Strange results from Display Filters>Clip Warning

[ajax]

As pretty much of a novice when it comes to digital image editing it seems like the idea of finding the portions of an image where clipping is occurring might be pretty basic.  It looks like this is done via View>Display Filters with the Clip Warning filter active.  I think I understand what Highlights and Shadows are but have no idea when it comes to Bogus Color.  I'd suppose that anything clipped might be considered Bogus.

When reading the help pertaining to Display Filters I find the following:

This filter allows to visualize underexposed and overexposed areas of a photo with user-configurable colors. For now, it’s mostly geared towards images where colors are stored with floating point precision. You will mostly benefit from this, if you work on 16-/32-bit per channel float images such as EXR and TIFF.

This is not very helpful.  Given that I'm working in 16 bit integer precision it comes across as something I ought not be using but surely I should be expected to want to know what is clipped.  How is that reconciled?

Furthermore, the strange results really arise when Clip Warning is Active and then View>Color Management>Soft Proof is also activated.  This seems to have the affect of turning the Magenta color used for out of gamut identification, when Soft Proofing, into Black which of course is a color that is not associated with either Clip Warning or Soft Proofing.  Black is also a pretty bad choice for any such warning since shadows that are NOT clipped include colors that are dark (i.e., nearly if not black).

I'm having a hard time finding any images that show some clipping when the Clip Warning is active.  This is true even though other software such as Rawtherapee does show fairly extensive clipping clipping on some of the same images.  Maybe this is what the documentation meant when saying "For now, ..." but does that also mean DO NOT USE GIMP for my scenario.

My thinking would be that the difference between Soft Proof and Clip Warning is what color profile is applied.  Soft proof should apply the profile associated with a specific choice of printer/paper/ink whereas Clip Warning would apply the profile for my display device which, by the way, has been calibrated.

Any elaboration that helps with the above dilemma will be appreciated.

[Ofnuts]

I confirm that the Clip Warning only works with floating point modes. As far as understand it, Clip Warning is about actual pixel values, whatever the color profile applied. "Bogus color" is pixels values that aren't valid floating point numbers (this can happen in some cases, for instance if you have a layer in "Divide" mode with color with a channel to 0 (black, or pure R,G,B)).

[ajax]

(09-22-2018, 08:23 PM)Ofnuts Wrote: I confirm that the Clip Warning only works with floating point modes. As far as understand it, Clip Warning is about actual pixel values, whatever the color profile applied. "Bogus color" is pixels values that aren't valid floating point numbers (this can happen in some cases, for instance if you have a layer in "Divide" mode with color with a channel to 0 (black, or pure R,G,B)).

While the method is a bit cumbersome (i.e., update preferences) the ICC Profile used for soft proofing can be changed.  While, I think, soft proof is intended to be used with printer profiles does it make any sense to specify the GIMP sRGB Working Profile instead?  The idea being that this would show out of gamut (both highlight and shadow) for the image displayed/edited using the working profile which is what I was expecting for Clip Warning.

Another possibility is that I simply don't understand the purpose of floating point precision.  Is it possible that floating point is what I should be using for editing even if my intention is to produce a 16bit (integer) TIFF format image file?

[Ofnuts]

The recommendation of the Gimp developers is that you use 32-bit floating point. This is the native format in which computations are done and is supposedly the fastest (it doesn't involve conversions). But of course it takes twice the RAM. For half that price, you have 16-bit integer or 16-bit floating point. I have yet to make up my mind about the benefits on one v.s. the other. The integer version could more accurately represent the values from a camera sensor but would be subject to round-off errors so this accuracy couldn't last.

[ajax]

When saying "it doesn't involve conversion", might you mean during the editing session/process?  It looks to me like I have to convert to 32bit floating point in order to put the image into that mode and then before exporting convert it back to some integer format if that is what I want (which I think might be necessary if I want a more universally supported image type).

However, when an image is converted to 32bit floating point precision I cannot get the color (magenta) specified for soft proofing to be used no matter what settings are specified for display filters.  It looks to be black which essentially makes detection of clipped shadows impossible.  In that, this is even worse than when I was editing in 16bit integer.

Based on comments above the fact that my computer is pretty well equipped with RAM caused me to like the idea of faster more efficient processing but this isn't going to work if I can't learn how to detect clipping.

Interestingly, it looks like this problem of using black for clipped pixels only applied to the preview that is being edited.  While tiny it looks like magenta is being used in the thumbnails.

[Ofnuts]

(09-23-2018, 06:57 PM)ajax Wrote: When saying "it doesn't involve conversion", might you mean during the editing session/process?  It looks to me like I have to convert to 32bit floating point in order to put the image into that mode and then before exporting convert it back to some integer format if that is what I want (which I think might be necessary if I want a more universally supported image type).

Yes, currently there internal conversions happening for at least some operations.

In 32-bit FP you can still export to the usual formats without an explicit conversion. The only problem is that there seem to be a hard-wired correspondance between image precision in Gimp and the bitness of the TIF file.

[ajax]

(09-24-2018, 12:06 PM)Ofnuts Wrote:

(09-23-2018, 06:57 PM)ajax Wrote: When saying "it doesn't involve conversion", might you mean during the editing session/process?  It looks to me like I have to convert to 32bit floating point in order to put the image into that mode and then before exporting convert it back to some integer format if that is what I want (which I think might be necessary if I want a more universally supported image type).

Yes, currently there internal conversions happening for at least some operations.

In 32-bit FP you can still export to the usual formats without an explicit conversion. The only problem is that there seem to be a hard-wired correspondance between image precision in Gimp and the bitness of the TIF file.

I would expect that exporting to JPG would require conversion to 8bit precision but apparently TIF allows for 32bit FP which creates a file about twice the size of a pretty big 16bit TIF.  Some viewers handle it others don't.  This, 32bit FP TIF, might be useful as an intermediate file but NOT very desirable for finished product.

Some more experiments involved intentionally developing a raw image to be way overexposed.  In that, plenty of clipped highlights which was then exported to a 16bit TIF.  This 16bit TIF is then opened in GIMP and Image>Precision>32bit FP selected.  I must admit that I don't know why I might choose Linear Light vs. Perceptual Gamma but for purpose of experiment tried both.  However, NO clipped highlights show up when trying the following:

• Turn on View>Display Filter>Clip Warning (CW)
  
• Turn off CW and try View>Color Management>Soft Proof (SP) using the ICC profile for my calibrated display
  
• Change SP to use ICC profile for printer/paper
  

Again, while there is no change in the main image (preview) view, it does look like SP (magenta) shows up in the thumbnail.

When I then convert it back to 16bit integer and SP now shows lots of clipped shadows but nothing for highlights when using the ICC profile for printer/paper.  Changing to the display profile shows a very little bit of clipped shadows but still nothing for highlights.

While I'm pretty sure that the 16bit integer TIF file had lots of clipped highlights GIMP does undertake a profile conversion when loading the file.  Doing the same thing but telling GIMP to KEEP the original profile when loading the file makes no difference.  Is it possible that when loading an image file clipped pixels are converted to something, such as a maximum/minimum value, that is not clipped and that the only way clipping occurs in GIMP is by applying tools (i.e., processing) that causes it?  When I open the overexposed file in Rawtherapee it has no problem recognizing and showing the clipping which of course it created.