Incorrect colours exported using ACE engine

[trafficjamstudio]

First posted in PS forum, mistakenly 

This issue has been plaguing ADOBE for years - it keeps popping up and causes us a lot of issues.

We need to output images with RGB background shade e1d3c4. Our projects have thousands of images (ecommerce) so we have to use software like Lightroom. The problem is, lightroom use ACE to convert the TIFF or PSD or other sources files, to JPG SRB 8 Bit files.

When this happens, the colour is changed to e1d4c4, not e1d3c4.

In PS, we can use the Apple CMM engine - if we do this, then it exports the JPG with the correct e1d4c4 shade no problem at all. This is an adobe ACE engine problem specifically and causes us so many headaches when a client wants a background colour to match their website colour.

I have attached two JPG images, one exported with ADOBE ACE one exported with APPLE CMM - the APPLE CMM conversion is bang on. The adobe conversion is always wrong.

It is not just an issue on MAC either - I had issues like this on windows for years - I had to do multiple colour profile conversions to get that to work, but nothing apart from using CMM works for Mac that I can tell. Anyone. have any other solutions?

I do not want to have to export via PS - it is too clunky and time consuming for the multiple thousands of images we produce monthly.

Our next step is to use Capture One as a catalogue to manage our files instead of Lightroom to see if we get better results with exporting (we have until now only used capture one sessions for tethering as we love the overlay - hate the AF spot movement though with Canon, does not work)).

  

[Jao vdL]

Just tested this and indeed this is a bug. I created a photoshop tiff file and filled it with e1d3c4. Saved the tiff and imported it into Lightroom Classic. Then exported to a jpeg and opened it in Photoshop again and tasted the color and indeed it changed to e1d4c4. Very strange and a bit disturbing indeed. That is a big shift in the green channel! Have you reported this bug?

[trafficjamstudio]

Thanks for your reply. No I have not reported this as I am not sure if it is a bug or if is a limitation of the srgb colour space. 

I have tried using Capture one which is even more off, though I think a differnt channel. 

[Jao vdL]

A little more testing and it looks like this is a rounding error moving between color spaces. It even happens when using 16 bit output but much smaller errors (only 2 in 16 bits precision) not visible in 8 bit space. Looks like Adobe is doing the color math in different precision than Apple.

[trafficjamstudio]

I think I made a mistake sayin the APPLE engine worked better, it does not - same error as I just tested all this again today. As above, C1Pro also has same-ish issue. 

I have even tried creating an 8bt sRGB tiff file and converting that directly to an 8 bit sRGB jpg image - same shift which to me makes no sense but I am no colour space conversion expert. I posted this first in PS channel by mistake - someone there suggested it could be a JPG compression issue - that makes no sense to me and JPG compression would not save space just by changing this colour to another one when it is a consistrent coloured background. 

I rememebr I had this issue a few years ago and I managed to work around it - I need to figure out the workaround again. If I do I'll post it on here.

Thanks again for your feedback.

[Jao vdL]

Not surprised you get the same problem in 8 bit sRGB. I don't think the source space matters. Also indeed jpeg compression has nothing to do with this. It will even happen when going to tiff. What happens here is that (at least in Lightroom), the file gets translated into linear 15 bits prophotoRGB (for some reason the full 16 bits doesn't get used) and then gets converted back into the sRGB space and tone curve. It probably goes through lab space to get there so there is a string of color conversions happening instead of a single straight shot into the destination space. These multiple conversion steps can lead to pathetic cases in which rounding actually gets you to shift a single bit in 8 bits space when rounding is applied going back into 8 bits sRGB which is what is happening here.