display_cheat

Cheat Home	Custom Cheat	Display Cheat	Debug Cheat	Array Cheat	Substitution Chet

Cheat #3: The -display Command Lies

TL;DR: -display does not preview your -output. For that, consider -display0.

You want to shrink and fade but preview before committing. "That's what display is for!" you think.

	Fade effect game plan: normalize in a narrow range around the image average (ia).
shrinkfade: -resize. 10%,10%,100%,100%,5 -normalize {0.7ia},{1.3ia}	shrink to ten percent, normalize to a narrow range around image average. A math expression finds that range around the predefined ia variable (for "image average").
	Now apply shrinkfade: gmic shrinkfade.gmic -input e_letter.png -shrinkfade -display Not faded ???

The results are not faded.

Check:	-shrinkfade is on the command line.	□
Check:	the command file itself has -normalize {0.7ia},{1.3ia}	□
Check:	G'MIC's very own processing log reports a narrow range	□

…min = 29750.1, max = 49583.6, mean = 41754.9,…

Conclusion:

G'MIC's broken (again!).

Angrily, you write an ALL CAPS post to the G'MIC developers: DO SUCH OBTUSE STUPIDITIES COME NATURALLY TO YOU GUYS OR DID YOU HAVE TO STUDY ?!?!?

The G'MIC developers shrug, (déjà vu all over again), pin the post to the wall under the rubric "display strikes again", then depart for a fine repast at La Cafétéria de l'ENSI or some other such gastronomic emporia like that.

The -display command implicitly normalizes items on image lists, a convenience that sows no end of confusion among new (and experienced) G'MIC users. The game -display tries to play is to give some indication of what an image may contain, given that an image may contain data that spans several orders of magnitude, that may not have any reasonable visualization at all. So, -display normalizes to a range that most desktop/laptop displays can handle: 8 bit-per-channel RGB. Technically, this is something of a Hail Mary pass that sometimes leads to ludicrous results.

Not Quite A Light Gray: [237,237,237]

The pipeline:

gmic -input 300,300,1,3,[237,237,237] -name. lightgray -display[lightgray]

produces a solid light RGB image that is a gray, as indicated by G'MIC's own output log:

[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input image at position 0, with values '[237,237,237]' (1 image 300x300x1x3).
[gmic]-1./ Set name of image [0] to 'lightgray'.
[gmic]-1./ Display image [0] = 'lightgray', from point (150,150,0).
[0] = 'lightgray':
  size = (300,300,1,3) [1054 Kio of floats].
  data = (237,237,237,237,237,237,237,237,237,237,237,237,(...),237,237,237,237,237,237,237,237,237,237,237,237).
  min = 237, max = 237, mean = 237, std = 0, coords_min = (0,0,0,0), coords_max = (0,0,0,0).

which leads you to believe that what you have produced is a light, solid gray image. Indeed, you have produced a light, solid gray image, but -display's necessary normalization strategy is deceived. Using the same mechanism that the normalize command uses, when confronted with an image that contains just one value — here, 237 — throughout, the display command has no basis to establish an input range, to which it can then map an output range! The H-L Normalizaton Relation says it all. Unable to distinguish an image minimum (im) from an image maximum (iM) — because all image values are the same — -display folds its tent rather than divide by zero. Lacking a 'mapping hint' like the normalize constant case ratio, the -display command punts and, for display purposes, maps the single value to the bottom of the putative output range, the zero of [0 → 255], which could work in some circumstances, but not this one. And so, trying to please (somehow!), -display lies.

Updated: 07-September-2021 11:05 UTC Commit: c85a4f425469

A Full-Featured Open-Source Framework for Image Processing

Latest stable version: 3.3.5 Current pre-release: 3.3.6 (2024/04/22)