Ticket #236 (Fixed)Wed Feb 03 15:15:19 UTC 2010
Problem with ChangeFSI
Reported by: | Jon Robinson (374) | Severity: | Minor |
Part: | RISC OS: Application | Release: | |
Milestone: | Status | Fixed |
Details by Jon Robinson (374):
If you use ChangeFSI to resize graphics, it nearly allways creates a grey strip along the bottom row and rightmost column, which shouldn’t be there. You can load the file in Paint and delete the unwanted strips, but it wastes time. The problem seems to be present on all versions of ChangeFSI.
Changelog:
Modified by Sprow (202) Sun, February 07 2010 - 09:17:25 GMT
The problem is one of data creation.
Say you have an image with an even number of pixels and scale it by a half, ChangeFSI uses a resampling algorithm which I’ll assume is linear here: so neighbouring luminance pixels of 90% and 80% would become a single pixel of 85% for example (ignore chroma for now).
If instead you have an image with an odd number of pixels at the edge you have to decide what to do with the last pixel: 90% 80% 70% -> 85% and ??%.
In ChangeFSI at the moment it slides an imaginary column of black in so you’d get 85% 35% in this example, or in plain english a strip of grey.
This is an improvement on older versions of ChangeFSI which used whatever garbage was in RAM leading to a strip of random colour pixels!
The question is what to do – duplicating the last column would be one policy (so you’d get 85% 70% in this example), or extrapolate based on the other pixels (so 85% 65% instead), or ignore the user’s request and round the output sprite size to the nearest whole pixel.
Modified by Steve Revill (20) Mon, December 06 2010 - 22:44:01 GMT
I would be tempted to produce output at the size that the user asked for – they presumably had good reason for asking – and invent some rows/columns which are duplicates of the edge that they extend so that rather than mixing with (say) black pixels, you’re mixing with pixels of the same colour.
Modified by Jeffrey Lee (213) Tue, September 10 2013 - 12:19:21 GMT
I’d say the correct approach would be to recalculate the scale factor based around the output image size. i.e. if you’re scaling a 101 pixel wide image by 50% and ChangeFSI decides the output width should be 50 pixels, the interpolation would use a scale factor of 50/101 instead of 1/2.
Modified by Sprow (202) Thu, January 09 2014 - 13:51:14 GMT
While recalculating the scaler to match the image size would certainly get rid of the right/bottom stripe, it does mean the scaling factor is no longer what the user asked for. Philosophically that might be less acceptable, or at least it’s different to the current behaviour.
eg. 34×34 sprite, resized by 14/16 => 29.75×29.75 (a factor 0.875)
obviously you can’t have fractional pixels so ChangeFSI currently rounds up and gives you a 30×30 output with the image portion scaled by 14/16 as desired and some junk round the bottom/right edge. If instead it’d adjusted the scaling factor to 30/34 you’d get an image of exactly whole pixels, except that the scaling factor is now 0.882 – an error of 0.8%.
Modified by Sprow (202) Fri, November 04 2016 - 23:04:44 GMT
- Status changed from Open to Fixed
Having looked at what ChangeFSI was actually doing, I see my concern about different scaling factors was unfounded, since ChangeFSI was already rounding up the output pixel size anyway, so in some circumstances you already didn’t get what you wanted.
Fixed in ChangeFSI-1_59.