Sharp: Small shift of resized thumbnail?

[puzrin]

• https://raw.githubusercontent.com/nodeca/sharp-resize-test/master/images/calendar.gm.jpeg
• https://raw.githubusercontent.com/nodeca/sharp-resize-test/master/images/calendar.sharp.jpeg
• https://raw.githubusercontent.com/nodeca/sharp-resize-test/master/images/calendar.pica.jpeg

Open images in separate tabs, and switch between those. I don't see difference between gm & pica, but sharp is slightly shifted. Can anyone confirm or negate? I'm not 100% sure that everything was done right at my side.

https://github.com/nodeca/sharp-resize-test - here are scripts to build test samples.

[lovell]

Hello, when sharp switched to use libvips' new reduce-based resizer, I was seeing some small round down errors.

Are you able to remove the + 0.1 from the end of pipeline.cc#L262 to see if this helps?

Alternatively, perhaps try + 0.05 as I believe a small addition is required to help prevent round down later. vipsthumbnail performs a similar addition.

[rlidwka]

@lovell, I tried removing + 0.1, and I'm afraid it has no effect at all (the code above actually uses fixed height/width, tried removing + 0.1 from lines 224-225 - same thing).

I can confirm that this glitch appeared in 0.15.0, in 0.14.1 there was no such shift.

[jcupitt]

Zooming in, it looks like sharp is stretching slightly vertically. The pen at the far right does not move if you flip between sharp and pica, but the pen at the bottom moves up.

Could sharp be giving slightly different numbers to reduceh and reducev due to rounding?

[puzrin]

IMHO horizontal shift exists too.

Could it be fractional miss (or error) after 1D box passes? I remember, we spend a noticeable time with tiler to properly calculate pixel compensations for lanczos filter init.

[lovell]

Thanks all for the feedback - I hope to take a closer look at this over the weekend.

[lovell]

Quick update: I've found the source of this small error and will commit the fix for it later today along with (an attempt to create) a test case to prevent it occurring again.

In summary, after the initial box shrink operation, the x and y factors are recalculated independently but then erroneously locked to the same value. This means if the shrink operation rounded up along one dimension, it could then also round up the reduce operation on the same axis, leading to a slight stretching effect.

[lovell]

Commit 7d261a1 should improve things. Thanks for reporting this!

[lovell]

v0.15.1 now available.