Re: non-color-scaled rgbimage plots

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

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, so it's more like

     if (GPVAL_VERSION >= "5.2") {
         set rgbmax 1.0;
         <scale the data to the range 0 to 1.0>
     else
         set cbrange [1:6.400000000000000e+01];
     end

where the latter is what Octave is currently doing because that's its 
scheme (data starts with 1, rather than 0).

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

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

Dan