Discrepancy between full-size preview in AP and exported JPG of it

[Richard Liu]

First, I apologize that I have different aspects of this problem in different topics.

 

Summary of Problem:

On my MacBook Pro 17", to which a Thunderbolt Display is connected, I have

1. developed a RAW file in AP Develop and specified the ROMM RGB for output.
2. In the Photo persona I changed the Document | Colour Format to RGB (16 bit), 
3. setup my adjustment layers and live filter layer,
4. then export the document as a JPG, 100% quality, using the ROMM RGB profile, which should be embedded.

When I compare the exported file and the document in AP, both at full size, both either on the laptop display or on the Thunderbolt display, the JPG is much darker than the document as displayed in AP.  Both displays have been calibrated using basICColor display and an X-rite i1 Display Pro.  I have several color profiles for each display, D50 L* 160 cd/m², D50 2.2 160 cd/m², D65 L* 110 cd/m², etc.  Regardless of which one I use, the JPG is alway much darker than the AP document when both are viewed at full size on the same display.  Only when I set the color profile to the factory default does the  document in AP become as dark as the JPG, which does not seem to change much.  (☚ Thanks to @owenr for the suggestion after doing some valuable tests!)  Clearly, the take-home message cannot be, so just use the factory profiles, especially given the ages of the laptop (late 2011) and the Thunderbolt display (bought second-hand several years ago).

 

Testing my Understanding:

For some time I have been assuming the the export must be the culprit, but @owenr graciously tested my .afphoto on his (her?) Mac and verified that the JPG as displayed by Preview is identical to the document as displayed by AP.

My understanding is, on Mac's applications don't need to worry about monitor profiles, that is the job of the OS.  So AP only needs to worry about the working color space, described by the ROMM RGB profile, when rendering the document, and the target space when exporting, which, in this case, is the same.  And, since Preview is color profile-aware, I should be seeing identical images, regardless of the monitor profile.  But perhaps AP is doing something else when displaying the document?  Or, not for the first time, my understanding is faulty.

Can anybody explain what I am seeing and perhaps suggest how I can profile the monitor(s) so that the JPG and the document in AP are identical?  For anybody interested, the .afphoto, a .jpg and a .tiff are here:  https://www.dropbox.com/sh/l5oaidwrbn4xiot/AADQ32NVF14neGoV_fqEYV8Xa?dl=0 .

 

Thanks

[R C-R]

When you export a document with an RGB 16 bit format to a JPEG file you are converting it to an RGB 8 bit color format. That's because JPEG only supports 8 bits of color. That is why you see differences.

You cannot, nor should you try to, 'fix' this by changing your monitor's color profile. 

[lepr]

.

 

[R C-R]

1 hour ago, owenr said:

Did you open Richard's files before commenting, I wonder.

Yes, I did. The differences I saw when exporting to JPEG I attributed to the rendering intent probably being different, but I have no way of knowing how AP was set up for that on his vs. my system.

[lepr]

.

[R C-R]

2 minutes ago, owenr said:

Rendering intent? What has that got to do with exporting an Affinity document to a JPEG with the same profile?

It affects how colors are mapped from 16 to 8 bit color.

[lepr]

.

[lepr]

.

[R C-R]

2 minutes ago, owenr said:

Where are you getting that "information" from?

The Cambridge in Colour link I added to my earlier post, among other places.

[lepr]

.

 

[R C-R]

Just now, owenr said:

I think you've become confused about things you have read.

So are you saying rendering intent has no effect on how colors are converted from a larger 16 bit color space to a smaller 8 bit one?

[lepr]

.

[Richard Liu]

@R C-R

3 hours ago, R C-R said:

When you export a document with an RGB 16 bit format to a JPEG file you are converting it to an RGB 8 bit color format. That's because JPEG only supports 8 bits of color. That is why you see differences.

You cannot, nor should you try to, 'fix' this by changing your monitor's color profile. 

In the meantime, @owenr has chimed in.  I appreciate all replies.

Having had no luck in creating a profile that would have the same effect as the factory default, i.e., make the JPEG as displayed in Preview and the AP document appear identical, I decide to try DisplayCAL ... and seem to have struck gold!  Starting simply, I let it just calibrate the laptop display and the external Thunderbolt display to a gamma of 2.2.  Evidently, everything else is "native."  DisplayCAL, unlike basICColor display, does not attempt to set the white level programmatically.  Instead, I have to set it manually while DisplayCAL checks.  The result was a profile that is probably very similar to the factory profile, since I had very little to specify, and the JPEG exactly matched the AP preview -- both at 100%, of course.  Drunk with beginner's luck, I created other profiles that DisplayCAL offered as presets, among others a 5800K L* softproof one, a D50 gamma 2.2 one "for photography," and one with D65 gamma 2.2 for office work, and that for both displays.  I have spent the better part of the day on this, it is dark outside (10:23 p. m. here in Basel, Switzerland), and either I am beginning to hallucinate, or the tree is ever so slightly darker in the JPEG with all these profiles, but I will check tomorrow.

What all these profiles have in common is, I have not specified anything regarding black point.  When I have more time, I might return to basICColor display and see whether I can create at least a softproof profile similar to DisplayCAL's with it by taking defaults on some of the parameters.

Again, thanks to one and all.

[lepr]

.

[R C-R]

11 hours ago, owenr said:

You are confused. Reducing the bit depth while keeping the same colour profile does not change the colour space, so rendering intent has nothing to do with the problem at hand.

I am confused by quite a few things. Not the least of them is, for the _DSC6609.afphoto file I downloaded from Dropbox, what happens to the document's colors when I convert it from the original RGB (16 bit) color format to the RGB (8 bit) one without changing anything else about it, & when I do the same after flattening it. Histograms for each:

In all cases, the color profile remains ROMM RGB, but as you can see something odd happens when the color format is changed, & without flattening the file the Affinity Photo histogram does not even show the correct number of pixels for the 6016 x 4016 px file.

[Richard Liu]

Thanks for looking, @R C-R.

I have noticed that, in general, reducing the color format changes the appearance of the document, and hence its histogram.  Sometimes, all that is required to make the new document resemble the original more closely is some tweaking of the live filter and adjustment layers' parameters.  In some cases, though, some layers must be unchecked and new ones inserted.  In rare cases, I have found it impossible -- or I have not had the patience -- to keep trying.  This is especially true going from RGB (32 bit) to RGB (16 bit), maybe less so from there to RGB (8 bit).

Regarding the histograms, it seems that the program accords the updating of the histogram a low priority.  I loaded the document and did nothing else.  Eventually, this appeared.

24,160,256 = 4016 x 6016.  Notice how the blip at the right edge has become a spike.  I do not recall how long I had to wait, nor do I know whether it is possible to speed up the process.  That probably explains what you noticed .  377,504 pixels would correspond to an image reduced to 12.5% of the original size.

I think the histogram would be more useful if

1. another symbol (e. g., ⏳) replaced the ⚠️ until the refined histogram appeared.
2. the classic zones were represented on the histogram.
3. it were possible to point to a pixel in the preview and see its level on the histogram.  This can be simulated, of course, by selecting a small area around it and checking the Marquee option of the histogram, but ... 

[lepr]

.

[lepr]

.

[lepr]

.

[R C-R]

1 hour ago, owenr said:

The caption under your bottom-right histogram says that the 16 bpc document was converted to 8 bpc and then flattened. However, that histogram reveals that you actually first flattened the 16 bpc layered document and then converted to 8 bpc (which is what would happen under the covers when exporting the 16 bpc layered document to a JPEG).

My caption was meant to mean "_DSC6609.afphoto Flattened" to its left (comma) was afterwards converted to 8 bit. I was in fact trying to emulate what would happen when exporting it to a JPEG. For each row of two histograms, my intent was to show the source file on the left & result on the right. Sorry if that was not clear.

As for waiting long enough for the fine histogram(s) to be generated, that explains what I was seeing in the top pair ... except that when I first ran the tests that I took the histograms from, I waited over 3 minutes for the updated ones to be generated, which I assumed would be long enough. Today, repeating the same tests, it now takes about 30-40 seconds. I am not sure why, other than maybe that there were background processes not associated with Affinity Photo running during the first test that were running with higher priority then that were not running today.

Anyway, you have convinced me that I need to check Activity Monitor when generating fine histograms in Affinity to make sure that process has completed, so thanks for that.