But yes, since this is a batch scale image converter, so offering options to use a different algorithm to upscale and yet another more CPU-intensive one for very drastic upscaling (2x or more, when the pixels start showing) is still something that might turn useful.

If i have a filter that does "upscale with pixel scaling" theni apply the "resize" filter, then i'm "wasting" a lot of CPU time upscaling 90% (2700) of the pictures that need not be upscaled (or at least not that much).

Also keep in mind that while doing pixel upscaling is very good to "get details" where there are none, it can be done only on exact multiples of the original size.

To me the best option looks to be the following: there is a different "pixel upscale" filter which is distinct from the normal "resize" filter and does not ask you just for a given "upscaling multiple" (as most pixel upscaling programs do) but also for a "target size" and upscale only pictures that would (once upscaled) do the usual "fill", "fit" or "get near" the required size. as per normal resizing, only pixel resizing can only do exact multiple so to get the target desired resizing a second "normal resize" filter should be applied.

It is the best option as it makes the user interface less cluttered and in general it seems to get the point across with the "least work" to be done coding wise, as most of the stuff just has to be recycled. The user also has a nice little "pixel upscale" filter to tweak as he/she likes and maybe use either in conjuction with other resizes or just alone.

As for using different upscale and downscale the "least amount of work" would be to put an "upscale only" and "downscale only" option (i don't remember if it is already there) So if i apply the two filters close together, then the first filter will catch only stuff to upscale and use the algorythm i like to use for upscaling, and the second filter will just do downscaling and apply the algorythm i like for downscaling. And since they are close together, what is missed by the first gets taken by the second and everything is fine without doing loads and loads of code.

So the user just has to apply two filters, one for upscaling and one for downscaling, and it might be more flexible too, for whichever reason.

I am currently outside my house for work (and when i'll be back i'll probably just go to bed and forget about it).Can anybody tell me if what i wrote is correct and sensible (and also check if what i just said is already there)?

bdragon wrote:As for using different upscale and downscale the "least amount of work" would be to put an "upscale only" and "downscale only" option (i don't remember if it is already there) So if i apply the two filters close together, then the first filter will catch only stuff to upscale and use the algorythm i like to use for upscaling, and the second filter will just do downscaling and apply the algorythm i like for downscaling. And since they are close together, what is missed by the first gets taken by the second and everything is fine without doing loads and loads of code.

So the user just has to apply two filters, one for upscaling and one for downscaling, and it might be more flexible too, for whichever reason.

I am currently outside my house for work (and when i'll be back i'll probably just go to bed and forget about it).Can anybody tell me if what i wrote is correct and sensible (and also check if what i just said is already there)?

And i was finally able to have some free time to check this and indeed it is already there.

Seems like i made a fuss over nothing.

Since we have already established that the pixel upscaling for extreme upscaling has already been issued as a request.

And since i have confirmed that indeed the procedure was already there, and also done in the best, most elegant, way i thought possible... consider this as either "fulfilled" "solved" or whatever. XD