Clipping indicator in Viewer as in FastPictureViewer

[akirot]

Despite having so many options I really miss a clipping indicator function in IMatch Viewer.
In FastPictureViewer I press the "C" ("C" as "Clipping") key and as long as it is pressed down the highlighted areas are marked in the image.
Could the very same option implemented in the IMatch viewer too, please?

[Mario]

What clipping do you mean? Cropping region? Highlights? Shadows?
I had that in IMatch 5 but when switching to hardware-based rendering. IMHO A DAM is not the right tool to check for clipped highlights and shadows, really.  That's what image editors are for, especially since there are many options which may affect which areas of your image are clipped.

[mastodon]

It might be useful in sorting. But a selection/sorting function would be a complete new feature.

[Mario]

I'm still not sure what kind of clipping is meant by the OP....

and as long as it is pressed down the highlighted areas are marked in the image.

highlighted because of what?

[sinus]

It might be useful in sorting. But a selection/sorting function would be a complete new feature.

But we have already selection/sorting.
In the viewer and also in the file window.

[Jingo]

I'm still not sure what kind of clipping is meant by the OP....

and as long as it is pressed down the highlighted areas are marked in the image.

highlighted because of what?

In FPV - if you hit the "C key - shows the "Burnt Highlights/Shadows (req. GPU)" [from keyboard shortcut cheat sheet] so sounds like it is clipped highlights and shadows.

[Mario]

What is considered a "clipped" HL/SH depends on the process, no?
And also which rule you apply. Do you consider only true black/white (RGB 0,0,0 or 255,255,255 + their respective 16-bit color-depth equivaents) as clipped? Surely not.
Most applications use a certain percentage from either edge or even a more complex algorithm to determine clipped pixels. It also depends on your process. Displaying clipped highlights / shadows on a RAW is pretty useless until you know what your RAW processor can recover. If you look at "final" images, the damage is already done and IMatch does not care much about this aspect of files.

I have removed the clip display from the Viewer over a year ago and nobody complained/asked to recreate it so far. It seems that this is nothing of great interest for most people. I may be wrong, as always. Lets see how many users comment on this. I dropped it because I've found it too complex to implement. Doing this in DirectX requires quite a bit more know-how than I currently have about this technology (I'm not a game/graphics developer) and learning all that stuff just to do my own shader for rendering on DirectX surfaces to indicate clipped pixels seems overkill to me...

[Jingo]

What is considered a "clipped" HL/SH depends on the process, no?
And also which rule you apply. Do you consider only true black/white (RGB 0,0,0 or 255,255,255 + their respective 16-bit color-depth equivaents) as clipped? Surely not.
Most applications use a certain percentage from either edge or even a more complex algorithm to determine clipped pixels. It also depends on your process. Displaying clipped highlights / shadows on a RAW is pretty useless until you know what your RAW processor can recover. If you look at "final" images, the damage is already done and IMatch does not care much about this aspect of files.

I have removed the clip display from the Viewer over a year ago and nobody complained/asked to recreate it so far. It seems that this is nothing of great interest for most people. I may be wrong, as always. Lets see how many users comment on this. I dropped it because I've found it too complex to implement. Doing this in DirectX requires quite a bit more know-how than I currently have about this technology (I'm not a game/graphics developer) and learning all that stuff just to do my own shader for rendering on DirectX surfaces to indicate clipped pixels seems overkill to me...

I wouldn't use such a feature - if this was a big interest for me, I would just open the files in FPV from IM and view the clipping that way.

[akirot]

Yes - I mean lost highlights/shadows.
I need this function to identify keepers (especially now after returning from a trip to snow and ice ;-) ).
The time before IMatch has been implemented on 64 bit I always used FPV for that (since I considered the IMatch viewer too slow compared with FPV). I could continue doing that but this would require rescans in IMatch which slows down the workflow as a whole.
Now I try to replace FPV by the IMatch viewer and identifying lost shadows/hihjlights is a function I miss.
To keep it simple: Most cameras can be configured to show clipped areas on their display (the then blinking areas). Technically this is almost always "wrong" since a jpg and not the raw is evaluated or only the green channel is taken into account... Nevertheless this is sufficient for my purpose.
So the IMatch Viewer should only evaluate what is displayed (the histogram works on the same basis as far as I understand). The thresholds per channel could be configured in the presets (e.g. 3 and 253 per channel or equivalent depending on the color depth of the file - so you Mario mustn't worry about further details).
Don't tell us it's too complicated ;-)

[Mario]

The complicated part is not the detection of the clipping, but to link into the high-speed WIC / DirectX render pipeline to process each pixel before it is displayed.
IMatch tries to stay out of the of way of this as much as possible, letting the GPU do what it can best.
I work with 80 MP files now often and this is a lot of data to move around so I can zoom and pan files with the normal IMatch Viewer speed.
To get in-between and re-color each pixel to show clipped shadows and highlights without sanctifying performance most likely requires me to learn how DirectX shaders work. And that's a complex matter. Usually only game developers or graphic developers have to deal with that. I don't even know how long this would take. I have a 800 pages book that just covers DirectX shader programming... q auick googling revealed only a lot of questions, but no real answers.

[sinus]

I have looked at this clipping thing maybe 10 times in my life.
I mean, sorry, but my monitor is well calibrated, and I am able to see with my eyes without some clipping stuff, if an image can be developped well or not, even if they are snow-images.

Don't tell me, akirot, that you are not able to do so. 

[Mario]

I find the clipping display on the camera monitor helpful, when you are setting up the lighting or while on the road. It is mandatory in a RAW processing application, of course.
For a DAM, it's maybe a nice to have, not more.

I'll keep this FR open so users can vote. Maybe when I find some time I'll look into the render pipeline and see how it can be done. Figuring out such things can take a day or a week...

[Jingo]

Yes - I mean lost highlights/shadows.
I need this function to identify keepers (especially now after returning from a trip to snow and ice ;-) ).
The time before IMatch has been implemented on 64 bit I always used FPV for that (since I considered the IMatch viewer too slow compared with FPV). I could continue doing that but this would require rescans in IMatch which slows down the workflow as a whole.
Now I try to replace FPV by the IMatch viewer and identifying lost shadows/hihjlights is a function I miss.
To keep it simple: Most cameras can be configured to show clipped areas on their display (the then blinking areas). Technically this is almost always "wrong" since a jpg and not the raw is evaluated or only the green channel is taken into account... Nevertheless this is sufficient for my purpose.
So the IMatch Viewer should only evaluate what is displayed (the histogram works on the same basis as far as I understand). The thresholds per channel could be configured in the presets (e.g. 3 and 253 per channel or equivalent depending on the color depth of the file - so you Mario mustn't worry about further details).
Don't tell us it's too complicated ;-)

So.. this brings up workflow... and another reason why I always cull/delete and process RAW files outside of IM - and then bring my finished images into the catalog.  This way - I use tools that were meant for these type of operations.. Capture One can easily show me this information and I'm going to be in that software to process them anyway.  Once the images are ingested and previews are loaded - the system is very fast.  Exported final files are then imported into IM and away we go!

[DigPeter]

-1

I cannot see the point of an indicator if nothing can be done about it.  As Mario says, the place for this is the editor, which i use for the vast majority of my images.

[ubacher]

-1 - should not be needed.

[bonsai]

-1
Not a task for a DAM