JPEGs in AdobeRGB too little saturated

Christian_Pfister · January 13, 2020, 3:58pm

As far as I know Firefox understands color management. Here you can check how to activate it.

betazoid · January 13, 2020, 4:03pm

Color management is active in FF. FF displays the colors like other color managed apps, e.g. RT. Only dt behaves differently here with JPEGs in AdobeRGB. The raws look normal.
The odd thing is that apparently dt thinks the JPEGs are in an even much larger color space than AdobeRGB. If it assumed they are sRGB, the colors would be more saturated.

betazoid · January 13, 2020, 4:04pm

you must click on my screenshots. In the preview it is barely visible. The difference should also be visible on an sRGB screen I think.

paperdigits · January 13, 2020, 4:08pm

Is this DT screenshot of the lightroom or darkroom view? What’s your working color space in DT?

betazoid · January 13, 2020, 4:15pm

darkroom mode; ok, I have just seen that output color profile was set to sRGB in darkroom, however I am not sure if this should matter. Anyway I set the output color profile in export settings in lighttable, usually I just leave the output profile setting in darkroom alone. I will test if the output color profile setting in darktable matters
Edit: checked, no difference.

danny · January 13, 2020, 4:26pm

No, it would be more saturated if it would assume that display is in srgb and it would be wider gamut display (without profile).
If it assumes srgb source, while it’s adobergb, it would desaturate the output.

Christian_Pfister · January 13, 2020, 4:26pm

I did (and the pictures are still open). But I still think the perceived difference is due to the background color, at least on my screen (NEC PA241W calibrated with SpectraView).

By the way DT uses the screen profile to display images. The setting in the output color profile or the Export module is only used during export. So maybe something is wrong with the dev version of DT you are using (3.1)?

betazoid · January 13, 2020, 4:29pm

betazoid · January 13, 2020, 4:31pm

I will upload the full res jpeg later

Christian_Pfister · January 13, 2020, 4:31pm

Can you paste a link to download this JPEG. I can try on my system with DT 3.0 (W10)

danny · January 13, 2020, 4:39pm

On windows cms in darktable 3.0 works fine for me on primary monitor, is broken on secondary monitor.
The same file displayed in linux version dt3.1, show (wrong) different colors, with cms correctly configured with same display profile (confirmed with darktable-cms and krita).

Christian_Pfister · January 13, 2020, 5:30pm

So one should check whether the issue has been reported on Github (I couldn’t find it).

betazoid · January 13, 2020, 6:26pm

I checked a few hours ago, before starting this thread, did not find anything either

danny · January 13, 2020, 6:26pm

I opened one for the windows issue before 3.0 was released:

github.com/darktable-org/darktable

Windows: incorrect colors on secondary monitor

opened 09:21AM - 29 Nov 19 UTC

closed 12:27AM - 13 Feb 21 UTC

Dannny1

no-issue-activity scope: OS support scope: color management

**Describe the bug** When darktable opens on secondary monitor(1) and the main …display is (2), it displays wrong colors. It probaly uses the display profile of the main (2) display. It shows correct colors on (1), if the (1) is set as main display. darktable 2.6 wasn't affected by this issue When dt is opened it seems also to show for very short moment small window on the main display, before it opens darktable window on the other monitor, it may be related. **To Reproduce** Steps to reproduce the behavior: 1. Have 2 monitors calibrated 2. Set darktable to open on secondary display 3. Open image in darktable **Expected behavior** it should use profile of the monitor where it's open and display corect colors as 2.6 did **Platform (please complete the following information):** - OS: Windows 8.1 - dt version: 3.0rc1 and rc2

But wasn’t touched, i won’t open another…

betazoid · January 13, 2020, 6:27pm

https://drive.google.com/open?id=17mF8nalTnzf-MX_8MCcWvMRHsRhlAqkK

betazoid · January 13, 2020, 6:30pm

I can do it though probably to today, but if there is no reaction to a bug report this does not mean much, it certainly does not mean that you should not report bugs any more. Besides, that was right before 3.0 was released and the devs had probably more important bugs to fix. Its clear that they cannot do everything at once.

danny · January 13, 2020, 6:39pm

It may be issue not directly in dt, but in cms library too.

anon41087856 · January 14, 2020, 12:20am

See

github.com/darktable-org/darktable

Internal D65 colour profiles possibly wrong

opened 12:18AM - 14 Jan 20 UTC

closed 07:27AM - 18 Apr 20 UTC

aurelienpierre

no-issue-activity priority: high scope: color management

**To reproduce:** 1. export a a raw picture to TIFF 32 bits float with Adobe RG…B output profile 2. open the exported TIFF (input profile set to "embedded ICC matrix", no module except input/output profiles) 3. export it again with the same parameters. Then, either overlap both exports using the darkroom snapshots or compute the RMSE using GraphicMagick `gm compare -metric RMSE export-1.tif export-2.tif -file diff.png` **Issue:** The blue channel has twice the RMSE as the other channels. On the picture, especially in dark greens, the second export (export from export) displays darker colours. With LCMS2 on (CPU SSE2 path): ``` Image Difference (RootMeanSquaredError): Normalized Absolute ============ ========== Red: 0.0000082394 0.5 Green: 0.0000052063 0.3 Blue: 0.0000157842 1.0 Total: 0.0000107103 0.7 ``` With LCMS2 off (OpenCL path): ``` Image Difference (RootMeanSquaredError): Normalized Absolute ============ ========== Red: 0.0000067537 0.4 Green: 0.0000059158 0.4 Blue: 0.0000203831 1.3 Total: 0.0000128592 0.8 ``` sRGB exhibits the same issue: ``` Image Difference (RootMeanSquaredError): Normalized Absolute ============ ========== Red: 0.0000119955 0.8 Green: 0.0000108273 0.7 Blue: 0.0000247451 1.6 Total: 0.0000170630 1.1 ``` Comparing with an external ProPhoto ICC profile: ``` Image Difference (RootMeanSquaredError): Normalized Absolute ============ ========== Red: 0.0000011652 0.1 Green: 0.0000012465 0.1 Blue: 0.0000031726 0.2 Total: 0.0000020798 0.1 ``` Diff image (differences highlighted in red): ![diff](https://user-images.githubusercontent.com/2779157/72302764-5c876880-366b-11ea-9ce6-46e3c0e4081b.jpg) I suspect an error in the internal Adobe RGB and sRGB profiles on the B channel coeff. Based on @blitzgneisserin https://discuss.pixls.us/t/jpegs-in-adobergb-too-little-saturated/15785 (but not sure it's the same problem).

danny · April 11, 2020, 5:13pm

I opened the issue on github.
It seems that the input color profile module doesn’t apply the embedded profile by default.
https://github.com/darktable-org/darktable/issues/4651

betazoid · April 11, 2020, 5:20pm

I thought this was fixed weeks or even months ago.