Re: non-color-scaled rgbimage plots

[Ethan A M. <sf...@us...>]

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;
}
%%%%%%%%

> 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.

> 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.

	Ethan