Re: non-color-scaled rgbimage plots

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

On Tuesday, November 14, 2017 12:03:09 PM PST Daniel J Sebald wrote:
> On 11/14/2017 12:27 PM, Ethan A Merritt wrote:
> > 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.  

You lost me.
That code, which no longer exists, was copying the R G and B components
sequentially.  They were all being scaled by the same range from the
palette definition, which was weird since they are not palette colors.
There was no "combine into one".

The whole point of the change was to disentangle RGB colors from the
grayscale palette.

You are still free to scale RGB as you like in the current code, but 
you'll have to do it via explicit transforms in the using spec.

	Ethan


> 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
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>