Convert to profile not working?

[Guillermo Espertino]

Hi, I'm having this problem:

I'm using a screenshot software that is not color-managed (i.e. it just dumps the screen pixels) to capture an image from a color-managed application (for instance, Affinity designer). The resulting image, both on disk and in the clipboard, has its pixels in the monitor colorspace, but is untagged.
I'm sure that the captured image is in the monitor colorspace, because when I display it in any color-managed software it looks wrong, as it's untagged. So the proper way to deal with this is to assign the monitor profile to it, so the managed applications display it properly.

So far so good, my capture is in the monitor colorspace, tagged with the monitor ICC and looks properly in Affinity Photo.

The problem comes when I want to convert that to sRGB.

Logic says that the following step is to "convert to profile" that image, from the monitor colosrpace to sRGB. But for some reason, doing that makes the image turn back to the previous state (as if I just assigned sRGB instead of converting).

I'm pretty sure I'm not doing anything wrong, as the same procedure in Photoshop does what I described above as the expected result, but I wonder if there's something wrong about my display profile (maybe its ICC version, for instance).

I'm attaching a few samples (captured untagged image, display profile, and expected result) to reproduce it.

 

Affinity Photo 2.5.5 on windows 11. Working colorspace sRGB IEC61966-2.1

LF27T35 2024-04-19 140cdm2 D5893 2.2 F-S XYZLUT+MTX.icm

[Ldina]

@Guillermo Espertino Hi Guillermo. Your process sounds correct.....first assign the appropriate profile, then convert to sRGB (or whatever profile you want). I assume your colors and brightness look right after assigning your monitor profile? (BTW, it looks like your monitor profile has a 1.8 gamma).

My scanner uses Apple Image Capture and saves TIFF files with an embedded 1.8 gamma generic scanner profile. When I want to work on these files, my very first step is to assign my custom scanner profile, (which is more accurate than the generic scanner profile). 2nd step is convert to sRGB. I do this before adding any other layers or adjustments, and color appearance remains the same after conversion.

Sometimes I forget to assign and convert until after I have added Curves, Levels, HSL, Filters, etc. When converting from my 1.8 gamma scanner profile to sRGB, which is 2.2 gamma (mostly), those adjustment layers cause a brightness and color shift, since I am changing to a new gamma. So, the solution to that was to assign/convert before adding any adjustments, or do a Merge Visible, which puts a Merged Pixel Layer on the top of the layer stack, so adjustments and filters on layers below don't cause a color/brightness shift. You could also flatten the document so the conversion only acts on your pixel layer.

I'm not sure if this is what is happening, but it's worth being aware of. 

You might also want to look at your Color Settings/Preferences in Affinity Photo, especially Convert opened files to working space, and Warn when assigning working profile to unprofiled files. (BTW, I chose Display P3 for RGB primarily to process RAW files in a wider color gamut than sRGB). From previous Forum discussions, I know you do HDR and use OCIO, and I'm not overly familiar with those, so I can't help there. I don't know if they might have any impact. Hope something here is helpful.

EDIT (added info): I wonder if Affinity is automatically assigning sRGB (RGB color profile in settings) to your unprofiled screenshot? That's why I check that warning because I like to know when something is happening behind the scenes. I don't like hidden assignments or conversions, and prefer to have manual control over them when possible, at least most of the time.

[Ldina]

@Guillermo Espertino can you Zip and upload one of your screenshots that does not have an embedded profile? If so, I’ll see if it works on my system.

[Ldina]

I'm on a MacBook Pro (Ventura). I opened one of my JPG files and assigned the Monitor ICC profile you uploaded with your first post. As expected, it brightened the appearance of my file (the embedded profile in my original JPG was Display P3, which is 2.2 gamma (actually, ColorSync says gamma 2..4), and your monitor profile is approximately 1.8 gamma). That would be expected behavior due to the change in gamma.

Then I converted my "assigned" file to sRGB. The converted file matches my file with your assigned ICC profile, so it's working fine on my system. I started with a file that had an embedded profile, so perhaps behavior is different with a file that has no embedded profile (it shouldn't be).

If you upload one of your unprofiled screenshots, I'll take a look. If you do upload one, be sure to ZIP it first so the forum software doesn't assign a profile or mess with the file in some manner.

[Guillermo Espertino]

Hi @Ldina thanks for taking a look.

My monitor's gamma is not supposed to be 1.8. I'm on Windows, using a consumer Samsung monitor. I use Samsung's gamma mode 2 as it produces less deviation when calibrating to a gamma 2.2 target. In essence: the uncalibrated and calibrated state are "closer" than default mode (both visually and according to the calibration device) so it doesn't have to go too hard on vcgt. Actually, mode 2 is the "brighter" one of the three available modes. The difference you see between corrected and un-corrected images is the difference between the uncalibrated screen and the calibration. It's somewhat expected and I don't think it's important here. My problem isn't the uncorrected image appearance, but the inability of producing an sRGB output from that image with the monitor profile assigned.

As I mentioned above, assigning the monitor profile to the untagged capture produces the CORRECT result (which is indeed brighter than the uncorrected image).

So, at any rate, my capture with the assigned screen profile looks ok, as it should. The -apparently- broken step is converting it to a different profile, keeping the corrected appearance in the target colorspace (in my case sRGB is what I want, for a somewhat standard delivery)

And again: the same procedure done in Photoshop produced the right result.

If you say that you tried the exact procedure on a Mac and it worked with my files and my profile, then I guess that the problem either affects Affinity Photo on Windows, or there's something in my system/installation that is off.

 

[Ldina]

Can you upload a Zipped screenshot that does not have an embedded profile?

[Guillermo Espertino]

Sure. Here's the file as the capture software saves it.

uncorrected screenshot.zip

[Ldina]

Thanks, @Guillermo Espertino.

I'm not an expert (by any means) when it comes to EXIF data. Perhaps @David in Яuislip can give it a look because he is very informed on these matters.

But, I will share what I see. I opened your unprofiled screenshot in Affinity Photo, Apple Preview and XnViewMP to compare them. I also used Apple Digital Color Meter to compare some of the color numbers. 

My standard RGB working space is Display P3 in AP Color Preferences, and I also have ticked the box that says "Warn when assigning working profile to unprofiled files." No warning came up and the file was not converted to Display P3, so that is working properly. When opening your unprofiled screenshot in Affinity Photo, AP automatically assumes and assigns sRGB. No warning, no message. So your screenshot colors are being "interpreted and displayed" as sRGB. Since AP is a fully color managed App, it has to assume something to display the colors. The two logical choices are the sRGB internet standard, or whatever you have set as your standard working space in AP Color Preferences (in my case, Display P3). Obviously, AP assumes sRGB, which more often than not, is probably a good choice.

I used Apple Digital Color Meter to check some color numbers in AP, Preview and XnViewMP. When using Native readouts, all three Apps show the same color numbers for the red/orange banner color (236R, 85G, 41B). When using sRGB Readouts, they all agree and are 255R, 70G, 2B. Using Lab readouts there are slight differences, probably due to rounding errors and/or a different color conversion engine, but they are very close. AP shows 58.46L, 68.80a, 71.15b and Preview shows 58.65L, 69..21a, 70.75b. For all practical purposes, and visually, they look the same (at least to my eyes).

If I Assign your Monitor profile, the image becomes lighter and more washed out, since the RGB numbers in the file are being interpreted by by your monitor profile (Apple Colorsync shows your monitor profile has a gamma 1.766 tone reproduction curve, compared to gamma 2.2 for sRGB (approximately). If I then Convert from your monitor profile to sRGB, the appearance of your file stays the same, (i.e., washed out), which is as it should be. So assigning and converting are working correctly in Affinity Photo. 

Which color comes closer to your captured screenshot when viewed on your monitor (using your native viewer)? I'm on a Mac, so I don't know what you are using or how it handles unprofiled images. Quick View on Mac looks the same as the previews in AP, Preview and XnViewMP, so they all are assuming sRGB. It's been quite a while since I used Photoshop, but I'd guess they also would assume sRGB, but depending on your PS preferences, it might display a warning that sRGB (or your default profile) are being assigned to the file.

At least AP is working properly as far as I can tell. So, I guess you get to decide on what "color interpretation" you want, and can standardize your workflow for consistency. I'm not sure that answers everything, but that's what I see. Hope that helps.

BTW, this is on Mac. I hope AP is working the same on Windows. If not, there may be a setting issue or a bug hiding somewhere.

[Guillermo Espertino]

Hi @Ldina Thanks again for taking the time to follow this issue.
Although I appreciate your explanations, please note that I know how color management is supposed to work. I reported this issue because Affinity Photo 2.5.5 is apparently not doing what it should (on windows, or at least on my computer).

I'm aware that raw RGB triplets are likely to be interpreted by colour-managed software either assuming sRGB or assigning/converting to the working colorspace, depending on the settings.
My CM is configured to use sRGB as working space. My AP is also configured to warn if color profile was assigned automatically, and it's not doing it.

So it's quite clear that that untagged image I sent you is a raw capture of the corrected screen from Affinity designer. Since my working space is sRGB, all my artwork RGB is expected to be sRGB.
Affinity color management then "corrects" the screen output to my display profile (as it should) so those sRGB values look as close as possible on my screen.

So far so good. Affinity CM works ok.

It's also clear that a raw screen capture of a color managed screen will be in the monitor's colorspace. Ideally the screenshot software should embed that profile so CM aware software interprets the image correctly, but it doesn't.

That's why I assign the monitor profile when I import the screenshot into Photo. Pretty much the same as you assign your custom scanner profile. It's the right thing to do in those cases when images are untagged but you know the colorspace and have the profile at hand.

Up to that point, we're on the same page, everything works as expected.

The problem, again, is converting that tagged image to sRGB. You say it works on your Mac. On my system, it's not working (I think I'll record a screencast so you can see what I'm talking about).

It's a simple procedure that I know well and it works as expected in Photoshop, but in my Affinity Photo is failing at that last conversion point. I'm doing exactly the same you did.

I'll make a short video and share it here.

 

Oh, btw. I'm confused about the 1.766 gamma value reported by Colorsync. I specifically set DisplayCal to 2.2 upon calibration. It should be 2.2, unless the "relative" value on that selector is introducing some offset? Any ideas?

[Ldina]

Hi Guillermo.

I figured you knew a LOT about color management...I just wanted to be thorough to make sure, and for others who read this and are less informed.

On 11/22/2024 at 11:36 AM, Guillermo Espertino said:

My AP is also configured to warn if color profile was assigned automatically, and it's not doing it.

I think it probably IS working as designed. Since your 'default RGB working space' is set to sRGB, AP is NOT "officially" converting to your working space. It's assuming sRGB, regardless of what you have your working space set to....yours just happens to be the same as Affinity is assuming. My default RGB color space is set to P3 and so no conversion from sRGB to P3 takes place. Maybe it's poor wording on Serif's part. It should probably say Warn if converting to your working space, if it is set to other than sRGB, or something like that. Anyway, that's my guess, but only a guess. Most RGB "mystery meat" (RGB files without an embedded profile) will be sRGB, so it appears AP automatically assumes sRGB (same as Preview, XnView, etc). I guess we're supposed to know that.

I'll attach one Colorsync screenshot of your profile (Red Tone Response Curve). Perhaps I am misinterpreting what that means. However, assigning your profile definitely lightens the image, similar to what happens with my Gamma 1.8 Scans, so it's probably correct. The Green and Blue curves are identical.

I have a copy of ColorThink software on my old Mac Pro and it shows the following (3 screenshots). It also reports a 1.77 Gamma for your monitor profile. It is an ICC v2.2 profile, but the gamma is 1.77.

Yes, on my Mac, I assign your monitor profile, then convert to sRGB and the appearance does not change at all during conversion. I wonder if AP is properly recognizing your profile on Windows? All works as it should here. Does your screenshot get lighter when assigning your monitor profile? As I'm sure you know...it should because of the 1.77 gamma in your monitor profile.

It would be interesting to see a video recording of what's happening on your end. 

 

[Guillermo Espertino]

@Ldina I don't know if it was the 2.5.6 update or the problem was a temporary glitch, but when I tried to reproduce the error recording a screencast, it worked as expected.

I couldn't reproduce the problem again, so I suspect it was indeed some temporary issue on my end (maybe some conflicting application, profiles not loaded properly or just windows being windows). I remember having done the same procedure before and getting the expected results and everything is working properly again, so I guess this report can be dismissed.

Thanks for your interest. And sorry for wasting your time, it was driving me nuts but now the problem is gone.

 

[Ldina]

@Guillermo Espertino I'm glad all is working properly now. Problems like that drive me nuts too. You didn't waste my time at all, and I learned a few new things along the way. I enjoyed it. I may need your assistance at some point regarding HDR workflows. I'm trying to understand the complexities of Apple's HEIC files (taken with an iPhone 16 Pro and saved as HEIC or DNG) and how to best use their files inside Affinity. I haven't figured out how Apple can create such small files that still display in HDR, at least in their own ecosystem. 32-bit HDR exports from Affinity are massive. 👍

[Guillermo Espertino]

@Ldina Sure, feel free to start a new thread and poke me. I'm not super familiar with the platform and the format, but I get the gist of it.
As far as I know, it's basically the same as HDR video delivery, but on still frames. In essence, a 10/12 bit log encoding and some metadata.
It's not super complicated and under the hood is not even something really "new", although Apple seems to be the first player in the consumer market that put everything together in a way that is accessible to the general public.