Re: non-color-scaled rgbimage plots

[Dima K. <gn...@di...>]

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

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.