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
>