• This forum is strictly intended to be used by members of the VS Battles wiki. Please only register if you have an autoconfirmed account there, as otherwise your registration will be rejected. If you have already registered once, do not do so again, and contact Antvasima if you encounter any problems.

    For instructions regarding the exact procedure to sign up to this forum, please click here.
  • We need Patreon donations for this forum to have all of its running costs financially secured.

    Community members who help us out will receive badges that give them several different benefits, including the removal of all advertisements in this forum, but donations from non-members are also extremely appreciated.

    Please click here for further information, or here to directly visit our Patreon donations page.
  • Please click here for information about a large petition to help children in need.

Pixel Scaling small stuff using low quality images

718
339
Idk if all the calc staff keep this in mind when evaluating the calcs but when scaling sizes that are extremely small from those that are extremely large and vice versa, the image being used MUST be of very high quality with high pixel count as a rule.

It's easy to cheat your way out or get significantly lower/higher results (whether knowingly or unknowingly) with the difference of just 1 pixel when you're dealing with low quality images. For example if the size of something is 2px when you scale a low quality image, an error of 1px can either increase/decrease your result by 50%, it might get exponentially worse in some cases when exponents are involved with this as a basis.
For example, Kinetic Energy by finding distance with this as basis - by (x+Dx)^2 - x^2 or Kinetic Energy of Giant beings whose size is calculated with this as basis - by (x+Dx)^5 - x^5. It's kind of alright if Dx is very small but it isn't with low quality images.

Whereas with high quality images, it's like an error of 1px against a size of 6-10px.

I also suggest consider the dark boundary of the small object as well when dealing with small sizes. The scaling stick used should also be thin.

Idk if this is the right forum to post this on, change it if it's not.
 
I agree with this. Let's address the problem metrologicaly:

Let's be you have 5 px object which is 2 meters tall. Making the pixel ratio 2/5 = 0.4 meters per pixel. However, the discretization error must be 0.08080... m per pixel. So now you are scaling up the object which is 1020 px tall. 1020*0.4 = 408 m. But the error is now: ±85 m.

410 m ± 85 m
 
Yes:

Let's say it's a cube and you want to know its volume:

Result: 410^3 = 68921000

Error: 85*3*410^2 = 42865500

6.9E7 m^3 ± 4.3E7 m^3

This is clearly unacceptable
 
Yeah this makes sense, I don't usually encounter low quality pixel scaling tho

Higher resolution images should always be used over lower resolution ones for pixel scaling
 
Wait, I'm sorry this is not how it works. This is all indirect measurements:

Let's say you have 5 px object which is 2 meters tall. Let's call its height in meters h and height in pixels x. We want to know the height of an object which is 1020 px tall. Let's call its height in meters L and height in pixel y. Hence L = (h*y)/x.

h = 2 m; x = 5 px, y = 1020 px


L =
(2*1020)/5 = 408 m

Now the discretization error must be 0.5 px for obvious reasons (for both y and x)

∂/∂y((h*y)/x) =h/x: 2/5*0.5 = 0.2 m

∂/∂x((h*y)/x) = -(hy)/x^2 = 2*1020/5^2 * 0.5 = 40.8 m

How the total error: sqrt(0.2^2+40.8^2) = ±40.8 m

So 410 m ± 41 m

The fact that x is merely 5 px is very bad, it must be much larger to get a more accurate result
 
Last edited:
To simplify things a little bit, the final error formula is h*sqrt(x^2+y^2)/(2x^2)
 
That is what's been said in the post, except for considering the discretization error. It is sort of an intrinsic error as a result of discretization of something continuous.

But the error I'm talking about is something which is manually done, people usually can be off by around 1-2px, deliberately or not.
 
No, the discretization error is always ±0.5 px. ±1-2 px is a subjective error. And they do add up

btw I'm a metrologist
 
I'm also not too sure about using partial differentiation for the error considering that the error isn't really small in comparison in this context.

I'll just compare w/ and w/o partial differentiation. I'm also assuming "y" to be constant.

L = h*y/x
L^2 = K*Y/x^2
PartialDer = -2*K*Y*dx/x^3

Now without,
Delta L^2 = K*Y*(1/x^2 -1/(x+dx)^2)
= K*Y*(2x*dx + (dx)^2)/(x^2*(x+dx)^2)

Let's say dx = 0.5 and x = 2

w/PD = 0.125
w/o PD = (2+0.25)/(4*6.25) = 2.25/25 = 0.09

I see it as something significant enough 🤔
 
Last edited:
No, the discretization error is always ±0.5 px. ±1-2 px is a subjective error. And they do add up

btw I'm a metrologist
Literally what I said though...

I said it is intrinsic and I'm talking about something manual aka subjective. We aren't machines.
 
It is nice that you're a metrologist bro. Although my expertise isn't in this department, I went till the national training camp stage for both physics and astronomy Olympiads in highschool. And I did do a few courses on data sciences in college
 
Yes, when pixel scaling it makes sense to use as high quality of an image as possible.... Well, not higher quality than the original, but aside from that.

I don't know if it really is relevant for any calc, but when in doubt one might have to round a little.
 
I'm also not too sure about using partial differentiation for the error considering that the error isn't really small in comparison in this context.

I'll just compare w/ and w/o partial differentiation. I'm also assuming "y" to be constant.

L = h*y/x
L^2 = K*Y/x^2
PartialDer = -2*K*Y*dx/x^3

Now without,
Delta L^2 = K*Y*(1/x^2 -1/(x+dx)^2)
= K*Y*(2x*dx + (dx)^2)/(x^2*(x+dx)^2)

Let's say dx = 0.5 and x = 2

w/PD = 0.125
w/o PD = (2+0.25)/(4*6.25) = 2.25/25 = 0.09

I see it as something significant enough 🤔
I'm sorry but I don't understand what you did here. Why did you square the L?
 
Oh that is for exponential terms. You can't differentiate between the partial differentiation and normal subtraction if it has no exponent.

Edit: you can but talking about how it'd be significant with an exponent

Edit2: It would also be fairly significant w/o exponential term but an exponential term portrays a better difference

Edit3: It is 0.125 (dx/x^2) and 0.1 (dx/x*(x+dx)) for the linear term
 
Last edited:
Well everyone seems to agree. So should this be added to calculation guide page or something?

Btw @Ugarik agrees with what the post is mainly about too, it's just that he says the intrinsic error isn't as big as he initially thought (although even that is still fairly significant) - which I never disagreed with or contradicted in the post/comments to begin with.

In fact, the intrinsic error only makes it worse. Or rather the subjective error makes it much more worse on top of the inhernet discretization error.
 
I would like to add that one should use as few pannels/images as posible. The error does add up
 
... I mean, duh. What is this even proposing, "please let us actually see what you're pixel scaling we are not psychic"? That's pretty obvious, no? I agree tho, I just fail to understand what the change is
 
Uh.. no. This can't be properly described with "plz let us see wat u pixel scaling"

I don't think the image quality is given the significance it deserves when someone's evaluating cases such as this.

Take Toneri's moon split calc for example. It was like 280 exa-tons with bad image quality and it turned out to be 355 exa-tons when a HD image is used.
https://vsbattles.fandom.com/wiki/U...lf_(In_HD)?useskin=oasis#WikiaArticleComments

It got lower result because a small image is being scaled from something large and line thickness sort of makes the scaling stick smaller than it should be even though it appears as though it fits.

If it was the other way around, the result would have been inflated instead. If this involved the KE of a giant human, it would've had a result like 5x higher than what it should be. And still most wouldn't have noticed this.

It should be explicitly stated in guide that when dealing with stuff similar to this, high quality images should be used and thin scaling sticks for small sizes. It makes the calcs lot more accurate.

And no, this isn't something obvious/trivial for most that do calcing
 
Eh, fair enough, I just had to evaluate a real ******' crusty pixel scaling
 
Back
Top