Sign In:     

Forum: Wishes and new features

Topic: Little improvement for skins (.xml file)

This topic is old and might contain outdated or incorrect information.

Sometimes happens that after resizing skins, they don't work good.

To fix it, VDJ should recognize decimal number like these:
size width="20.54" height="14.12"

Could it possible to add this option in VDJ?
 
Posted Tue 24 Feb 09 @ 10:33 am
There's no such thing as a decimal pixel position. For higher quality skin resizing bicubic interpolation should be used, also when I was making my own skin resizing program I found that the program being able to resize each element individually led to less artefacts in skins, however, I never made it public as I had problems with the faders not being aligned properly.
 
This should be good when you are resizing a skin.

Example:
skin from 1440x900 to 1280x800 with this code:
original code:
size width="60" height="50"

How big must the new size be?

Answer:
w=1440/1280=1.125
h=900/800=1.125

it means that the new width must be
60/1.125=53.33333333

while the new height must be
50/1.125=44.44444444

size width="53.33" height="44.44"

Since at the moment these numbers aren't allowed, JeremK rounded down in his algorithm 53 and 44. The problem appers when you are using this:
down x="0" y="3279" nbx="24"></down

it means you will have an approximation's error of 0.33*24=7.92 pixels and 0.44*24=10.56 pixels (these are visible to the naked eye).

Yes, of course we will have an error of 0.00333333*24 and 0.004444444*24 but they are so little that eyes don't notice it.
 
You can't have decimal pixels. If you imagine the game Tic Tac Toe, it has 9 grid squares, you cannot have choose the 2.33 position to place your move. This is the same thing with pixels on your screen.
 
I know Andrew, but without this stratagem is not possible to fix all problems in the matter of resizing.
 
sischo wrote :
I know Andrew, but without this stratagem is not possible to fix all problems in the matter of resizing.


VDJ would have to then either scale or interplorate anyway. Since this would only affect a resized skin, I think modifying the resizer to implement this would be a better bet.
 
I spoke with JeremK but he told me he can't change interpolation way on his tool.

Anyway, I think that even if he changed interpolation, it can't fix this issue.

Look this
visual pannel="6" chan="1" type="custom" source="position"
size width="53" height="53"></size
pos x="451" y="349"></pos>
down x="0" y="3689" nb="276" nbx="24"></down
clipmask x="499" y="2058"></clipmask
/visual>

The right number must be 53.33333

At first, the square 53x53 is right as position.



but after 24 (nbx=24) the square is wrong as position: this depends on error of approximation as I told you (the interpolation in this case doesn't hit the nail on the head).
 
I don't know what language JeremK wrote his tool in but bilinear interpolation is a simple algorithm; however for better quality bicubic shouldn't take too much work. http://www.fho-emden.de/~hoffmann/bicubic03042002.pdf

A monitor cannot display a decimal pixel so it's best to use whole numbers which also requires less processor resources. This work is better left to the resizer.

What you're illustrating is a bug in JeremK's program, not a Virtual DJ related issue. To achieve better quality he should resize each element individually and then place them in the appropriate x/y positions. I think his resizer does a simple scale of the whole skin and then replaces the original Virtual DJ specific controls which have a static size which is why decimal values appear to be needed.

This does not require Virtual DJ to understand decimals and it would be quite messy if it did.
 
Andrew87 wrote :

What you're illustrating is a bug in JeremK's program, not a Virtual DJ related issue. To achieve better quality he should resize each element individually and then place them in the appropriate x/y positions. I think his resizer does a simple scale of the whole skin and then replaces the original Virtual DJ specific controls which have a static size which is why decimal values appear to be needed.


He uses Real-basic language.
Yes, you are right:
"To achieve better quality he should resize each element individually and then place them in the appropriate x/y positions"

This is a good idea, but I think is very difficult to implement to him :(
It means a lot of picture processing; my idea was just to make plain JeremK's work! I don't know, maybe it means for Dev team to change the type of the variable as "real" rather than "integer"
 
But it's not that simple; as has been said many times you can't just use a fraction of a pixel. Virtual DJ would then have to implement extra alogrithms at runtime to do the interploration - it shouldn't be necessary for them to have to do that because a user is trying to violate the specifications. You specify in a skin where you want something on a screen, and it's dimensions. Those values are in pixels. Pixels are an integer value.

I agree with Andrew; I'd rather the skin engine didn't have the added complexity and rendering requirements of interploration.

Simply changing the co-ordinate system to support fractions by changing the variable type to double or float won't magically fix it - something still has to be done with those values. They are either rounded or interplorated.

Open up paint and see if you can draw a line on the bitmap for me, starting at exactly 10.21x10.21 and ending at 12.76x12.76. Let me know how you get on.
 
Yeah, I know SBDJ I cannot.
It's like if I would want to split a BIT in many parts..I know it's not possible!

Let me know:
how would you fix my question?

I have this solution:
the resizer should analyse when the resizing gives a decimal number and in that case it should move that section in the bitmap file according it:
for example putting a white pixel between two contiguous parts in order to "recover" the approximation loses during the resizing.



It's a very hard work to do!!:(
 
There's no need to put a white pixel there, working out the exact position is easy. In your example there are 276 elements, with 24 elements per line; that's 11 rows with a remainder of 12. If the original element is 60px and the scale factor is 1.125, we want each element to be 53px.

The skin resizer should copy the following:

[original bitmap - no remainder]
x = 0, y = 3689
+x: 60 * 24 = 1440px
+y: 60 * 11 = 660px

[original bitmap - remainder only]
x = 0, y = 4349
+x: 60 * 12 = 720px
+y: 60 * 1 = 60px

To these dimensions:

[scaled bitmap - no remainder]
x = 0, y = 3279
+x: 53 * 24 = 1272px
+y: 53 * 11 = 583px

[scaled bitmap - remainder only]
x = 0, y = 3862
+x: 53 * 12 = 636px
+y: 53 * 1 = 53px


Such scaling would match exactly the XML.
 
Hi everybody and thanks for your concerns.

I already thought about doing that Andrew, but didn't get the time to work on it yet.
One of the reasons it doesn't scale some elements individually is that I'm afraid it will overlap other elements in the skin or even get out of bounds of the picture.

The out of bounds in the picture crashes VDJ, this happened in the first releases of the Skin Resizer.

But what I could do, and this would only give a .99 pixel error at most, is change the size to Floor(60/1.125) and then scale some elements in the picture.
 
@andrew87
Now I understand what you meant!!:)

Rather than putting one white pixel between each square of 53x53, you will let more white pixels at the end of the picture (in fact 53*24=1272 < 1280 which is the width of the resized skin).
I guess this is more simple to be implemented.
 


(Old topics and forums are automatically closed)