Choice of display profile affects histogram, color picker values and overexposure indicators

[flannelhead]

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
4. Enable under/overexposure indicator
5. Observe there are no parts of the image indicated as underexposed (I have the underexposure threshold set at 2% which is the default)
6. Color picker also shows a minimum value of RGB = (6, 6, 6), at some point this becomes independent of 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 to reduce 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 a82f213ad14f17148cd5e9be3d909a372a3ad521

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

[junkyardsparkle]

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

[flannelhead]

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

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

[junkyardsparkle]

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

[flannelhead]

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 clipping indicator. 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. colord hasn't received updates recently either. Some KDE Plasma packages have been updated though, I'll continue investigating.

[flannelhead]

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

[flannelhead]

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

The first weirdness is that "system display profile" is listed twice in the "histogram profile" menu (right-click on 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 the darkroom. It controls the color space of the histogram, color picker and overexposed check. When gamut or softproof checks are active the histogram and color picker use the softproof profile, otherwise they 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 the histogram, over/underexposure checks or the color picker values in any way as the "histogram profile" setting is 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 "display profile" between "system display profile" and "sRGB", I see an evident change in the histogram, color picker values as well as the indicated over/underexposed regions. :(

Edited the title accordingly.

[junkyardsparkle]

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

[parafin]

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

[TurboGit]

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

[parafin]

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

[flannelhead]

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

There both display_profile and display2_profile get assigned a category_pos number which makes them 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 refers to 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 the histogram profile menu (notice that none of the other profile menus have "system display profile" listed twice).

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

[parafin]

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

[flannelhead]

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 (on Linux 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.

[flannelhead]

If I'm reading the code right, the transformation to the histogram profile takes place in this block: https://github.com/darktable-org/darktable/blob/a94463bc4b0a56e4133095f4172f1187b64cdd31/src/develop/pixelpipe_hb.c#L958-L969 This transformation goes from the display profile to the histogram profile. So it seems either the input image for histogram calculation is coming from a part of the pixelpipe where the image has already been converted 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 cover the whole gamut of the histogram profile (this is the case for my display profile) – some of the color information 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 information which is a likely root cause of the issue with the histogram and color picker values changing. What do you think?

[flannelhead]

One solution would be to branch the histogram calculation right before colorout, since very few modules are placed after colorout in the default module order: https://github.com/darktable-org/darktable/blob/ad1110f98ffccb826d7340ea9f0c94b223cea1b7/src/common/iop_order.c#L302-L310 As of now it seems to me that histogram calculation takes place in the pixelpipe just before the final gamma iop.

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

This obviously has the effect that iops coming after colorout won't be reflected in the histogram or overexposure indicators. Are there many such cases? One of those would probably be the application of a 3D LUT that is meant as an artistic filter working in the sRGB color space (probably a common case). It is a bit questionable 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 the necessary 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 colorout and does a similar conversion as is done for the histogram: https://github.com/darktable-org/darktable/blob/ad1110f98ffccb826d7340ea9f0c94b223cea1b7/src/iop/overexposed.c#L138-L157 It is reasonable to have the indicators overlaid after colorout, however the source image would have to come from the same path as the image used for the histogram (i.e. without applying the display profile in between). This is probably a bigger change than the one required just for the histogram.

[parafin]

Yep, PR #2069 didn't take into account the loss of information (smaller gamut) when converting to and from display profile. The problem here, as you gathered, is the fact that colorout iop is not necessarily the last in the pipe. And current darktable pipe doesn't support branching like you proposed. Real solution is to honestly 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 be desired. Unbounded colorspace conversions could have solved this issue, but not many color profiles are suitable for it. So I'm afraid this bug is unfixable for now. Either hard-coding colorout to be in the end of the pipe or supporting pipe branching is required here.

[flannelhead]

I'd tend to think it's not a bad compromise to calculate the histogram and overexposure indicators (and picker values) before colorout. After all, in the default module order only these modules come after colorout: https://github.com/darktable-org/darktable/blob/ad1110f98ffccb826d7340ea9f0c94b223cea1b7/src/common/iop_order.c#L302-L310

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

[parafin]

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

[flannelhead]

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

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

[parafin]

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

[flannelhead]

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

[flannelhead]

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 input image 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 then the 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).

[parafin]

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

[flannelhead]

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

[flannelhead]

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

[github-actions[bot]]

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

[flannelhead]

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

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

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 not possible since the roundtrip to the display profile in the pipe before taking the spot and histogram values loses the completely black tones.

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

[johnny-bit]

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

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

[sboukortt]

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, only generating a profile with black point compensation will produce a display profile that does not do that.

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

[flannelhead]

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 profile doesn't exhibit the same issue. Hence there might be something ill-defined about the attached profile. I can try to do a comparison and see if I can find anything strange, however I'm not very familiar with ICC profile files so it might take some time to dig into. However, I attached both profiles for reference here.

profiles.zip

[sboukortt]

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

[flannelhead]

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

Unless there's anything else clearly wrong about profile_bad.icc in the ZIP, I think the conclusion here would be that the original issue still exists - the display profile definitely seems to affect the histogram, picker and overexposure indicator readings. It does seem to slightly affect also midtones (for example, a difference of 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. linear Rec2020 or linear Rec709 (same primaries as sRGB but linear TRC) instead, the black point issue with the bad profile 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 between any non-linear and linear profile (e.g. sRGB and linear Rec709), there's a change in the blacks (checked with e.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 role in the pipe when calculating the histogram, color picker and overexposure indicator readings. Even if it really shouldn't.

[parafin]

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 this effect is a technical limitation of current implementation. See my previous comments above, I don't think anything changed since then. All those colorspace changes in histogram were about rendering the histogram, not computing it.

[johnny-bit]

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

[dtorop]

@johnny-bit Uggh! Thank you for referencing this. Of the top of my head: I have to admit that I've noticed as well that flipping display profile affects the histogram. It's been on my list to look at, and I should have made a bug report. My worst fear is that the histogram may be, if not meaningless, then at least not attached to any 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 for the 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.

[flannelhead]

@dtorop thank you for chiming in :)

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

[dtorop]

A lot to think through. I'm still not sure if what's going on is an architectural problem (e.g. an unanticipated result of converting from working profile -> display profile -> histogram profile), or if there's simply a bug somewhere. I'm pretty shocked how much the histogram can jump depending on the display profile, but maybe 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 profile and 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 last possible moment. I think current code would duplicate work in these pipes up to colorout. This seems like an inelegant 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 that DT_SIGNAL_CONTROL_PROFILE_CHANGED doesn't get raised when it should be. I'm having trouble remembering the specifics.

[dtorop]

I keep going back to this being an argument for a "readout" iop. It would pull histogram/scope and color picker data. It would generate over/under exposure and gamut masks. It would have one user-modifiable parameter: 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 it were pulled to after colorout, it could display a warning if the readout profile is different from the working profile (particularly if there was clamping or a linear->non-linear transform in colorout). If it was pulled to the start of the pixelpipe, it could do the work of "raw overexposed". At other locations it could provide intermediary understanding of the pixelpipe.

The argument for this is to make the UI better reflect the underlying process, rather than, as now, have a leaky 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 the image. (Even if modules overexposed, rawoverxposed, and gamma -- in ways invisible to the user -- break this pattern.)

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

[TurboGit]

The readout iop would default to being just before colorout

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

[dtorop]

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

@flannelhead suggested this in https://github.com/darktable-org/darktable/issues/3271#issuecomment-550198974. 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 be included 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. This would help in the case of someone putting a useful module after colorout and wanting to use the colorpicker on 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 produces readouts which vary with histogram profile but not with display profile.

[dtorop]

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

With #7531, changing the display profile keeps the histogram much more stable. It's still possible to choose display 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 before gamma. Advantages:

• There should be no variation with display colorspace
• It will be possible to see extreme values even if the display colorspace conversion is bounded
• It moves some messy code out of the pixelpipe and into a module and removes some confusing conditionals from the pixelpipe

Disadvantages:

• It changes long established darktable behavior
• It's still possible to choose an unbounded display colorspace to see extreme values
• The readouts will not see any data after colorout
• It'll mean moving around a lot of code, and be an opportunity for more bugs

[flannelhead]

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 the pipe. 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 with respect 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 to see 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 of messes up the spread.

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 from the working profile (linear Rec2020) to display profile with some rendering intent (perceptual, I think?) As a result any pixels that are out-of-gamut in the large working space are brought inside the display gamut by the rendering intent. Later they are converted to histogram profile but they now have completely different XYZ coordinates.

Then, if I would like to use the "saturation only" indicator to see if any areas are out-of-gamut in the working space (meaning that they probably aren't visible light or have imaginary colours) that's not possible unless the display profile is also changed to the working profile - actually, the "saturation only" mode won't show any oversaturated areas if the display profile is smaller than (and inside) the working profile. This can be a great 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 is shown on the display, mainly judging it by the gradients. However, in some situations the luminance and saturation indicators can be helpful, but only if they work predictably and correctly such that users know what they'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 it can 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 the toolbar) which paints out-of-gamut pixels cyan. That one seems to work correctly, obeying the softproof profile without display profile affecting it. There's special handling for the gamut check in the colorout module: https://github.com/darktable-org/darktable/blob/d4e5b6dfcd8a2aa8618dd7055bc98c4651b94521/src/iop/colorout.c#L458

[dtorop]

Hi @flannelhead: Thanks for thinking this all out. I think you're right that at the least, it's worth documenting that 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 specific and not "well behaved". What's wrong is that "display profile" is being used as a working space, but for many people, it won't be.

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

I haven't looked into moving overexposed before colorout, but given what you wrote https://github.com/darktable-org/darktable/issues/3271#issuecomment-550198974 and your test, it seems like it could work.

[flannelhead]

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 pixelpipe has 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 it would be possible to have a configurable default position for it. Something like what's being done with the legacy/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 profiles is 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!

[dtorop]

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

https://github.com/darktable-org/darktable/blob/6b58bc079e9474291ecaaffdeb974a210a4de3e7/src/develop/pixelpipe_hb.c#L2135-L2142

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 profile used for waveform or RGB parade. It also incorrectly states that the clipping indicator is calculated in output color 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 before colorout (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 histogram readouts into their own iops (as with clipping/overexposed), to simplify the pixelpipe code.

[dtorop]

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