Apply correct colourspace conversion when producing thumbnails

[theefer]

i.e. the same rules as we do when cropping.

That will mean search thumbnails will be a correct preview of what the image is like in RGB. Note that the full image (via imgops nginx module) will likely still be wrong.

cc @kenoir

[paperboyo]

Yeah, that would be cool. But the full image is more important. Just had a conversation about it (explaining why it's wrong and that one has to download the image or make a full size crop to check the colours). I wouldn't like to become too lazy and convert everything to sRGB just not to have these conversations... ;-)

Regards
Mateusz

[theefer]

Yes agreed, but that might be harder to do as it's done by nginx currently, so will have to do separately.

[paperboyo]

Yes, I know, just wanted to say the above to state the obvious ;-) Reading about VIPS, e.g. http://libvips.blogspot.co.uk/2012/11/new-colour-package.html. From my perspective it looks good. And the github "support" is amazing. Searching its github by png and icc makes good impression. The lack of pngquant is less exciting, but entirely expected... But how it hooks up to yours, I wouldn't know...

[paperboyo]

Hi,

Just a followup on that. So with the thumbnails the situation is not bad. Currently, there is no conversion done to them, but the profiles are intact. So in huge majority if instances browsers deal correctly with that and make a necessary conversion on the fly (there may be tiny performance hit here?). Some profiles are not recognised by browsers (most probably v4 profiles), like famous 311f2d6b4cd994014bb3f0d88a33f7d43e8471f9, but the majority are.

Unfortunately, at the cropping stage/in viewer the profiles are stripped (and there is no conversion), so the images with anything but sRGB look wrong. Unfortunately it looks like nginx image filter module is using libgd which is known to be crap at that for quite some time (libgd/libgd#136). :sadpanda:

#155?

Regards
Mateusz

[paperboyo]

It’s not entirely relevant, but I didn’t wanna pollute issue list any more. After doing very limited experiments, I think we can ~halve the sizes of thumbnails (by adjusting creation process, stripping metadata). I’ve done a Photoshop resize (Bicubic sharper interpolation, much sharper, harder to compress) of the original picture https://media.gutools.co.uk/images/c3192fc7b8fb9d99b725f67f04c9d0f93560c11a (it’s got "test" label, so you can see thumbnail by using it). Then I’ve saved it twice compressing through SaveForWeb (stripping metadata, leaving AdobeRGB profile) - with better quality (subjectively) than our thumbnail and trying to visually match quality. And SaveForWeb is far from being the best encoder. We could do more tests using GM or mozjpeg or something... Images here, so that they can be opened in tabs and compared quickly.

Original Grid thumbnail 50.7 KB:

Ps q51 26.3 KB (with metadata would be 32.7 KB!):

Ps q40 18.8 KB:

[edit] Of course this is not exactly representative, images of blue sky will behave differently, sRGB profiles are 2,6 KB (this one is just a tag, would we do the colour conversion we would have to live with 2,6 KB * number of thumbnails 😢), some metadata may weight less. But it can also weight substantially more. In general, I think we should be optimistic.

On that note, see you in three weeks ⛺ 😎

Regards
Mateusz

[theefer]

Great thanks, enjoy your holidays!

[paperboyo]

Fixed in #1306 & #1621. Now only #894 left. Safe to close?