Jump to content
kwebble

Colors in exported images differ from editor

Recommended Posts

Yes and if you shoot RAW (Nikon NEF format) there is no associated working color space since it captures more or less the raw sensor data. A working color space comes for NEF into account when you develop the NEF inside some RAW converter, there inside the RAW converter software you setup a working color space to deal with. Initially there is no working color space for RAW data.


☛ Affinity Designer 1.8.3 ◆ Affinity Photo 1.8.3 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

The current approach of AP to development, i. e., prestidigitation (now it's sRGB, now it ain't, now it is), essentially limiting colors to sRGB -- yes, I understand that working in between input and output in 32-bit floating point and ROMM RGB has at least theoretical benefits --, would seem to be something that it would behoove Serif to repair before it becomes public knowledge, unless, of course, this is supposed to be a feature, the superiority of which over the more straight forward approach of the competition should be more widely publicized.

Ironically, I entered this thread assuming that both AP and DxO are both using all data and metadata in RAW files, so it would be possible to obtain with AP results similar to those I get with DxO, and any extra work involved would be mitigated by the benefits of working exclusively in the more powerful and more flexible product.  Now, I must conclude that, unless DxO is engaging in the same color reduction hocus-pocus, the differences I see between AP and DxO might well be due to the extra color information that DxO has retained, which all the extra power and flexibility of AP is not likely to be able to compensate.

Share this post


Link to post
Share on other sites

Very interesting discussions guys.
A lot to read, on this holy Christmas day
Thank you all for your contribution and commitment .


Affinity Photo  1.8.0.585   -  Beta 1.8.0.555

Windows 10 Home  1909 (build 18363.657) - 64 bit processor - AMD A4-5000 APU with Radeon HD Graphics  1.50GHz - RAM 8,00 GB
Calibrated Monitor (Datacolor Spyder5 Pro)

 

Share this post


Link to post
Share on other sites

Thanks all for the clarification regarding the amputated colors.  What is the status of this bug or feature?  Will it be fixed, or is there some justification for mapping to sRGB on input and output to/from Develop instead of to the target output color space?

Share this post


Link to post
Share on other sites

Hopefully this can clarify the issue and also clear up the concerns that Photo is discarding or throwing away anything outside of sRGB:

RAW files opened in Develop go through an image processing pipeline, during which the colour information is extracted and processed—the colour space used for these operations is ROMM RGB because it provides a suitably large resolution and enables colour values to be saturated and manipulated without clipping to white. This choice of colour space was introduced in version 1.5 where there was a marked improvement in RAW files with intense colour values (e.g. artificial lighting).

However, the actual document profile is in sRGB—this means the final colour values sent to the screen are restricted to sRGB. Is this deficient? Yes, and there have been discussions about how to tackle it without risking further complication for people who don't use wide colour profiles.

There is a silver lining though. RAW files are developed in an unbounded (float) colour space, which means all the values that fall outside of sRGB are not clipped or discarded. If you were to then set your output profile to a larger colour space like ROMM RGB, these out of bound values can be accommodated by the larger resolution of that colour space. Essentially, you can avoid clipping values outside of sRGB when clicking Develop, and you can get them back once you're in the Photo Persona: the issue is that you can't see these values within the Develop Persona.

I've experimented with one of my photographs of some intense lighting to back this up, and have attached it to this post for people to experiment with. I've also compared the results versus Photoshop CC 2019 (where you can set the colour space and it will actually affect the view transform) and, minor processing differences aside such as sharpness and lens distortion, have been able to match the intensity of colours. For Photoshop I also used ROMM RGB and increased saturation directly in the Camera Raw module.

Here's the RAW file for you to try out:

_1190462.RW2

Steps for this experiment:

  1. Enable Shadows/Highlights and drag the Highlights slider to -100%.
  2. Avoid any colour or saturation adjustments, add other adjustments to taste (e.g. noise reduction).
  3. Enable the Profiles option and set the output profile to ROMM RGB.
  4. Click Develop.
  5. Once in the Photo Persona, add an HSL adjustment and increase Saturation all the way.
  6. You'll be able to dramatically saturate the image without losing resolution.
  7. If you close and re-open the RAW file and try to increase the saturation within Develop, you'll notice that the colour values are restricted to sRGB—however, even with values at the limit of sRGB, you can still set the output profile to ROMM RGB and then increase them further once in the Photo Persona.

And below are two images, one still in ROMM RGB, the other converted to sRGB. I'm not sure how they will display on the forum (and whether the forum software will process and convert the colour profile—hopefully not!) but feel free to download both and view them in a colour-managed application or image viewer. If your display is capable of reproducing wide colour gamuts, you should see a noticeable difference between the two.

[Edit] OK, that didn't work, the forum software converts to sRGB and ruins the comparison. Here's a Dropbox link to the JPEGs and RAW file where you can download the original files: https://www.dropbox.com/sh/aof74w94f6lm3d2/AABXE2OJMfk__kjA_jb6vwmia?dl=0

_1190462_sRGB.thumb.jpg.474bfcb562633523b45f4184ce07c059.jpg

_1190462_ROMM.thumb.jpg.eb8e5a42313d60483046e491e0d60aad.jpg

 

Hope that helps!

James


Affinity Photo Video Tutorials - Affinity Photo for iPad Tutorials

Looking for a manual/documentation? Check affinity.help for online help!

@JamesR_Affinity for tutorial sneak peeks and more

Share this post


Link to post
Share on other sites
1 hour ago, Richard Liu said:

Very happy about this.  Let's hope the changes make it into the next production release.

Well, it's in 1.7, which is the next planned production release, once it finishes the beta process.


-- Walt

Windows 10 Home, version 2004 (19041.388),
   Desktop: 16GB memory, Intel Core i7-6700K @ 4.00GHz, GeForce GTX 970
   Laptop:  8GB memory, Intel Core i7-3625QM @ 2.30GHz, Intel HD Graphics 4000 or NVIDIA GeForce GT 630M
Affinity Photo 1.8.3.641 and 1.8.4.693 Beta   / Affinity Designer 1.8.3.641 and 1.8.4.693 Beta  / Affinity Publisher 1.8.3.641 and 1.8.4.687 Beta.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.