Re: non-color-scaled rgbimage plots

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

On Wednesday, 16 August, 2017 10:24:16 Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> >> "noautoscale" applies to the whole plot, does it not?
> >
> > It applies to only one component of the plot at a time.
> > The idea is so you can plot x, y, and z but only scale to fit y.
> > I.e. points from x and z may be outside the range defined by y.
> >
> >   plot 'x' noautoscale, 'y', 'z' noautoscale
> >
> >
> >> I think what would be most appropriate here is some sort of
> >> "origcolors" option applicable only to rgbimage/image data sources.
> >> So autoscaling would still apply, but would ignore "origcolors" data.
> >> Does that make sense?
> >
> > It makes sense for input RGB PNG images, but I am not certain it
> > generalizes.
> >
> > For that matter I'm not clear on what "autoscale" even means for
> > rgbimage data.  For image data it ends up controlling cbrange for
> > the palette mapping.  But for rgb images there is no palette, so
> > what exactly is being scaled?
> 
> I looked at the code, and have a sense of what's being done now.
> "noautoscale" currently does apply to rgbimage and image plots, but it
> only affects the spatial range, NOT the color range. For my use case
> (which is probably the most common use case), I'd want noautorange for
> the colors, but yesautorange for x,y. So how about a new option called
> "nocbautorange" to turn off just the color autoranging?
> 
> As for what's being scaled in palette-less rgbimages, it's the
> intensities of the R,G and B channels, controlled separately, I believe:
> look at the cb2gray() calls in process_image() in graphics.c. I doesn't
> obviously make sense to scale palette-based colors (from data) together
> with palett-less colors (in an rgbimage). Removing that logic entirely
> maybe makes the most sense, but I can imagine there're people out there
> that depend on this functionality, so maybe adding a "nocbautorange" is
> the right thing to do.

I agree that it makes no sense to apply the palette range (cbrange) 
to rgb data.
For example this just seems wrong to me:

    # looks nice
    plot 'nicepicture.jpeg' binary filetype=auto with rgbimage
    # messed up
    set cbrange [50:100]
    replot
    # lost altogether
    set log cb
    replot

So yes, cb2gray() should not be used for RGB data components.
Let's plan to replace it in 5.3 with a new routine rgb2gray(),
exact behaviour to be discussed.

Then the question becomes how or if to autoscale the rgb components.
And if we decide it should be under user control, should it be 
treated as an axis, 
	e.g. set rgbrange[0:255] 
or 3 or 4 separate axes
   e.g. set bluerange [0:1]; set alpharange [0:1] 
or a new set of non-axis commands
   set rgb {autoscale | 8bit_channels | grayscale}
or something else entirely.

If backward compatibility with current behaviour is a concern
(not sure it is in this case), then the default could be
to use the cbrange if the user has not set something else.

> 
> I think I want an option (or options) to
> 
> 1. Ignore rgbimage colors when finding the min/max for the autoscaling
> 
> 2. Ignore the computed cbrange scale when rendering the image: the
>    original image colors should be used instead
> 
> If "nocbautorange" works like "noautorange", it would only do #1, but
> maybe it should also do #2 as a special-case for rgbimage data.

My inclination is not to change the current commands that affect
cbrange, but instead to sever the connection between cbrange and
RGB image components.

Let's add this to the wishlist for 5.3 development.

	Ethan


> For grayscale images, we can read them in explicitly:
> 
>   plot "grayscale.png" binary filetype=auto flipy with image using 1
> 
> These DO end up using a palette, so probably "nocbautorange" should do
> #1, but not #2. If the user just wants to draw a background image, they
> should be instructed to plot this as an rgbimage:
> 
>   plot "grayscale.png" binary filetype=auto flipy with rgbimage
> 
> Makes sense? I'm out of town until next week, so the earliest I can send
> out a patch is late next week.