gnuplot-beta

non-color-scaled rgbimage plots

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

Hi. These days a common plotting use case for me is to draw an image
from a file, with some data plotted on top of it. I do something like
this:

  plot "xxx.png" binary filetype=auto flipy with rgbimage, "yyy" with points palette, ...

This works OK. There's an annoyance however: the points in "yyy" have a
3rd column, rendered as a color, and I want gnuplot to autoscale these
colors. But the pixels in "xxx.png" also have colors and gnuplot
interprets these colors as data too, and these 0-255 color values are
included in the autoscaling along with the 3rd column in "yyy". So for
instance, if the 3rd column in "yyy" is in [0-1], then the image is
plotted normally, but the "yyy" points all look black. Conversely, if
the points in "yyy" are in [10000-20000], then the points all look
yellow and the image is all black.

Is there a way to instruct gnuplot to just plot the image as is, without
trying to interpret the pixel colors as data? If not, can we add such an
option? The current behavior is definitely good for some use cases, but
not for all of them.

Re: non-color-scaled rgbimage plots

[sfeam <sf...@us...>]

On Monday, 14 August 2017 21:13:00 Dima Kogan wrote:
> Hi. These days a common plotting use case for me is to draw an image
> from a file, with some data plotted on top of it. I do something like
> this:
> 
>   plot "xxx.png" binary filetype=auto flipy with rgbimage, "yyy" with points palette, ...
> 
> This works OK. There's an annoyance however: the points in "yyy" have a
> 3rd column, rendered as a color, and I want gnuplot to autoscale these
> colors. But the pixels in "xxx.png" also have colors and gnuplot
> interprets these colors as data too, and these 0-255 color values are
> included in the autoscaling along with the 3rd column in "yyy". So for
> instance, if the 3rd column in "yyy" is in [0-1], then the image is
> plotted normally, but the "yyy" points all look black. Conversely, if
> the points in "yyy" are in [10000-20000], then the points all look
> yellow and the image is all black.
> 
> Is there a way to instruct gnuplot to just plot the image as is, without
> trying to interpret the pixel colors as data? If not, can we add such an
> option? The current behavior is definitely good for some use cases, but
> not for all of them.

gnuplot> stats 'yyy' using 3 prefix "COLOR"
gnuplot> plot 'xxx.png' binary filetype=auto with rgbimage, \
                'yyy' using 1:2:($3 * 255./COLOR_max) with points


This is not ideal since the color axis is still labeled [0:255]


Right now the program ignores the "noautoscale" keyword for image plots.
I'm not sure what would happen if that were to change.
If you experiment with the code, that's where I suggest starting.

	Ethan

Re: non-color-scaled rgbimage plots

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

sfeam <sf...@us...> writes:

> On Monday, 14 August 2017 21:13:00 Dima Kogan wrote:
>> Hi. These days a common plotting use case for me is to draw an image
>> from a file, with some data plotted on top of it. I do something like
>> this:
>>
>>   plot "xxx.png" binary filetype=auto flipy with rgbimage, "yyy" with points palette, ...
>>
>> This works OK. There's an annoyance however: the points in "yyy" have a
>> 3rd column, rendered as a color, and I want gnuplot to autoscale these
>> colors. But the pixels in "xxx.png" also have colors and gnuplot
>> interprets these colors as data too, and these 0-255 color values are
>> included in the autoscaling along with the 3rd column in "yyy". So for
>> instance, if the 3rd column in "yyy" is in [0-1], then the image is
>> plotted normally, but the "yyy" points all look black. Conversely, if
>> the points in "yyy" are in [10000-20000], then the points all look
>> yellow and the image is all black.
>>
>> Is there a way to instruct gnuplot to just plot the image as is, without
>> trying to interpret the pixel colors as data? If not, can we add such an
>> option? The current behavior is definitely good for some use cases, but
>> not for all of them.
>
> Right now the program ignores the "noautoscale" keyword for image plots.
> I'm not sure what would happen if that were to change.
> If you experiment with the code, that's where I suggest starting.

"noautoscale" applies to the whole plot, does it not? 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?

Re: non-color-scaled rgbimage plots

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

Ethan A Merritt <sf...@us...> writes:

>> > Right now the program ignores the "noautoscale" keyword for image plots.
>> > I'm not sure what would happen if that were to change.
>> > If you experiment with the code, that's where I suggest starting.
>>
>> "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

Interesting. The documentation describes the per-axis usage, but not the
per-data usage that you mention here. This is clearly the appropriate
option to hook into.


> 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?
>
> This is not a part of the code that I know very well.
> Right now I don't have any opinion on it because I don't really
> understand what it does now or what the other options might be.

OK. I'll take a look. For what it's worth, my images actually ARE
grayscale, but plotting them "with rgbimage" works while "with image"
does not. I'll look.

Thanks for the pointers.

Re: non-color-scaled rgbimage plots

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

On Tuesday, 15 August, 2017 12:39:23 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > On Monday, 14 August 2017 21:13:00 Dima Kogan wrote:
> >> Hi. These days a common plotting use case for me is to draw an image
> >> from a file, with some data plotted on top of it. I do something like
> >> this:
> >>
> >>   plot "xxx.png" binary filetype=auto flipy with rgbimage, "yyy" with points palette, ...
> >>
> >> This works OK. There's an annoyance however: the points in "yyy" have a
> >> 3rd column, rendered as a color, and I want gnuplot to autoscale these
> >> colors. But the pixels in "xxx.png" also have colors and gnuplot
> >> interprets these colors as data too, and these 0-255 color values are
> >> included in the autoscaling along with the 3rd column in "yyy". So for
> >> instance, if the 3rd column in "yyy" is in [0-1], then the image is
> >> plotted normally, but the "yyy" points all look black. Conversely, if
> >> the points in "yyy" are in [10000-20000], then the points all look
> >> yellow and the image is all black.
> >>
> >> Is there a way to instruct gnuplot to just plot the image as is, without
> >> trying to interpret the pixel colors as data? If not, can we add such an
> >> option? The current behavior is definitely good for some use cases, but
> >> not for all of them.
> >
> > Right now the program ignores the "noautoscale" keyword for image plots.
> > I'm not sure what would happen if that were to change.
> > If you experiment with the code, that's where I suggest starting.
> 
> "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?

This is not a part of the code that I know very well.
Right now I don't have any opinion on it because I don't really
understand what it does now or what the other options might be.


	Ethan

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.

Re: non-color-scaled rgbimage plots

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

Someone on Octave's bug tracker noticed a change in image color scaling 
behavior:

https://savannah.gnu.org/bugs/?52401


On 08/17/2017 03:54 PM, Dima Kogan wrote:
 > Ethan A Merritt <sf...@us...> writes:
[snip]
 >> 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.
 >
 > OK, that sounds like a plan. In the meantime I'm going to apply the
 > attached patch to my own builds. This detaches the rgb colors from the
 > palette entirely, both for autoscaling and for rendering. Works OK in
 > initial testing.

This patch/changeset divides by 255.0.  That assumes that the user has 
an image with 8-bit color depth, does it not?  (The cb-autoscaling takes 
assumptions about depth out of the equation.)  What happens if someone 
uses an image format that is different from 8-bit, such as newer JPEG 
with 12-bit depth?

https://www.popphoto.com/news/2014/01/jpeg-standard-91-will-bring-12-bit-color-lossless-compression

https://laurashoe.com/2011/08/09/8-versus-16-bit-what-does-it-really-mean/


On 08/16/2017 01:43 PM, Ethan A Merritt via gnuplot-beta wrote:
> On Wednesday, 16 August, 2017 10:24:16 Dima Kogan wrote:
>> Ethan A Merritt <sf...@us...> writes:
[snip]
> 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

Was it much different than this behavior?

gnuplot> splot sin(sqrt(x**2+y**2))/sqrt(x**2+y**2) with pm3d
gnuplot> splot 500*sin(sqrt(x**2+y**2))/sqrt(x**2+y**2) with pm3d
gnuplot> set cbrange [50:100]
gnuplot> replot

Autoscaling of cbrange is similar to mapping the histogram of the pixel 
colors into the usable range, but often one wants to change that range. 
For example, if one scans a newspaper article it often has yellowish 
tint but expanding the range will map the yellowish background to near 
white but still retain reasonably facsimile of the foreground image. 
XSane image scanner software (see attached) has just such a simple 
scaling to enhance contrast, etc.

https://en.wikipedia.org/wiki/Contrast_(vision)

Sure, one can apply a math formula to the image data input to do 
autoscaling and so on, but the same can be said for pm3d and other modes 
that use cbrange auto-scaling.

Dan

Re: non-color-scaled rgbimage plots

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

On Monday, November 13, 2017 12:45:02 PM PST Daniel J Sebald wrote:
> Someone on Octave's bug tracker noticed a change in image color scaling 
> behavior:
> 
> https://savannah.gnu.org/bugs/?52401
> 
> 
> On 08/17/2017 03:54 PM, Dima Kogan wrote:
>  > Ethan A Merritt <sf...@us...> writes:
> [snip]
>  >> 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.
>  >
>  > OK, that sounds like a plan. In the meantime I'm going to apply the
>  > attached patch to my own builds. This detaches the rgb colors from the
>  > palette entirely, both for autoscaling and for rendering. Works OK in
>  > initial testing.
> 
> This patch/changeset divides by 255.0.  That assumes that the user has 
> an image with 8-bit color depth, does it not?  (The cb-autoscaling takes 
> assumptions about depth out of the equation.)  What happens if someone 
> uses an image format that is different from 8-bit, such as newer JPEG 
> with 12-bit depth?

Answer 1:
gnuplot currently uses libgd to read in png or jpeg image files.
So far as I know libgd cannot handle any depth other than 8-bit, so
if you wanted to do this you'd have to re-write the input stage anyhow.
At that point you can do whatever you want about scaling.

Answer 2:
There is a new command "set rgbmax" that sets the range of the
color components to something other than 255.   That works for
reading in raw numbers or generating them in the using spec.
It does not, however, have any effect of the "binary filetype=foo"
options, since those are hard-coded.

	Ethan


> 
> https://www.popphoto.com/news/2014/01/jpeg-standard-91-will-bring-12-bit-color-lossless-compression
> 
> https://laurashoe.com/2011/08/09/8-versus-16-bit-what-does-it-really-mean/
> 
> 
> On 08/16/2017 01:43 PM, Ethan A Merritt via gnuplot-beta wrote:
> > On Wednesday, 16 August, 2017 10:24:16 Dima Kogan wrote:
> >> Ethan A Merritt <sf...@us...> writes:
> [snip]
> > 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
> 
> Was it much different than this behavior?
> 
> gnuplot> splot sin(sqrt(x**2+y**2))/sqrt(x**2+y**2) with pm3d
> gnuplot> splot 500*sin(sqrt(x**2+y**2))/sqrt(x**2+y**2) with pm3d
> gnuplot> set cbrange [50:100]
> gnuplot> replot
> 
> Autoscaling of cbrange is similar to mapping the histogram of the pixel 
> colors into the usable range, but often one wants to change that range. 
> For example, if one scans a newspaper article it often has yellowish 
> tint but expanding the range will map the yellowish background to near 
> white but still retain reasonably facsimile of the foreground image. 
> XSane image scanner software (see attached) has just such a simple 
> scaling to enhance contrast, etc.
> 
> https://en.wikipedia.org/wiki/Contrast_(vision)
> 
> Sure, one can apply a math formula to the image data input to do 
> autoscaling and so on, but the same can be said for pm3d and other modes 
> that use cbrange auto-scaling.
> 
> Dan
> 

Re: non-color-scaled rgbimage plots

[Petr M. <mi...@ph...>]

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

---
PM

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.

Re: non-color-scaled rgbimage plots

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

Ethan A Merritt <sf...@us...> writes:

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

OK, that sounds like a plan. In the meantime I'm going to apply the
attached patch to my own builds. This detaches the rgb colors from the
palette entirely, both for autoscaling and for rendering. Works OK in
initial testing.

Thanks

Re: non-color-scaled rgbimage plots

[sfeam <sf...@us...>]

On Thursday, 17 August 2017 13:54:44 Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > I agree that it makes no sense to apply the palette range (cbrange)
> > to rgb data.
> > 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.
> >
> 
> OK, that sounds like a plan. In the meantime I'm going to apply the
> attached patch to my own builds. This detaches the rgb colors from the
> palette entirely, both for autoscaling and for rendering. Works OK in
> initial testing.

[patch snipped]

Looks good to me.
I've applied it to 5.3 cvs.

	Ethan

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

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

Re: non-color-scaled rgbimage plots

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

On 11/14/2017 12:27 PM, Ethan A Merritt wrote:
> 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;
> }
> %%%%%%%%

I just read documentation:

"
gnuplot> help rgbmax
  Syntax:
       set rgbmax {1.0 | 255}
       unset rgbmax
  The red/green/blue color components of an rgbimage plot are by default
  interpreted as integers in the range [0:255].  `set rgbmax 1.0` tells the
  program that data values used to generate the color components of a plot
  with `rgbimage` or `rgbalpha` are floating point values in the range 
[0:1].
  `unset rgbmax` returns to the default integer range [0:255].
"

I see options 1.0 or 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.

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

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
> 

Re: non-color-scaled rgbimage plots

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

On 11/14/2017 03:19 PM, Ethan A Merritt wrote:
> 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".

Right, I'm pointing that out.  All were scaled with the same formula. 
You initially gave a counter example saying that if the Green channel is 
an all zero channel it is going to leach across color channels in some 
way.  There's nothing weird about the use of cb2range.  The palette 
didn't apply, not until someone wanted to combine palettes and images. 
The cb2gray() is just a linear transformation using the parameters 
cbaxis->min and cbaxis->max.  Call the function something more 
generalized, linearmap(), whatever.  And if the code were more 
object-oriented, the linearmap() routine could be applied to xyz-axis, 
colorbar, alpha channel, rgb, i.e., code reuse.

In terms of syntatx, it's more confusing to not continue the paradigm 
from one axis type to another.

Dan

Re: non-color-scaled rgbimage plots

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

On Tuesday, November 14, 2017 2:12:05 PM PST Daniel J Sebald wrote:
> On 11/14/2017 03:19 PM, Ethan A Merritt wrote:
> > 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".
> 
> Right, I'm pointing that out.  All were scaled with the same formula. 
> You initially gave a counter example saying that if the Green channel is 
> an all zero channel it is going to leach across color channels in some 
> way.  There's nothing weird about the use of cb2range.  The palette 
> didn't apply, not until someone wanted to combine palettes and images. 
> The cb2gray() is just a linear transformation using the parameters 
> cbaxis->min and cbaxis->max.  Call the function something more 
> generalized, linearmap(), whatever.  And if the code were more 
> object-oriented, the linearmap() routine could be applied to xyz-axis, 
> colorbar, alpha channel, rgb, i.e., code reuse.
> 
> In terms of syntatx, it's more confusing to not continue the paradigm 
> from one axis type to another.

We'll have to agree to disagree on that point.
I find it strange to consider RGB color assignments an "axis" at all.

Anyhow, I believe that the most common transformations applied to
color components are nonlinear and cannot be applied to a single
component in isolation, e.g. gamma-correction, color balance,
visual temperature.

min/max linear scaling is not a good model for color manipulation.

    Ethan