Color Management and Targeting Outputs

Processing
1

This is a continuation of the post over on the RawTherapee category about some color pp3 profiles. I didn’ want to clutter up that post with this color management stuff:

By the way, I am using a color profile for my new monitor (Dell U2413), and the same for RT (per @Morgan_Hardwood), but I am still seeing super-saturation in my output if there’s no color management… :frowning:

For instance:

1592×559 260 KB

The left is what I see in chrome (from this post), middle is irfanview w/o color management turned on, and the right is irfanview with color management turned on (and is the same thing I saw in RT while editing)… Anyone have any ideas?

2

Well, that’s to be expected if it’s just a profile (with no calibration).

3

We may still be coming up against the color profiles being stripped from images. Here’s the same set of images. This time the first one is chrome (no web page, just opened the image directly in the browser), second is color managed irfanview, third is w/o color management irfanview.

1580×557 253 KB

4

I believe I have the U2412, fantastic monitor. Mine have a built in sRGB LUT, you may want to check the settings.

5

I’ve actually got it set to the factory sRGB setting now…

6

Interesting… Please follow up, as I’m planning on switching my editing rig to a new distro and will recalibrate and redo all of my color management stuff at that time.

7

Just finished a calibration + profile run with displaycal. It appears that things are running correctly.

Part of my problem right now is that for some reason the forum is still stripping profiles (even though @darix sent a patch upstream a long time ago). In fact, I am attaching his old color wheel as an example. If that top color is not labeled “Rot”, the profile got lost…

800×800 82 KB

8

It’s ‘Rot’ In Opera and Firefox on Win7/64

9

Sorry, I meant if the color doesn’t match the name…

10

Yeah it doesn’t match at all.

11

Yes, it doesn’t match

12

Yep, this means the profile is being stripped by the forums still… :astonished: I’ll check into this shortly (again).

13

But Chrome does not support color-management…

14

“Velvia-esque” is my favorite of the first set.

15

@Morgan_Hardwood does the RT community collect pp3 files like these somewhere?

16

@paperdigits no, but it would be nice to. pixls.us has a GitHub collection of stuff and ting, I think that would currently be the best place for them. Then we can link to the correct place from RawPedia where relevant.

17

I’ll get that started tomorrow evening.

18

That is to be expected. When an application doesn’t use the display profile and it’s a wide gamut monitor, then all the colors will look like straight from Ommpa Loompa land. That’s the downside of a wide gamut screen.

PS: Try watching a Michael Bay movie in a non-color managed video player. The already saturated colors will blind you. :smiley:

19

That was what I thought, too. My test images appear to contradict this, though. I’m on 52.0.2743.116 m and my images with a profile attached appear to be working correctly. Even the test image from @houz appears to render as expected:

Images that I generated working with @Hombre yesterday afternoon as tests:

https://pixls.us/files/samples/dot-out-No_ICM.jpg
https://pixls.us/files/samples/dot-out-RT_sRGB.jpg

In each case I was working in RT. I exported the first to No_ICM, and the second to RT_sRGB.

In a CM viewer, they look (as expected) different, with the RT_sRGB version looking close to what I was seeing while editing the file in RT. The No_ICM is just nuts, (again, as expected).

In a non CM viewer they both just look nuts (too super-saturated).

To make matters more odd (this is for another topic), both Firefox and Chrome render the RT_sRGB profile image slightly differently.

Left: Chrome, Right: Firefox
Top: No_ICM embedded, Bottom: RT_sRGB embedded

Just FYI: the RT_sRGB in Firefox is closest to what I was seeing in my RT editing.

The Question

Which leads me to my main question through all of this. We basically have two main approaches (targets?) that we’re considering here:

  1. Assume the viewer will be CM - in which case this is a non-issue? Just go with RT_sRGB or another space if you know that the viewer will handle it correctly. Basically, a normal workflow I’d think?
  2. Assume the viewer is not CM. Which begs my main question through all of this:

Is there a way to export what I’m seeing while editing in a CM workflow so that it will at least be closer if viewed in a non-CM application?

Best case scenario is that there’s a method for exporting/converting somewhere at the end of the pipeline to make sure that what I see matches as close as possible what a plain sRGB(?) or non-CM viewer would see?

Second option - would another possible solution be to set RT to use sRGB as my monitor profile while editing - as that seems to match what I see in my No_ICM output?

Relying heavily on @houz, @Morgan_Hardwood and others in here… :slight_smile:

20

My best guess: save the image for web display in sRGB. In this case:

  • a user with a calibrated monitor and a ICM-aware viewer will see the right colors, although users with wide-gamut display will not be able to take advantage of the extra gamut
  • a user with a small-gamut display, no display calibration and/or a non-ICM-aware viewer will still see approximately correct colors, depending on how much the display deviates from sRGB
  • a user with a wide-gamut display, no display calibration and/or a non-ICM-aware viewer will see highly saturated colors. But then he will have abnormally saturated colors for everything (movies, pictures, drawings, etc…)