Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

Colors in exported images differ from editor


Recommended Posts

I find it hard to understand the effects that color profiles have on the colors of images in Affinity Photo.

A raw image opened in Photo looks de-saturated, compared to DXO and preview in Irfanview. The JPEG from the camera looks better, but less saturated than shown in other software, like Firefox, Paint.net and Irfanview. Perhaps some setting of Photo overrides the data from the image?

When developing the image I assign the ROMM RGB profile. From what I understand this profile keeps the highest number of colors available during editing. Is this true?

After making adjustments I export the image as JPEG to use on Instagram and my website:

  1. during export choose the sRGB color profile and embed it. Other software like the Windows Explorer preview, Windows Photos, Irfanview and Firefox show the exported image more saturated then I see during editing.
  2. first convert the image by changing the color profile of the document to sRGB. Then exporting it the same way. Now the image is also more saturated then shown in Photo, but less than in option 1.

What do I need to do differently to have the colors of the exported image match the colors I see during editing?

This happens on a Windows machine with the color profile of the display set to the profile that came with the monitor.

Link to comment
Share on other sites

2 hours ago, kwebble said:

A raw image opened in Photo looks de-saturated, compared to DXO and preview in Irfanview...

In APh the RAW develop engine as default usually doesn't apply any preset exposure compensation, contrast, sharpening ... etc. settings, thus opened RAW images look more dull here. Apply some settings and make yourself a preset for your cam.

2 hours ago, kwebble said:

When developing the image I assign the ROMM RGB profile. From what I understand this profile keeps the highest number of colors available during editing. Is this true?

gamut_wide.jpg.1dcaf94d591ecf5aeb4a9787e7bbe454.jpg

Yes, it offers the most colors from the usual available different color spaces (see above).

2 hours ago, kwebble said:

What do I need to do differently to have the colors of the exported image match the colors I see during editing?

Well if things differ that much, then try to use the sRGB color space instead of ROMM RGB also for developing/editing the images and see later after exporting if they do match better here in terms of colors and tonality.

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

Link to comment
Share on other sites

11 hours ago, v_kyr said:

Yes, it offers the most colors from the usual available different color spaces (see above).

Something to keep in mind about those color charts is they show a two dimensional slice through what is actually a three dimensional color space. As explained here, while these charts provide a useful way to visualize how colors map between color spaces, they typically show midtone mappings, so they can be a bit misleading about how shadows & highlights will be mapped.

That reference is part 2 of a very informative 3 part article (as is just about everything else in the tutorial section of the Cambridge in Colour web site). If nothing else, it might be a good idea to read part 3 as well.

All 3 1.10.6, & all 3 V2.03 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.6; Affinity Designer 1.10.6; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

1 hour ago, R C-R said:

Something to keep in mind about those color charts is they show a two dimensional slice through what is actually a three dimensional color space....

Yes, the idea for that gamut image was just to quickly show that there are indeed huge color amount differences between the color spaces.

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

Link to comment
Share on other sites

20 hours ago, v_kyr said:

In APh the RAW develop engine as default usually doesn't apply any preset exposure compensation, contrast, sharpening ... etc. settings, thus opened RAW images look more dull here. Apply some settings and make yourself a preset for your cam.

Well if things differ that much, then try to use the sRGB color space instead of ROMM RGB also for developing/editing the images and see later after exporting if they do match better here in terms of colors and tonality.

Thanks for the tips, I'll try and see what the exported result looks like when editing sRGB.

About the RAW, I mentioned it because I thought it might matter for the end result. I prefer to use DXO for RAW conversion because of better noise and color fringe reduction, lens correction and local brightness adjustment.

Link to comment
Share on other sites

7 minutes ago, kwebble said:

...I prefer to use DXO for RAW conversion because of better noise and color fringe reduction...

Well in general RAW converters are a theme of their own, meant here in terms of the quality they generate for specific supported cameras and their RAW format, thus it might highly depend here. Personally I think one always has to (re)check again from time to time and do some own individual RAW converter comparison tests here for the cams one use, in order to see which one does the overall best job.

From those RAW converters which support a bunch of vendors and cams the DXO one IMO does a decent good job. It's by far not the fastest performer, but the results it produces were quite good (at least for my cams here). - However as said things are changing fast nowadays and there are a bunch of such RAW conversion tools available, comercial and freeware/opensource, so one always has to look which fits best the individual needs here.

So if you feel comfortable with the DxO one, just use that one then!

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

Link to comment
Share on other sites

  • 2 weeks later...

Hi,

I think I have the same question as @kwebble.  I am uploading a .NEF, an .aphoto and its corresponding .jpg, and a .dop and its corresponding _DxO.jpg (Archive.zip) and would like to ask the forum what I can do to make the .aphoto more similar to the .dop.

Technical background:  Affinity Photo 1.6.7, DxO Photo Lab 2 2.1.1 build 17, macOS 10.13.6 running on 2018 MacBook Pro 15".

Photo:  Taken Dec. 6, 2018 at 16:11 from one of the two towers of the Basel cathedral.  It had rained off and on the whole day, the sky was just clearing and the sun just setting.  The camera is configured to use Adobe RGB.  Affinity Photo is configured to use ROMM RGB.  The .afphoto seems "muddy," particularly in the foreground, and lacks the "punch" of the .dop.  I am sure that most of the difference can be attributed to my inexperience.  Affinity Photo is configured not to use a tone curve when importing a RAW file.  In the Develop persona I do some minimal sharpening, tame blown out highlights and try to "spread" the histogram.  In the Photo persona I try to first get the colors right before I mess with sharpening, but invariably find that I spend more time on sharpening.  Photos like this one stand to benefit from dehazing, but dehazing and sharpening seem to introduce enough visible noise that avoiding and/or mitigating it soon becomes important.  I hesitate to use DxO as a substitute for Affinity Photo's Develop persona.  I tried exporting from DxO to .DNG, and importing it to Affinity Photo.  Yes, the file was recognized as RAW, but it bore little resemblance to what I was seeing in DxO when I exported it.  A mix-and-match approach to developing RAW "film" and "printing" "negatives," although perhaps logical, would seem to be fraught with pitfalls.

Thanks in advance.

Richard Liu

MacBook Pro 16" 2021 M1 Max | macOS 12.3.1 | BenQ SW271 | Affinity Photo 1.10.5

Link to comment
Share on other sites

Hi richard,
I gave it a try.
Imported the native NEF file in Develop Persona.
I Took a screenshot with the settings I used (see attachment).
Didn't do any further adjustments in Photo Persona.
 

EDIT

Some extra important info.
Check your settings in Develop persona.
In my case :
- Tone Curve = Take no action
- Exposure Bias = Apply exposure bias as initial state
(important because you took the picture with a +0.7 exp compensation (see EXIF tab)

_Develop Persona.jpg

_DSC0678_2 .jpg

Develop Assistent.jpg

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)

 

Link to comment
Share on other sites

Hi @HVDB Photography,

Thanks.  I was able to reproduce your results provided I changed RAW output format in the Develop Assistant to RGB (16 bit), even though our settings on Noise reduction also disagree (I have only Apply color reduction).  I notice that, in my case, clipped highlights, shadows and tones appear.  Maybe they would disappear if I changed my configuration for Noise reduction to yours.

At any rate, the main difference is the RAW output format.  I'll be the first to admit that I really don't understand what I gain by configuring RGB (32 bit HDR).  Is there any tangible benefit, or are the benefits only theoretical?  My (mis)understanding is, Affinity Photo is working in 32 bit anyway, and therefore it might be advantageous to postpone a conversion to 16 bit until the device for which the output is intended cannot handle 32 bit.

Also:  I'm not sure how you came up with the idea of increasing Blackpoint.  I usually decrease it, since many adjustments that I will perform in the Photo persona (e.g., increasing contrast and detail) seem quite often to push the histogram back to the left.

Regards,

Richard

Richard Liu

MacBook Pro 16" 2021 M1 Max | macOS 12.3.1 | BenQ SW271 | Affinity Photo 1.10.5

Link to comment
Share on other sites

On 12/23/2018 at 5:33 PM, Richard Liu said:

Maybe they would disappear if I changed my configuration for Noise reduction to yours.

As far as I know, noise reduction does not affect clipping.
And I think it's normal that clipping appears. The photo was captured  in "Auto Exposure", with +0.7 EV, and ISO 1600, focus on the cathedral.

On 12/23/2018 at 5:33 PM, Richard Liu said:

 I'll be the first to admit that I really don't understand what I gain by configuring RGB (32 bit HDR).

Me too.
To the best of my knowledge, most RAW data is captured at 12-bit or 14-bit.
The unprocessed image data is then remapped and represented in a 16-bit container.
 

On 12/23/2018 at 5:33 PM, Richard Liu said:

My (mis)understanding is, Affinity Photo is working in 32 bit anyway


That's what this video tells:

But to me it's also a kind of gray zone ... and I think we're not the only one.
I suppose the same process as for a 16 bit is used, remapped and represented in a 32-bit container.
 

On 12/23/2018 at 5:33 PM, Richard Liu said:

Is there any tangible benefit, or are the benefits only theoretical?

There should be  .. maybe less than when using a serie of bracketed images (3 or more) because the HDR merge combines them to produce a wider dynamic range (I suppose)  then when using a single RAW file.
 

 

On 12/23/2018 at 5:33 PM, Richard Liu said:

I'm not sure how you came up with the idea of increasing Blackpoint.

Well, I'm just eyeballing and trust my gut feeling.
 

I did some testing .. developed  one in 16 bit and the other in 32bitHDR.
They both needed different settings in Develop Persona to achieve +/- the same result.
Then I imported them in Tone Mapping Persona and used the same settings for both.
There are some slightly differences between both (see attachment), and of course we're looking at an 8bit JPG export.

 

 

_004.jpg

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)

 

Link to comment
Share on other sites

Maybe, in the near future, @James Ritson will write an in depth article in Affinity Spotlight, on how a 16 bit RAW image is being remapped in a 32 Bit HDR?

 

 

A merry Christmas to you all.

 

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)

 

Link to comment
Share on other sites

I second the motion.

By the way, I had a look at your tutorials on YouTube.  I think you could improve them by using your own voice.  The reader that you use often puts the emphasis on the wrong word in a phrase.  Besides, a foreign accent enhances the aura of the product.  Otherwise, my compliments.  Well done, and very useful.

Richard Liu

MacBook Pro 16" 2021 M1 Max | macOS 12.3.1 | BenQ SW271 | Affinity Photo 1.10.5

Link to comment
Share on other sites

By the way, do you have the your settings for Develop in 32 bits and and those for the tone mapping to hand.  Perhaps there's "just" something that I'm overlooking in Develop.  If not, don't worry.  I'll have something to do over the Christmas holidays.

Merry Christmas to All

Richard Liu

MacBook Pro 16" 2021 M1 Max | macOS 12.3.1 | BenQ SW271 | Affinity Photo 1.10.5

Link to comment
Share on other sites

Hereby ... 
Preset Export  > see attachment

 

_32bitHDR_DevelopPersona.jpg

_32bitHDR_ToneMapping.jpg

DSC0678.aftonemap

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)

 

Link to comment
Share on other sites

An interesting reply from @James Ritson from an earlier thread

 

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)

 

Link to comment
Share on other sites

Thanks, Hubert.  I read @James Ritson's answer in that thread, obviously in a way that he never intended, weighing each and every word twice and thrice, and coming up with more questions than answers.  A cursory reading reveals what seems to be a contradiction between the virtues of development done in 32-bit floating point, the advantages of editing (in the Photo persona) in a wider-gamut color space than sRGB, and the ominous sentence that begins, "Honestly, I wouldn't recommend touching 32-bit unless you're doing something that demands precision above what 16-bit offers, e.g. close-ups of clouds or skies [...]"

I think 32-bit processing and working in, say, ROMM RGB are two different animals.  At least, that's the only way I find to avoid that contradiction.  The abrupt cut to the take-home message, not to use 32-bit unless ..., is, in my case at least, unhelpful, for it's exactly the sky and the clouds, blown out in the JPEG generated in-camera and quite evident in Develop, that I will want to preserve, if not enhance, in the Photo persona.  Maybe James would not consider that to qualify as "close-ups of clouds or skies."  Finally, the reason that James gives for avoiding 32-bit if possible is enticingly nebulous:  "but it brings about other issues into your typical image editing workflow."

I suspect that I am experiencing some of those issues, and could avoid them altogether by configuring Develop to output 16-bit RGB using the ROMM RGB profile; however, my understanding of why I might not want to opt automatically for the seemingly greater flexibility of 32-bit RGB and ROMM RGB would be enhanced by a tutorial that clarifies the terms

  • 16- and 32-bit processing;
  • 8-, 16- and 32-bit RGB color format;
  • sRGB and ROMM RGB profiles

and illustrates the advantages and disadvantages of 32-bit editing.

 

Richard Liu

MacBook Pro 16" 2021 M1 Max | macOS 12.3.1 | BenQ SW271 | Affinity Photo 1.10.5

Link to comment
Share on other sites

15 minutes ago, Richard Liu said:

 A cursory reading reveals what seems to be a contradiction between the virtues of development done in 32-bit floating point, the advantages of editing (in the Photo persona) in a wider-gamut color space than sRGB ...

As @James Ritson mentioned, the development process itself is always done using 32 bit float & ROMM RGB. The output of that process to the Photo Persona can be set to 16 or 32 bit, & the color profile can be set to sRGB or ROMM RGB, depending on the Develop Assistant settings. IOW, it isn't contradictory because there is a difference between how the process is done internally & how the results of that process are sent to the Photo Persona.

So you are right, in the sense that 32-bit development processing and working in ROMM RGB in the Photo Persona are two different animals.

All 3 1.10.6, & all 3 V2.03 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.6; Affinity Designer 1.10.6; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

@R C-R:  Yes, I was sure.  Furthermore, how many bits (16 or 32) which color format (8-, 16- or 32-bit RGB, etc.) and which ICC profile (sRGB, Adobe RGB, ROMM RGB) are used during the processing, especially in the Photo persona, seem to be three independently configurable aspects of the processing, an impression that one doesn't automatically get when one learns that the Develop persona works in 32-bit float and uses the ROMM RGB profile.  Indeed, I had assumed up until now, that ROMM RGB implied 32-bit processing and 32-bit RGB color format, and that the advantages of both developing and editing using 32-bit floating point calculations in ROMM RGB would outweigh the slowness of floating point calculations.

I think I, at least, really need to understand what @James Ritson was warning against when he wrote, "Honestly, I wouldn't recommend touching 32-bit unless ... ."  Did he mean color format 32-bit RGB or 32-bit floating point processing, or are these equivalent for him.  Specifically, too, I would like to know some of the pitfalls of "32-bit" to which he alludes.

Richard Liu

MacBook Pro 16" 2021 M1 Max | macOS 12.3.1 | BenQ SW271 | Affinity Photo 1.10.5

Link to comment
Share on other sites

@>|<:  Woah!  I have my camera configured to use Adobe RGB, so, do you mean to say, when AP opens the NEF (Nikon's own RAW format) file in the Develop persona it first converts all the colors that Adobe RGB can represent that sRGB cannot into the "next best" sRGB colors???  I can hardly believe that.  If you mean, in this case it retains the Adobe RGB colors during the development, but converts the results of the development to sRGB during output.  Well, that, too I find hard to believe.  Why on earth would it do either of these two things if I've taken the trouble to photograph in Adobe RGB?

Richard Liu

MacBook Pro 16" 2021 M1 Max | macOS 12.3.1 | BenQ SW271 | Affinity Photo 1.10.5

Link to comment
Share on other sites

47 minutes ago, >|< said:

With the current retail and beta versions of AP, the colours in the output from Develop persona are always limited to the sRGB gamut, ...

Sad but looks to be true, I recall the bug report thread about that theme! - So talking here about using Adobe RGB or ROMM RGB in the Develop Persona is actually pretty meaningless.

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

Link to comment
Share on other sites

To be slightly more specific:

If you take photographs in RAW format, you can make the decision about the working color space to use later. Camera raw data inherently have no color space; the color space set at the time of shooting on the camera only affects the embedded preview JPEG and becomes the default in some RAW converters, but does not affect the actual raw data.

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

Link to comment
Share on other sites

@>|<, @v_kyr, @R C-R, @HVDB Photography, and all who stumble on this in thread in the future:

Here is the thread that discusses bug/feature/behavior mentioned by @>|< and confirmed by @v_kyr:  

This is disappointing and unacceptable, especially as it seems to be a "feature" of the current release candidate as well.  If I understand correctly, colors exceeding sRGB in a RAW file opened in the Develop persona are converted to sRGB.  Subsequently, all operations performed during development are done in 32-bit floating point in a wider-gamut color space, just so that resulting colors that fall outside sRGB are not immediately lost.  Finally, during output, any colors outside sRGB are converted to sRGB.  I'm not sure I see much point in using Affinity Photo for development until this is fixed.

Does anybody know whether the Photo persona performs the same kind of prestidigitation?  If I developed in, say, DxO Photo Lab 2 and exported the results in, say TIFF and Adobe RGB, and opened it in AP in the Photo persona, would it first convert the colors to sRGB?

Richard Liu

MacBook Pro 16" 2021 M1 Max | macOS 12.3.1 | BenQ SW271 | Affinity Photo 1.10.5

Link to comment
Share on other sites

@v_kyr

Quote
11 minutes ago, v_kyr said:

To be slightly more specific:

If you take photographs in RAW format, you can make the decision about the working color space to use later. Camera raw data inherently have no color space; the color space set at the time of shooting on the camera only affects the embedded preview JPEG and becomes the default in some RAW converters, but does not affect the actual raw data.

Yes, that's how I understood you.  In fact, the camera is configured to shoot NEF + JPEG and generates not only the embedded JPEG, but also the same JPEG it would generate if I were only shooting JPEG.

Richard Liu

MacBook Pro 16" 2021 M1 Max | macOS 12.3.1 | BenQ SW271 | Affinity Photo 1.10.5

Link to comment
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...
 Share

×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.