A while ago, I posted a question about taming halo artifacts and got some good responses. I keep experimenting with ways to tackle those, but in the process recently run into some unexpected behavior of the color picker module (which I haven’t used all that much before).
Below is a screenshot as an example (the image is zoomed in 1600%, which is a bit extreme, but makes it easier to illustrate the point). I know the color picker can be used in area mode and then is sampling the average color of the drawn rectangle. But below I’m using the default ‘point’ mode. I’m not sure, if it samples a single pixel under the cross-hair or a larger area - which might the crux of the matter - but it looks like the sampled colors don’t seem to be accurate and don’t pick up that green strip:
Looks more accurate and makes sense now that it doesn’t pick up the green, but still the sampled colors only make sense, if a larger area is sampled instead of a single pixel. Now the question is, is there a way to sample a smaller area or a single pixel?
If I use a color picker tool from my OS (Linux Mint), and sample the green line, a mostly green swatch readily shows up:
The picker acts on the preview pixel pipe which is sampled at lower resolution. I suspect the explanation for your observed behaviour is, that it still samples the cached preview instead of the actual zoomed in rendered pixels.
The picker value is not pixel perfect and it is averaged. This stems from its position in the pipeline (keeps the saved patch value consistent across render resolution) and helps even out super tiny variations in adjacent pixels of the same color (helpful if you want to select on those values).
It’s not only that: you may have the picker on an area that’s not visible in the main editor view. Normally, the main editing pipeline only renders what’s visible (unless you have HQ rendering turned on), so it would be impossible to update the picker. The preview pipe is used for other things, too, that need the whole image, like tone equalizer’s histogram, or the main histogram, and I think also haze removal (the latter now uses the main pipe, when in HQ mode, if I remember correctly, but that may be totally wrong; I’ll try and check later).
A couple of Github issues have previously been submitted about this behaviour: #9920, #17851
So we know why this behaviour happens, but it would be good if there was a way to force a super-accurate sampling, even if just temporarily. I am definitely one of those who will zoom in massively from time to time to sample a very specific colour. Sometimes averages over an area simply aren’t accurate enough or are tricky to capture.
This is not my area of expertise at all, so forgive me if it’s ridiculous, but if the pixelpipe is the root cause, could there be a way to generate a pseudo “export” of the relevant area of the image on the fly, similar to a raster mask, and sample that?
It’d be quite difficult, because of how the pipe works. There’s lots of legacy stuff in the architecture. They are there for a reason, and no solution is perfect; changing things that over 17 years of code built upon is hard.
The color picker reads values from the preview pipe (that causes the resolution/accuracy issues), which always covers the whole image. This is needed so it can display samples that are from areas that are not visible (outside the central view). The main view’s pipe, in HQ mode, processes the whole image at full resolution but then crops and scales the result down to just what’s on screen before the point where the picker reads values (finalscale, a non-exposed, technical module), so changing zoom would change whether you really read 1 pixel or the average of several, that got projected into one. To get stable, accurate values, the picker would have to be modified to sample at an earlier stage, before finalscale, but there data is still in pipe working space, so colour conversions would also be needed (a small issue, compared to the rest; BTW, this also means that at the current position, you are sampling values in monitor space, not export, so LUT and matrix + TRC display profiles could clip values; then that’s converted to histogram space, and that’s what you see).
And there’s some messing with the cache, which I don’t understand yet. But if I don’t go to sleep now, I won’t understand it tomorrow, either, so let’s stop here.
If my analysis (heavily leaning on Claude) is wrong, someone will hopefully correct me.
Thanks for the detailed explanations (more than I could ever have asked for).
It appears that the pixel pipe prevents single pixel sampling for the current implementation of the color picker. Would it theoretically be possible (not to put something on the plate of already busy developers…) to implement a color picker tool that would work similar to what the eye dropper tool of the OS is doing and simply sample a pixel of what’s displayed on the screen?
Just for my own curiosity: what’s the use of a single pixel’s value in a million ?
Sensors output a lot of pixels, how is one more relevant than all the other one.
Can’t speak for everyone, of course, but in my case and as shown in the example above, that green line is only a few pixels wide (but clearly visible at 100% or smaller). To selectively target the color of that line, e.g. with the ‘color lookup table’ module, can only be done with a color picker that targets a single pixel (a few more pixels would also do the trick here, but a single pixel is imho more practical at this point).
I agree with @Photoniker. If that pixel is different to the other million and happens to be the exact colour (or HSL) that you want, then its more relevant than all the others for your particular use case.
I agree that this is situational and not necessarily a top priority for anyone. But there are certainly times when I’ve needed to zoom in to pixel level to try and isolate an exact colour. One scenario I can think of is when you have some fringing, which can be a purple, cyan, red, or greenish colour. When the dedicated module doesn’t do a good enough job, I have tried to isolate the colour using parametric masks, and zooming in really close is needed.
In practice, you rarely need to sample an individual pixel, but often the area is very thin or tiny, so not easy to use the colour picker tool in its current form.
