Create thumbnails in the "same sRGB" as Lightroom

[sebschub]

The thumbnails seem to be another sRGB as the Lightroom output in sRGB. The difference is visible in a non-color managed application on my wide gamit monitor (e.g. also my browser). Maybe it is an issue of linear color vs non-linear color, with a description here what that actually means.

Here is an example. The first picture is the main Lightroom output with IEC 61966-2.1 Default RGB colour space - sRGB (sRGB IEC61966-2.1).

The following is the large thumbnail generate by the plugin. The colors are more intensive, more saturated, in particular, the red is stronger. The file seems to not include a color space profile.

I was able to reproduce the issue with imagemagick on my Linux machine. I get exactly the same colors as the plugin's thumbnail with convert -define jpeg:size=1280x1280 -quality 80 -colorspace RGB -unsharp 0.5x0.5+1.25+0.0 -colorspace sRGB fox.jpg fox_RGB_sRGB.jpg. Here, the color profile just says sRGB - lcms generated (sRGB).

However, with convert -define jpeg:size=1280x1280 -quality 80 -unsharp 0.5x0.5+1.25+0.0 -colorspace sRGB fox.jpg fox_sRGB.jpg I get the same colors as with the Lightroom originall. Color profile says IEC 61966-2.1 Default RGB colour space - sRGB (sRGB IEC61966-2.1).

Obviously, I would like to have a thumbnail matching the Lightroom output with sRGB so that it does work without color management. Unfortunately, removing the -colorspace RGB in the plugin did not yield a better result (or I did something wrong). (That the fox might need a bit more intensive red is another question... ;) )

[sebschub]

There is practically no difference on a normal, non-wide gamut monitor.

[flingo64]

That was my impression, too. I can see a little difference in sharpness and probably in contrast, but no difference in color. Some questions, though:

• when you changed the parameter in the plugin code, did you reload the plugin and could you verify in the Logfile (Loglevel-Debug) that your changes were applied?
• which program do you use to view the pictures, or is the effect independent of the viewer and solely depending on the monitor?
• the thumbnails generated by the plugin do not have a exif header (including the colorspace indication), whereas the other pictures have a exif header. I think this is controlled by the -strip option. Could you try to change this in the plugin code?

[flingo64]

I found this article (German) from my favorite computer magazine C'T explaining the whole colorspace issue: http://www.heise.de/ct/artikel/Zu-bunt-getrieben-292000.html So, adding the exif header to the thumbs might be one part of the solution ...

[sebschub]

Adding the exif information would only help with color-managed applications. And webbrowser have issues with it. On the other hand, I do not understand why using a color-managed application (showfoto from the digikam suite) actually does the correct thing... I will try to work on your questions during the next week and will also have a look at it from within lightroom (ie importing the pictures in lightroom) so there is no operating system change involved.

[flingo64]

I did some testing with various parameter combinations according to ImageMagick's documentation and verified the output with Exiftool/Exiftool-GUI:

• -thumbnail (instead of -resize) removes all exif header infos (which is OK for a thumbnail)
• -strip removes all remaining image profile data, including the ICC header (which includes the color space information)

Removing only -strip did not bring back the ICC Header and Profile, but when I removed also the -colorspace RGB option (as you suggested) the ICC Header and Profile came back to the thumbs (as in your last/ideal image).

So, knowing that at least Firefox is capable of doing color management, http://ntown.at/de/2013/12/28/firefox-color-management/ it's probably a good idea to keep the ICC header also in the thumbnails.
I can't see any bad side effects, even the file size was slightly smaller, so I decided to include the changes yo suggested.

Please, check out, if you can see the difference.

[sebschub]

Thanks a lot. This seems to solve this issue for color managed and non-color managed applications. I don't know what I did wrong when testing before.

[flingo64]

Good to know! Unfortunately, I realized that this fix will only work for photos that use sRGB colorspace, which is very likely, at least. If in a rare case a user decides to process to AdobeRGB or to export original photos with a different colorspace, then with this parameter settings convert will keep the original ICC Header and Profile (indicating AdobeRGB) while at the same time transcode the thumbnail to sRGB.
Could you do me a favour and test this scenario? I probably won't find the within the next two weeks to work on it, though.

Thanks, Martin

[sebschub]

Why not remove color space conversion all together? Thumbnails should look like the original as much as possible. If the user chooses aRGB or any other space, (s)he expects the viewer to understand and cope with color spaces. Thus, thumbnails in this particular space should be fine.

[sebschub]

I'll test this later this week.

[flingo64]

Excellent idea! There is really no point in transcoding to a different color space within a Lightroom Export plugin: use the appropriate section in the Export/Publish dialog to define the target color space for both the original and the thumbs! Besides that, it might (hopefiully) also speed up the thumb generation. Let me know if it works as expected for different color spaces. I will then publish a new version.

[flingo64]

Results form my side when removing -strip, -colorspace RGB and -colorspace sRGB:

• thumbs keep the original colorspace and the original (correct) ICC Header and Profile (checked for sRGB and AdobeRGB configured in Lr export)
• thumbs are 3 - 5 % smaller
• thumb generation is 15% faster !!!(on a sample of 83 photos)

I'm so excited about this obviously beneficial enhancement that I uploaded this modification (not yet tagged as release). I really hope to hear that it works well on wide gamit monitors, so it will be tagged as next release!

Thanks, Martin

[sebschub]

I can confirm that it works fine, tested also with (for-jpeg-output-crazy) Pro Photo RGB. Nice to see that speed increase. From my pov, this can be closed (cannot see this fox anymore... ;) )

[flingo64]

v3.1.0 is the tagged release for this fix.