Re: non-color-scaled rgbimage plots

[Daniel J S. <dan...@ie...>]

On 11/14/2017 12:27 PM, Ethan A Merritt wrote:
> On Tuesday, November 14, 2017 10:09:51 AM PST Daniel J Sebald wrote:
>> On 11/13/2017 05:45 PM, Petr Mikulik wrote:
>>>> Someone on Octave's bug tracker noticed a change in image color
>>>> scaling behavior:
>>>>
>>>> https://savannah.gnu.org/bugs/?52401
>>>
>>>
>>> Hm, it seems Octave needs to add this gnuplot command:
>>>
>>> if (GPVAL_VERSION >= "5.2") set rgbmax NNN
>>>
>>> where NNN is "size(colormap,1)"
>>
>> But the only options are rgbmax 1.0 and 255,
> 
> That is simply not true.  Here is the source:
> 
> set.c:4546
> %%%%%%%%%%
> static void
> set_rgbmax()
> {
>      c_token++;
>      if (END_OF_COMMAND)
>          rgbmax = 255;
>      else
>          rgbmax = real_expression();
>      if (rgbmax <= 0)
>          rgbmax = 255;
> }
> %%%%%%%%

I just read documentation:

"
gnuplot> help rgbmax
  Syntax:
       set rgbmax {1.0 | 255}
       unset rgbmax
  The red/green/blue color components of an rgbimage plot are by default
  interpreted as integers in the range [0:255].  `set rgbmax 1.0` tells the
  program that data values used to generate the color components of a plot
  with `rgbimage` or `rgbalpha` are floating point values in the range 
[0:1].
  `unset rgbmax` returns to the default integer range [0:255].
"

I see options 1.0 or 255.


>> However, the bigger issue is that the rgbimage/rgbalpha now have a
>> syntax not consistent with the gnuplot concept and they've lost the
>> autoscaling feature.  Recall, image/rgbimage/rgbalpha, these have more
>> to do with the underlying graphics library support (e.g., drawing with
>> PostScript's inherent image support as opposed to polygons as does pm3d).
>>
>> It sounds to me as though someone wanted to create more sophisticated
>> plots that combine images and colorbar data.  In other words, he wanted
>> to decouple the rgb data axes from the colorbar axis.
> 
> Correct.
> 
>> But that doesn't
>> mean there shouldn't be autoscaling of rgb axes, as that is what the
>> gnuplot paradigm is, whether it's spatial or color components.
> 
> There are no "rgb axes".
> And no, it does not make sense to autoscale RGB components of an image.
> Suppose you are displaying a photograph that for whatever reason does
> not contain any regions with Green==0.   Rescaling the Green component
> would distort all the colors everywhere, leaching the green out of things
> that really are green.  The _representation_ requires the range to run
> [0:255] even if this particular image doesn't happen to contain pixels
> with small Green component values.

rgb components aren't necessarily treated independently.  This code

-  image[i_sub_image++] = cb2gray( points[i_image].CRD_R );
-  image[i_sub_image++] = cb2gray( points[i_image].CRD_G );
-  image[i_sub_image++] = cb2gray( points[i_image].CRD_B );

was combining all component values into one.  Hence, if Red and Green 
channel was all zero, and Blue happened to have a range of 17 to 234, 
all components would be scaled to that range.  I don't think we'd want 
to treat components individually, at least by default, because that 
really distorts the color.  Only if all components are 0 would there be 
a scaling (likely to either all black image or all white image).


>> The most consistent syntax that retains features would have been an
>> rgbrange independent from cbrange, just as there is an xrange, yrange,
>> zrange, cbrange and to retain autoscaling for rgb (separate from cb
>> autoscaling).
> 
> I did consider that.  But I decided it was better not to confuse people
> because so many of the normal "set range" options would be
> invalid in this one case.

Here's what Matlab does

https://www.mathworks.com/help/matlab/ref/image.html

They appear to use the data type int8, int16, double, etc. to determine 
the range for RGB images:

double --> [0 0 0] black, [1 1 1] white
uint8  --> [0 0 0] black, [255 255 255] white
int8   --> [-128 -128 -128] black, [127 127 127] white
etc.

Interestingly, they treat the alpha channel ('scaled' option) similar to 
gnuplot's cbrange:

"
'AlphaDataMapping' — Interpretation of AlphaData values
'none' (default) | 'scaled' | 'direct'
'scaled' — Map the values into the figure’s alphamap. The minimum and 
maximum alpha limits of the axes determine the alpha data values that 
map to the first and last elements in the alphamap, respectively. For 
example, if the alpha limits are [3 5], then alpha data values less than 
or equal to 3 map to the first element in the alphamap. Alpha data 
values greater than or equal to 5 map to the last element in the 
alphamap. The ALim property of the axes contains the alpha limits. The 
Alphamap property of the figure contains the alphamap.
"

More generally, Matlab supplies adjustment for color images via a 
special function (example of a picture of a football given):

https://www.mathworks.com/help/images/ref/imadjust.html

"
RGB2 = imadjust(RGB,___) performs the adjustment on each plane (red, 
green, and blue) of the RGB intensity image RGB. You can apply the same 
mapping to the red, green, and blue components of the image or specify 
unique mappings for each color component.
"

with default being something called stretchlim(I).

In GIMP there is a wealth of color scalings; just import an image and 
look under "Colors" drop-down menu.  The majority of them are linear 
stretching of RGB, Hue/Lightness/Saturation in some form or another, and 
GIMP takes it one step further with arbitrary curve alteration.

If one were to search the Internet, there are probably other 
applications that can map image color components--at least linearly. 
(Searching will likely turn up more cases where "scale" refers to the 
spatial dimensions such as in autoscaling the size of an image in HTML 
browsers.)

Anyway, the point is that something like

   set rgbrange [A:B]

or even

   set rgbrange [A1,A2,A3:B1,B2,B3]

in gnuplot doesn't seem an unreasonable syntax.  (Note that gnuplot 
doesn't keep track of the input variable type.)  But I do agree with 
Matlab a bit that alpha channel seems like a different animal, so

   set alpharange [A:B]

seems logical as well, where with no alpha channel specified the default 
is that alpha for a particular RGB object is B.

Dan