darktable-org / darktable

Code Issues 544 Pull requests 37 Actions Projects 8 Wiki

Jump to bottom

Choice of display profile affects histogram, color picker valuesand overexposure indicators #3271

Closed flannelhead opened this issue on Nov 3, 2019 · 46 comments

Labels reproduce: peculiar

Learn Git and GitHub without any code!Using the Hello World guide, you’ll start a branch, write comments, and open a pull request.

Read the guide

New issue

flannelhead commented on Nov 3, 2019 •

Describe the bug It doesn't seem possible to saturate the black level to yield zero RGB values.

black_level_test_file_and_xmp.zip

To Reproduce Steps to reproduce the behavior:

1. Open a raw image with no edits (an example Olympus ORF file attached)2. Enable the Exposure module

3. Set black level correction to 1.0

Contributoredited

4. Enable under/overexposure indicator

5. Observe there are no parts of the image indicated as underexposed (I have the underexposure thresholdset at 2% which is the default)

6. Color picker also shows a minimum value of RGB = (6, 6, 6) , at some point this becomes independentof the black level correction (e.g. the same result with 0.1 and 1.0)

7. Tried also doing some other adjustments (e.g. contrast, brightness) but no adjustments seemed toreduce the RGB values

8. Increasing the underexposure threshold to 3%, now most of the image is shown as underexposed

Expected behavior Most of the image should be shown as underexposed and there should be completely black pixels ( RGB =(0, 0, 0) )

Platform (please complete the following information):

OS: Arch Linux x86_64

Version a82f213

Additional context In my usual workflow I have used the over/underexposure indicators to observe clipping e.g. when doingadjustments in Filmic, but now the underexposure indication seems to be broken. I can try to find the mostrecent version where this worked (next week) if it is beneficial. This also doesn't seem to depend on whetherOpenCL is enabled or not.

flannelhead changed the title Not able to saturate black level - RGB always above zero Not able toclip to pure black - RGB always above zero on Nov 3, 2019

junkyardsparkle commented on Nov 3, 2019

Can't reproduce; I get plenty of black clipping showing up. Can you reproduce this on a fresh profile with nosettings changed?

Contributor

flannelhead commented on Nov 3, 2019

Indeed it reproduces if I remove $HOME/.config/darktable and $HOME/.cache/darktable and the relevantXMP files and start fresh.

Contributor Author

It seems to also reproduce on earlier revisions where I clearly remember the clipping indicator working. Kindof a mystery, guess I'll have to investigate if something is broken on my system (package upgrades etc.)

junkyardsparkle commented on Nov 3, 2019

Weird. Maybe something to do with color management or a weird display profile?

Contributor

flannelhead commented on Nov 3, 2019

Indeed it seems to be display profile related; if I start darktable when my calibrated display profile is loaded,the issue reproduces. When using the stock display profile, the minimum value I get is now RGB = (5, 5, 5)instead of (6, 6, 6) (still the nonzero result here puzzles me somewhat). This is enough to fire the clippingindicator. Can anyone provide insight on the nonzero values?

Weird that the issue wasn't there earlier - I'm fairly sure the calibrated profile was loaded also before. colordhasn't received updates recently either. Some KDE Plasma packages have been updated though, I'll continueinvestigating.

Contributor Author

flannelhead commented on Nov 3, 2019

Ok, so if I set the display profile to sRGB in darktable (instead of system display profile), RGB = (0, 0, 0) isreached. Guess it's good time for me to recap on Linux color management and check if my calibrated colorprofile is actually ok.

Contributor Author

flannelhead commented on Nov 4, 2019 •

I'm indeed getting some pretty weird effects in darktable. I don't think my display profile is at fault.

Contributor Authoredited

The first weirdness is that "system display profile" is listed twice in the "histogram profile" menu (right-clickon the soft-proof or gamut check buttons).

The other one is related to this piece in the release notes for 3.0.0rc0:

A new profile ‘histogram profile’ has been added on the same pop-up that the softproof one on thedarkroom. It controls the color space of the histogram, color picker and overexposed check. Whengamut or softproof checks are active the histogram and color picker use the softproof profile, otherwisethey use the histogram profile. The overexposed check always use the histogram profile.

So as far as I understand, the selection of "display profile" or "softproof profile" shouldn't affect thehistogram, over/underexposure checks or the color picker values in any way as the "histogram profile" settingis used for those (see the image of the relevant menu).

However, what I'm seeing here is that if I e.g. set "histogram profile" to sRGB and then change "displayprofile" between "system display profile" and "sRGB", I see an evident change in the histogram, color pickervalues as well as the indicated over/underexposed regions. :(

Edited the title accordingly.

flannelhead changed the title Not able to clip to pure black - RGB always above zero Choice ofdisplay profile affects histogram, color picker values and overexposure indicators on Nov 4, 2019

junkyardsparkle commented on Nov 4, 2019

I honestly don't know if that's the expected behavior or not... maybe @edgardoh can clarify how this shouldwork.

Contributor

parafin commented on Nov 5, 2019

"system display profile" is indeed listed twice for some reason. But I can't reproduce the change in histogramwhen changing display profile. When soft-proofing or gamut check is enabled changing soft-proof profilechanges the histogram, but display profile still have to effect.

Member

TurboGit commented on Nov 5, 2019

@parafin : looking at the code "system display profile" is displayed twice when there is two displays.probably something to fix to be clearer.

Member

parafin commented on Nov 5, 2019

I tested on the system with only one display... Where is this code located?

Member

flannelhead commented on Nov 5, 2019

As far as I can tell, the profiles are initially loaded here: https://github.com/darktable-org/darktable/blob/master/src/common/colorspaces.c#L1253

Contributor Author

There both display_profile and display2_profile get assigned a category_pos number which makesthem appear in the histogram profile menu due to this code: https://github.com/darktable-org/darktable/blob/master/src/views/darkroom.c#L2048

I don't know the code very thoroughly, however it seems to me that display2 in darkroom.c at least refersto the "preview display profile", not a second display per se. https://github.com/darktable-org/darktable/blob/master/src/views/darkroom.c#L1986

Therefore it seems a bit illogical to have both display_profile and display2_profile added in thehistogram profile menu (notice that none of the other profile menus have "system display profile" listedtwice).

About the change of histogram and pixel values when changing the display profile: I can upload my profilelater today for examination. The change is not as clear with all profiles (this could be especially the case if thedisplay profile is very close to sRGB).

parafin commented on Nov 5, 2019

OK, I see now about 2 displays. I think they need to be distinguishable from each other here.

Member

flannelhead commented on Nov 5, 2019

HP E242 #2 2019-09-18 18-43 D6500 2.2 F-S XYZLUT+MTX.zip Here's the color profile I'm using. To use it in darktable, copy it to $HOME/.config/darktable/color/out (onLinux at least). Switching the display profile between this and sRGB in darktable should show a shift in the"dark" (low-EV) side of the histogram.

Contributor Author

flannelhead commented on Nov 5, 2019 •

If I'm reading the code right, the transformation to the histogram profile takes place in this block:

darktable/src/develop/pixelpipe_hb.cLines 958 to 969 in a94463b

958

959

960

Contributor Authoredited

{

img_tmp = dt_alloc_align(64, roi_in->width * roi_in->height * 4 * sizeof(float));

This transformation goes from the display profile to the histogram profile. So it seems either the inputimage for histogram calculation is coming from a part of the pixelpipe where the image has already beenconverted to display profile, or there is a mistake in this conversion.

Maybe this is a corner case, but there's an issue here at least in cases where the display profile doesn't coverthe whole gamut of the histogram profile (this is the case for my display profile) – some of the colorinformation is lost during the transition

working profile -> display profile -> histogram profile

if gamut of the display profile is a subset of the histogram profile.

Reading the release notes I would have intuitively expected the pipeline to be something along the lines of

/--> display profile -> displayed image working profile -| \--> histogram profile -> histogram, color picker, overexposure

By branching the conversion to display profile and histogram profile, one would avoid the loss of informationwhich is a likely root cause of the issue with the histogram and color picker values changing. What do youthink?

961

962

963

964

965

966

967

968

const dt_iop_order_iccprofile_info_t *const profile_info_from

= dt_ioppr_add_profile_info_to_list(dev, darktable.color_profiles->display_type,

darktable.color_profiles->display_filename, IN

const dt_iop_order_iccprofile_info_t *const profile_info_to

= dt_ioppr_add_profile_info_to_list(dev, histogram_type, histogram_filename, INTEN

dt_ioppr_transform_image_colorspace_rgb(input, img_tmp, roi_in->width, roi_in->height,

fil i f t "fi l hi t ")

flannelhead commented on Nov 5, 2019 •

One solution would be to branch the histogram calculation right before colorout , since very few modulesare placed after colorout in the default module order:

darktable/src/common/iop_order.cLines 302 to 310 in ad1110f

302

303

304

Contributor Authoredited

{ 69.0, "colorout"},

{ 70.0, "clahe"},

{ 71.0, "finalscale"},

305

306

307

308

309

310

As of now it seems to me that histogram calculation takes place in the pixelpipe just before the final gammaiop.

This would allow going directly from the (wide-gamut) working profile to the histogram profile and avoidexcess loss of color information.

This obviously has the effect that iops coming after colorout won't be reflected in the histogram oroverexposure indicators. Are there many such cases? One of those would probably be the application of a 3DLUT that is meant as an artistic filter working in the sRGB color space (probably a common case). It is a bitquestionable in this case, though, if the histogram after the artistic filtering is valuable information.

EDIT: I just noticed that the 3D LUT module lets one choose the application color space and does thenecessary conversions, so no need to put it after colorout in any reasonable workflow, it seems.

The overexposure indicators would also need special handling; the overexposed iop comes after coloroutand does a similar conversion as is done for the histogram:

darktable/src/iop/overexposed.cLines 138 to 157 in ad1110f

It is reasonable to have the indicators overlaid after colorout , however the source image would have tocome from the same path as the image used for the histogram (i.e. without applying the display profile inbetween). This is probably a bigger change than the one required just for the histogram.

138

139

140

141

142

143

144

145

146

147

148

{ 72.0, "overexposed"},

{ 73.0, "rawoverexposed"},

{ 74.0, "dither"},

{ 75.0, "borders"},

{ 76.0, "watermark"},

{ 77.0, "gamma"},

static void _transform_image_colorspace(dt_iop_module_t *self, const float *const img_in

const dt_iop_roi_t *const roi_in)

{

dt_colorspaces_color_profile_type_t histogram_type = DT_COLORSPACE_SRGB;

gchar *histogram_filename = NULL;

_get_histogram_profile_type(&histogram_type, &histogram_filename);

const dt_iop_order_iccprofile_info_t *const profile_info_from

= dt_ioppr_add_profile_info_to_list(self->dev, darktable.color_profiles->display_t

darktable.color_profiles->display_filename, IN

parafin commented on Nov 5, 2019 Member

Yep, PR #2069 didn't take into account the loss of information (smaller gamut) when converting to and fromdisplay profile. The problem here, as you gathered, is the fact that colorout iop is not necessarily the last inthe pipe. And current darktable pipe doesn't support branching like you proposed. Real solution is tohonestly do the conversion to selected export profile in colorout and convert to display profile after all iops.On the other hand this will effectively enable soft-proofing for export profile, which also might not bedesired. Unbounded colorspace conversions could have solved this issue, but not many color profiles aresuitable for it. So I'm afraid this bug is unfixable for now. Either hard-coding colorout to be in the end of the pipe orsupporting pipe branching is required here.

flannelhead commented on Nov 6, 2019

I'd tend to think it's not a bad compromise to calculate the histogram and overexposure indicators (andpicker values) before colorout . After all, in the default module order only these modules come aftercolorout :

darktable/src/common/iop_order.cLines 302 to 310 in ad1110f

302

303

304

305

306

307

308

309

310

clahe seems to be deprecated for a long time, finalscale is used only during export and not in thedarkroom (if I'm not mistaken), [raw]overexposed don't modify the image except for adding the indicatoroverlays, and dither shouldn't have much of an effect on the histogram. borders will add frames to theimage, but at least I wouldn't like to see them included in the histogram or shown as overexposed. Same forwatermark . Then comes gamma at which point the histogram is currently calculated (before applying gamma,

if I read correctly).

Contributor Author

{ 69.0, "colorout"},

{ 70.0, "clahe"},

{ 71.0, "finalscale"},

{ 72.0, "overexposed"},

{ 73.0, "rawoverexposed"},

{ 74.0, "dither"},

{ 75.0, "borders"},

{ 76.0, "watermark"},

{ 77.0, "gamma"},

parafin commented on Nov 6, 2019

Maybe. The problem is that pipe can be re-ordered.

Member

flannelhead commented on Nov 6, 2019 •

It would then be mostly a matter of properly documenting that modules after colorout won't be included inthe histogram calculation.

I think the recent push towards scene-referred workflow requires most of the users to rethink their workflowson some level. This consideration about colorout could be a natural part of the rethinking.

Contributor Authoredited

parafin commented on Nov 6, 2019

I agree on that point. But another issue is that you will be fixing only histogram. There are also 2 otherfeatures that requires similar fix - overexposed indicator and color picker. Overexposed iop should beprobably just moved before colorout, but fixing color picker might prove tricky.

Member

flannelhead commented on Nov 6, 2019

I had a brief look at overexposed – there's also rawoverexposed which takes its input from elsewhere than itsactual input image in the pixelpipe, so I think it could be feasible to do something similar for overexposed . Ican try to have a deeper look in this and the color picker later this week, but my gut feeling would be thatthis should not be too hard to fix.

Contributor Author

flannelhead commented on Nov 6, 2019

As far as I can tell, the picker values are calculated here in the same place as the histogram: https://github.com/darktable-org/darktable/blob/master/src/develop/pixelpipe_hb.c#L2479-L2507 Therefore it should not be too hard to move the post_process_collect_info to be executed with the inputimage of colorout instead of that of gamma . I can test this and open a PR for discussion if successful.

overexposed could be fixed in principle by moving it in the iop order right before colorout – obviously thenthe indicator colors can get transformed a little by colorout but that may not be too bad of a side effect(and by choosing the indicator colors to be within sRGB, it should be quite safe).

Contributor Author

parafin commented on Nov 6, 2019

My concern with colorpicker is coordinates - e.g. borders iop will change image dimensions, so I suspect itmay result in colorpicker getting information from a wrong place in the image.

Member

flannelhead commented on Nov 6, 2019

That's a good point. I'll have to keep an eye on that.

Contributor Author

flannelhead commented on Nov 12, 2019

Unfortunately it seems I can't promise to work on this issue during this year due to shortage of time. To helpothers possibly fix these two issues presented here (duplicate system display profile shown in the menusand the actual color space conversion issue), would it be helpful if I closed this ticket and filed two new oneswith clear descriptions?

Contributor Author

github-actions bot commented on Jan 24, 2020

This issue did not get any activity in the past 30 days and will be closed in 7 days if no update occurs. Pleasecheck if the master branch has fixed it since then.

github-actions bot added the no-issue-activity label on Jan 24, 2020

flannelhead commented on Jan 25, 2020

This seems to be still present on master ( ea956f408 which is the most recent one I built, but there havebeen no color-related changes since).

Contributor Author

The main annoyance for me here is the lift of the black values from (0, 0, 0) to (6, 6, 6) when a certain profileis selected. It makes the assessment of clipped values harder (although of course one can change thethreshold).

The display profile I'm using has a TRC like this (profiled using DisplayCal and a Spyder):

Notice that it doesn't touch the origin, which means pure black can't be represented by the monitor.However, it would be beneficial to see those values in number and in the histogram. Unfortunately this is notpossible since the roundtrip to the display profile in the pipe before taking the spot and histogram valuesloses the completely black tones.

Also other non-black color values are affected, supposedly due to loss of information when converting to thedisplay profile.

johnny-bit commented on Dec 22, 2020

There was recently a lot of work around histogram and color profiles... Can you check if you still have issueswith current master?

Also - your display has interesting profile if it lifts blacks like that...

Member

johnny-bit added reproduce: peculiar and removed no-issue-activity labels on Dec 22, 2020

sboukortt commented on Dec 22, 2020 •

Also - your display has interesting profile if it lifts blacks like that...

What do you mean? It’s quite typical for displays not to be able to display pure black. In general, onlygenerating a profile with black point compensation will produce a display profile that does not do that.

See: https://www.argyllcms.com/doc/CrushedDisplyBlacks.html

edited

👍 1

flannelhead commented on Dec 22, 2020

Hi @johnny-bit, thank you for following up!

Can you check if you still have issues with current master?

It seems indeed that I still can reproduce the issue (on master) using the profile attached earlier in the thread.However I also have a new profile for the same display, created with a different calibrator device. That profiledoesn't exhibit the same issue. Hence there might be something ill-defined about the attached profile. I cantry to do a comparison and see if I can find anything strange, however I'm not very familiar with ICC profilefiles so it might take some time to dig into. However, I attached both profiles for reference here.

profiles.zip

Contributor Author

sboukortt commented on Dec 22, 2020 •

The black point in profile_good.icc is quite a bit lower, enough to make the contrast ratio ~885:1 instead of575:1. That seems more realistic. (HP quotes 1000:1 for that model.)

edited

flannelhead commented on Dec 23, 2020

Yep, the new profile makes more sense to me too. The old one was made with an old Spyder which may wellhave been outdated.

Unless there's anything else clearly wrong about profile_bad.icc in the ZIP, I think the conclusion herewould be that the original issue still exists - the display profile definitely seems to affect the histogram, pickerand overexposure indicator readings. It does seem to slightly affect also midtones (for example, a differenceof one unit in the midtones), however the issue is the clearest in the blacks.

One thing I noticed; the effect is the strongest if the histogram profile is set to sRGB. If it's set to e.g. linearRec2020 or linear Rec709 (same primaries as sRGB but linear TRC) instead, the black point issue with the badprofile disappears. I remember Aurélien recommending several times on pixls.us to use a large-gamut space(such as the linear Rec2020) as the histogram profile to catch colors that go out of the visible light gamut.

Another thing; now if histogram profile is set to linear Rec2020 and the display profile is switched betweenany non-linear and linear profile (e.g. sRGB and linear Rec709), there's a change in the blacks (checked withe.g. a live color picker) - with lin Rec709 the RGB values may go negative, with sRGB they are clipped to (0, 0,0). This is interesting, and probably the non-linear tone response curve of the display profile is playing a rolein the pipe when calculating the histogram, color picker and overexposure indicator readings. Even if it reallyshouldn't.

Contributor Author

parafin commented on Dec 23, 2020

I think histogram still goes through display profile, so if transformation is not reversible (involves clamping),then it's expected to have an effect. Also precision may suffer due to multiple conversions. So I think thiseffect is a technical limitation of current implementation. See my previous comments above, I don't thinkanything changed since then. All those colorspace changes in histogram were about rendering the histogram,not computing it.

Member

johnny-bit commented on Dec 23, 2020

@dtorop - can you chime on here? Since you've done loads of work on histogram :)

Member

dtorop commented on Dec 23, 2020

@johnny-bit Uggh! Thank you for referencing this. Of the top of my head: I have to admit that I've noticed aswell that flipping display profile affects the histogram. It's been on my list to look at, and I should have madea bug report. My worst fear is that the histogram may be, if not meaningless, then at least not attached toany absolute reference.

Am skimming through the thread above. I've wondered for a while if the histogram (and color picker) should,instead of special case code in the pixelpipe, really be seen as special iops that save/send relevant data forthe colorpicker/histogram libs to display.

My recall is that the there is a good rationale for histogram/colorpicker work happening right before"gamma", perhaps that it is the last moment the data is unbounded floating point rather than clamped 8-bit.

I'll follow this through more carefully, ideally tonight. It does sound like this is a pixelpipe problem.

Contributor

❤ 2

flannelhead commented on Dec 23, 2020

@dtorop thank you for chiming in :)

Sadly, I noticed that the display profile also affects the clipping indicators in "full gamut" mode (and othermodes too). In a test image, I see far less gamut clipping when display profile is set to Linear Rec2020 versusthe actual display profile (or As far as I understand, the clipping indications shouldn't be affected by thedisplay profile at all if they worked as designed. I think this is the clearest indication of information losshappening due to going via the display profile.

Contributor Author

dtorop commented on Dec 24, 2020 Contributor

A lot to think through. I'm still not sure if what's going on is an architectural problem (e.g. an unanticipatedresult of converting from working profile -> display profile -> histogram profile), or if there's simply a bugsomewhere. I'm pretty shocked how much the histogram can jump depending on the display profile, butmaybe that's just a mark of how different a range of profiles can be.

It would be possible to make the code "fork" at colorout, such that preview pipe converts to display profileand scopes/indicators stay in working profile: make yet another pixelpipe type, DT_DEV_PIXELPIPE_SCOPE.That pipe would get passed through colorout unmodified and get converted to histogram profile at the lastpossible moment. I think current code would duplicate work in these pipes up to colorout. This seems like aninelegant solution. It may also produce bad information if there are any iops enabled after colorout.

Also, on the subject of multi-monitor, I've a memory that there is a bug such thatDT_SIGNAL_CONTROL_PROFILE_CHANGED doesn't get raised when it should be. I'm having troubleremembering the specifics.

dtorop commented on Dec 24, 2020

I keep going back to this being an argument for a "readout" iop. It would pull histogram/scope and colorpicker data. It would generate over/under exposure and gamut masks. It would have one user-modifiableparameter: readout profile, equivalent to current "histogram profile".

The readout iop would default to being just before colorout, so that it saw float data in working profile. If itwere pulled to after colorout, it could display a warning if the readout profile is different from the workingprofile (particularly if there was clamping or a linear->non-linear transform in colorout). If it was pulled to thestart of the pixelpipe, it could do the work of "raw overexposed". At other locations it could provideintermediary understanding of the pixelpipe.

The argument for this is to make the UI better reflect the underlying process, rather than, as now, have aleaky abstraction. It also would remove some special case code from dt_dev_pixelpipe_process_rec().

What I don't like is that it muddles the modules GUI, which is currently just about what is being done to theimage. (Even if modules overexposed, rawoverxposed, and gamma -- in ways invisible to the user -- breakthis pattern.)

Of course this may still just be a trivial bug somewhere, not an architectural/technical problem.

Contributor

TurboGit commented on Dec 24, 2020

The readout iop would default to being just before colorout

Member

Why no directly in colorout ? This will avoid having a new module and would be ok in there, no? You said thatreadout should be just before so the input of colorout could well be working to or if needed using the outputof colorout would "emulate" it being just after. I don't see why it should be in other places, but I could bewrong as this is an area where I'm no expect at all. And the "histogram profile" could be put there too, itmakes sense in colorout to me.

dtorop commented on Dec 24, 2020

@TurboGit This makes sense to me. This would simplify pixelpipe_hb.c and make lib/histogram.c principallyabout display rather than processing.

@flannelhead suggested this in #3271 (comment). There's a good back-and-forth with @parafin after that,including about pipe reordering. From @flannelhead:

It would then be mostly a matter of properly documenting that modules after colorout won't beincluded in the histogram calculation.

This sounds right.

Another possibility would be to continue to do this work in the pixelpipe, usually before colorout. Then in"histogram profile" have a "passthrough" setting to do the readout in display space right before gamma. Thiswould help in the case of someone putting a useful module after colorout and wanting to use the colorpickeron it. All this would need to be documented.

I'm happy to try to fix this. First check would be to see if moving the work to before colorout producesreadouts which vary with histogram profile but not with display profile.

Contributor

👍 1

dtorop added a commit to dtorop/darktable that referenced this issue 28 days ago

histogram: handle manually selected display profile fe57076…

dtorop mentioned this issue 28 days ago

histogram: handle manually selected display profile #7531 Merged

dtorop commented 28 days ago Contributor

It turns out that the histogram was ignoring any user-selected display profiles. This was a bug which I madein f1cd7fb . I made PR #7531 to fix this.

With #7531, changing the display profile keeps the histogram much more stable. It's still possible to choosedisplay profiles (esp. device-specific ones) which produce a notably altered histogram.

I'm now torn about whether it's worth doing the various readout work in colorout rather than right beforegamma. Advantages:

There should be no variation with display colorspace

It will be possible to see extreme values even if the display colorspace conversion is boundedIt moves some messy code out of the pixelpipe and into a module and removes some confusingconditionals from the pixelpipe

Disadvantages:

It changes long established darktable behavior

It's still possible to choose an unbounded display colorspace to see extreme valuesThe readouts will not see any data after colorout

It'll mean moving around a lot of code, and be an opportunity for more bugs

TurboGit linked a pull request that will this issue 27 days ago

histogram: handle manually selected display profile #7531 Merged

close

flannelhead commented 27 days ago •

Thank you for the reply and fix, @dtorop! Good to know there was an actual issue affecting the histogram.Also good analysis of the advantages and disadvantages of moving the readouts to an earlier point in thepipe. The change would most certainly be disruptive.

Somewhat related to the topic we're discussing here, there's a nice recent post by Aurélien on pixls.us: https://discuss.pixls.us/t/color-spaces-nightmares-gamut-clipping-wtf/22085

His take on the histogram makes me think perhaps we shouldn't overthink this matter here (at least withrespect to the histogram).

In what space to show histograms ? Any. It doesn’t matter. What we look for, when looking at histograms, is the spread. If you really want tosee the middle grey in the middle of the graph, then choose some space that has a power 2.4 as OETF,like sRGB. Although, the sRGB OETF has a linear slope for low-lights, and a power above, so it kind ofmesses up the spread.

Contributor Authoredited

But there are the over/underexposure indicators ("luminance only") and gamut indicators ("saturation only").I'm a bit concerned about the latter. What happens with the current code is that the image is mapped fromthe working profile (linear Rec2020) to display profile with some rendering intent (perceptual, I think?) As aresult any pixels that are out-of-gamut in the large working space are brought inside the display gamut bythe rendering intent. Later they are converted to histogram profile but they now have completely differentXYZ coordinates.

Then, if I would like to use the "saturation only" indicator to see if any areas are out-of-gamut in the workingspace (meaning that they probably aren't visible light or have imaginary colours) that's not possible unlessthe display profile is also changed to the working profile - actually, the "saturation only" mode won't showany oversaturated areas if the display profile is smaller than (and inside) the working profile. This can be agreat source of confusion if left undocumented.

Aurélien has a very good point that one should primarily use one's eyes and trust the image itself that isshown on the display, mainly judging it by the gradients. However, in some situations the luminance andsaturation indicators can be helpful, but only if they work predictably and correctly such that users know whatthey're looking at. Hence I think at the very least these features need further documentation.

I did a small test by moving the overexposed module right before colorout in the IOP order - it seems itcan be made to be independent of the display profile. I can post the patch a bit later.

Edit: I almost forgot there's also a dedicated gamut check mode (the "exclamation mark triangle" icon in thetoolbar) which paints out-of-gamut pixels cyan. That one seems to work correctly, obeying the softproofprofile without display profile affecting it. There's special handling for the gamut check in the coloroutmodule:

darktable/src/iop/colorout.cLine 458 in d4e5b6d

458 if(gamutcheck)

dtorop commented 27 days ago

Hi @flannelhead: Thanks for thinking this all out. I think you're right that at the least, it's worth documentingthat with the current setup, the path for readouts is:

working profile -> display profile -> histogram profile

And that this may produce surprising results (including to gamut) when the display profile is device specificand not "well behaved". What's wrong is that "display profile" is being used as a working space, but for manypeople, it won't be.

I'm OK with documenting this and moving on. Users can still flip "display profile" to a proper working space ifthey must see a more accurate histogram (and less accurate screen image).

Contributor

I haven't looked into moving overexposed before colorout , but given what you wrote #3271 (comment)and your test, it seems like it could work.

flannelhead commented 27 days ago

The current documentation actually says that the global color picker uses the display color profile: https://darktable-org.github.io/dtdocs/module-reference/utility-modules/darkroom/global-color-picker/

The global color picker works in monitor color space and takes its samples after the complete pixelpipehas been processed.

However the tooltip of the histogram profile menu tells otherwise:

histogram and color picker ICC profiles in

and I'm pretty sure that at least a year ago I read that the global color picker would use the histogram profile.Probably worth checking out which information is correct and fixing the related tooltips and documentation.

Re position of overexposed : if it's only a matter of moving the position of the IOP in the pipe, in principle itwould be possible to have a configurable default position for it. Something like what's being done with thelegacy/modern module order. However that would require making that module visible.

Besides documentation, probably something could be done to warn the user if such a combination of profilesis selected that has an undesirable effect on the readouts. Probably adds pretty complex logic though :/

Anyway, @dtorop, thank you very much chiming in on this!

Contributor Author

dtorop commented 27 days ago

Judging from current code, the colorpicker operates in the preview pipe just before gamma. It doesn'thappen at all if the currently expanded iop is "colorout" -- not sure why.

darktable/src/develop/pixelpipe_hb.cLines 2135 to 2142 in 6b58bc0

2135

2136

2137

2138

2139

2140

2141

Contributor

// Picking RGB for primary colorpicker output and converting to Lab

if(dev->gui_attached && pipe == dev->preview_pipe

&& (strcmp(module->op, "gamma") == 0) // only gamma provides meaningful RGB data

&& dev->gui_module && !strcmp(dev->gui_module->op, "colorout")

&& dev->gui_module->request_color_pick != DT_REQUEST_COLORPICK_OFF

&& darktable.lib->proxy.colorpicker.picked_color_rgb_mean && input) // colorpicker modu

{

The _pixelpipe_pick_primary_colorpicker() sets up a conversion from display profile to histogram profile(and from display profile to Lab). Then _pixelpipe_pick_from_image() does the conversion.

Hence the documentation is wrong and the tooltip is correct. The documentation is also off about the profileused for waveform or RGB parade. It also incorrectly states that the clipping indicator is calculated in outputcolor space. It is calculated in histogram color space.

I'll make a PR which corrects all this in the documentation. It'll also warn that the work -> display ->histogram transformation may lose data. I'll update the histogram profile fix to say that this issue is (fairly)closed.

Future work would be to move all the "readouts" (global color picker, clipping, and histogram) to just beforecolorout (probably not user configurable) and make sure that no image-modifying iops occur after colorout(hence they all will happen in work profile). This fix could also make the global color picker and histogramreadouts into their own iops (as with clipping/overexposed), to simplify the pixelpipe code.

2142 _pixelpipe_pick_primary_colorpicker(dev, (const float *const )input, &roi_in);

👍 1

dtorop mentioned this issue 27 days ago

histogram profile: clarify when it is used darktable-org/dtdocs#188 Merged

dtorop commented 27 days ago

Also, just to note: Both the histogram and overexposed processing convert the image to histogram profilethen throw this data away. For some memory/CPU savings when both are enabled, it could be possible tohold onto this data.

Contributor

dtorop added a commit to dtorop/darktable that referenced this issue 27 days ago

histogram: handle manually selected display profile 58a5b88…

TurboGit closed this in #7531 23 days ago

TurboGit added a commit that referenced this issue 23 days ago

Assignees

No one assigned

Labels

reproduce: peculiar

Projects

None yet

Milestone

No milestone

Linked pull requests

Successfully merging a pull request may close this issue.

histogram: handle manually selected display profile

7 participants

histogram: handle manually selected display profile 86b6f50…

flannelhead mentioned this issue 22 days ago

overexposed: fix and clean up color profile handling #7630 Merged