Clipping warning - color scheme, color modes

[user0]

XnViewMP 1.11.5
Windows11 (25H2), display resolution 3840x2160, dpi scale 150%

Browser/Viewer

Clipping Warning Comparison

clipping_warning_comparison.jpg

Color scheme

mode	XnViewMP	Lightroom	Affinity Photo	Capture One	darktable	digiKam	RawTherapee	GIMP	ACDSee	Canon DPP	NX Studio	OM Workspace
Highlights	orange	red	red	red	red / black / purple	black	black (gradient)	red	red	red	8 colors	black (blinking)
Shadows	blue	blue	blue	blue	blue / white / green	white	white (gradient)	blue	green	blue	8 colors	white (blinking)
Channels	orange	-	yellow	-	red / black / purple	-	-	yellow	-	-	-	-

test_img_clipping.zip

Suggestion

• color modes
  looks like it works only on RGB images, like Affinity Photo
  would be consistent to have it for other modes as well, eg like in Lightroom, darktable, digiKam

• clipping threshold
  Highlights threshold looks in line with other apps, though it may be worth checking Lightroom's algorithm as well

• clipping color scheme
  Highlights should be red, not orange

• custom settings
  maybe add ability to customize colors/threshold (see example below)

Example

• Clipping/Exposure warning settings (digiKam, darktable, RawTherapee, GIMP)
  other_apps_settings_clipping_warning.png

Related

• suggestions
  Clipping warning - color scheme, color modes (current post)
  Menu - View - clipping warning & grid

[jkm]

Pierre asked me to address this, so I'll touch on a couple of points, although the original post looks more like a suggestion than a bug report.

• clipping color scheme
  Highlights should be red, not orange

No, they shouldn't.

Red is a mistake on Adobe's part, and some applications slavishly copy Adobe. Orange was used as the default for a good reason.

In real-world images, aside from sky, red is the most commonly clipped color due to over-saturation in digital photography. It is often clipped on flowers, signage, and clothing.

Due to a technical limitation, the clipping warning cannot blink in XnViewMP at this time...

A non-blinking red warning on blown red highlights would be invisible. Orange is almost never blown in real-world images, so orange was used to maximize visibility in the widest number of situations.

For visibility, red and white are the two worst colors to use for indicating blown highlights. (Fortunately, I've never seen anyone try to use sky-blue for this purpose.)

Regardless, this is a non-issue because the clipping colors can be customized by the user. So anyone that doesn't want red can just change it.

• custom settings
  maybe add ability to customize colors/threshold (see example below)

The ability to customize the colors and threshold already exists. This was covered in the documentation post. It's done in the INI file.
shadowClipping=2
shadowColor=0 0 255
highlightClipping=253
highlightColor=255 141 35

It's not done through the UI because Pierre didn't want to bother with adding more UI clutter for this, which would probably be set once and not changed. That was just a choice made for expediency, like the option to right-align counts in the catalog filter. I favor settings being in the GUI for ease of use.

[user0]

Red is a mistake on Adobe's part, and some applications slavishly copy Adobe. Orange was used as the default for a good reason.

you can think whatever you want, but red is the industry standard; orange is not. It's that simple.
The default color scheme should be consistent with that used by most other apps (red/blue/yellow)

Due to a technical limitation, the clipping warning cannot blink in XnViewMP at this time...

it should never blink
at most, it can use stripes (maybe slowly moving), like in GIMP

[jkm]

Red is a mistake on Adobe's part, and some applications slavishly copy Adobe. Orange was used as the default for a good reason.

you can think whatever you want, but red is the industry standard; orange is not. It's that simple.
default colors should be consistent with those used in all other apps

That's a lemming's argument.

I don't expect you to understand, because this is a feature for photographers, not forum readers.

As for red being an industry standard... None of the major camera manufacturers show highlights in red. They use black, black & white, or orange.

it should never blink
at most, it can use stripes (maybe slowly moving), like in GIMP

Stripes? I think the term you're looking for is Zebras.

But for photographers, blinking highlights are common. Canon, Nikon, Olympus/OM, and Fuji cameras all blink highlight warnings on screen.

Blinking makes it more visible. It also alerts users to the fact that something unusual is happening, to make them think, so it's less likely to go unnoticed. It also cuts down on the number of posts asking "why is part of my image red" which are rampant on Lightroom forums. So to say it should never blink is just foolish and inexperienced.

Pierre wanted me to explain why things were done the way they were. I've done that. Bye bye.

[user0]

I don't expect you to understand, because this is a feature for photographers, not forum readers.

sure, lol

As for red being an industry standard... None of the major camera manufacturers show highlights in red. They use black, black & white, or orange.
But for photographers, blinking highlights are common. Canon, Nikon, Olympus/OM, and Fuji cameras all blink highlight warnings on screen.

you clearly do not understand the difference between camera software running on a small camera screen in an outdoor environment and pc software displayed on a monitor

go and check Exposure clipping/warning functionality in:
- Canon Digital Photo Professional - red/blue
- Nikon NX Studio - 8 colors for both Highlights/Shadows (show only warning, hiding source image)
- Olympus OM Workspace - b&w + blinking
- Fujifilm X Raw Studio - functionality n/a (as far as I can see)

so, no orange and 1 blinking among 11 apps in total

Blinking makes it more visible. It also alerts users to the fact that something unusual is happening, to make them think, so it's less likely to go unnoticed.

developers of 10 out of 11 apps do not agree with you

It also cuts down on the number of posts asking "why is part of my image red" which are rampant on Lightroom forums. So to say it should never blink is just foolish and inexperienced.

typical skill issue

However, since XnView is not pure DAM app, Exposure warning state should be disabled by default after a restart, just like Zoom lock.
User should take some extra step for these features to remain enabled after restart, eg via option in Settings, flag in .ini or 'save session' feature that could (in theory) keep some settings.

Exposure warning state after restart in other apps:

• saved
  - ACDSee
  - Affinity Photo
  - Lightroom
  - Capture One
  - Canon DPP
  - darktable

• not saved
  - digiKam
  - FastRawTherapee
  - Nikon NX Studio
  - Olympus OM Workspace

[xnview]

However, since XnView is not pure DAM app, Exposure warning state should be disabled by default after a restart, just like

yes i'll add a setting