strange colormap behaviour with postscript printing

[Francesco Potortì]

octave> imagesc(peaks());colormap(gray())
octave> print("gray.png") # png image is good
octave> colormap(flipud(gray))
octave> print("udgray.png")     # png image is good
octave> colormap(gray)
octave> print("gray.ps")g")     # ps image is good
octave> colormap(flipud(gray))
octave> print("udgray.ps"))     # ps image is same as above!

Apparently, when printing to postscript, flipping the colormap has no effect!

--
Francesco Potortì (ricercatore)        Voice: [phone] (op.2111)
ISTI - Area della ricerca CNR          Fax:   [phone]
via G. Moruzzi 1, I-56124 Pisa         Email: Potorti@...
(entrance 20, 1st floor, room C71)     Web:   http://fly.isti.cnr.it/
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

On 25-Sep-2008, Francesco Potorti` wrote:

| octave> imagesc(peaks());colormap(gray())
| octave> print("gray.png") # png image is good
| octave> colormap(flipud(gray))
| octave> print("udgray.png")     # png image is good
| octave> colormap(gray)
| octave> print("gray.ps")g")     # ps image is good
| octave> print("udgray.ps"))     # ps image is same as above!
|
| Apparently, when printing to postscript, flipping the colormap has no effect!

Is this a bug in gnuplot, or are we somehow using it incorrectly?

I did

  imagesc(peaks());colormap(gray());
  colormap(flipud(gray))
  drawnow ("x11", "/dev/null", 0, "debug.gp");

to generate the attached file.  Then I edited the first two lines of
the file to change them from

  set terminal x11 enhanced title "Figure 1"
  set output "/dev/null";

to

  set terminal png
  set output "udgray.png"

and ran

  gnuplot debug.gp

to generate a png file that looks the same as what is displayed on
the screen.  Then I changed the first to lines of the file to be

  set terminal postscript
  set output "udgray.ps"

and the colors appear to be inverted.  I'm using gnuplot 4.2
patchlevel 2.  Can someone check to see whether this problem is fixed
in newer versions of gnuplot?  If not, please report the problem.

Thanks,

jwe



_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Ben Abbott]

On Friday, January 16, 2009, at 03:44PM, "John W. Eaton" <jwe@...> wrote:

>On 25-Sep-2008, Francesco Potorti` wrote:
>
>| octave> imagesc(peaks());colormap(gray())
>| octave> print("gray.png") # png image is good
>| octave> colormap(flipud(gray))
>| octave> print("udgray.png")     # png image is good
>| octave> colormap(gray)
>| octave> print("gray.ps")g")     # ps image is good
>| octave> print("udgray.ps"))     # ps image is same as above!
>|
>| Apparently, when printing to postscript, flipping the colormap has no effect!
>
>Is this a bug in gnuplot, or are we somehow using it incorrectly?
>
>I did
>
>  imagesc(peaks());colormap(gray());
>  colormap(flipud(gray))
>  drawnow ("x11", "/dev/null", 0, "debug.gp");
>
>to generate the attached file.  Then I edited the first two lines of
>the file to change them from
>
>  set terminal x11 enhanced title "Figure 1"
>  set output "/dev/null";
>
>to
>
>  set terminal png
>  set output "udgray.png"
>
>and ran
>
>  gnuplot debug.gp
>
>to generate a png file that looks the same as what is displayed on
>the screen.  Then I changed the first to lines of the file to be
>
>  set terminal postscript
>  set output "udgray.ps"
>
>and the colors appear to be inverted.  I'm using gnuplot 4.2
>patchlevel 2.  Can someone check to see whether this problem is fixed
>in newer versions of gnuplot?  If not, please report the problem.
>
>Thanks,
>
>jwe

My gnuplot was built from the developers sources a few weeks ago. I also see the colors as inverted (x11 and png are the same and ps is inverted).

I'll file a bug report tonight.

Ben


_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Dmitri A. Sergatskov]

On Fri, Jan 16, 2009 at 2:44 PM, John W. Eaton <jwe@...> wrote:

> On 25-Sep-2008, Francesco Potorti` wrote:
>
> | octave> imagesc(peaks());colormap(gray())
> | octave> print("gray.png")             # png image is good
> | octave> colormap(flipud(gray))
> | octave> print("udgray.png")           # png image is good
> | octave> colormap(gray)
> | octave> print("gray.ps")g")           # ps image is good
> | octave> print("udgray.ps"))           # ps image is same as above!
> |
> | Apparently, when printing to postscript, flipping the colormap has no effect!
>
> Is this a bug in gnuplot, or are we somehow using it incorrectly?
>
> I did
>
>  imagesc(peaks());colormap(gray());
>  colormap(flipud(gray))
>  drawnow ("x11", "/dev/null", 0, "debug.gp");
>
> to generate the attached file.  Then I edited the first two lines of
> the file to change them from
>
>  set terminal x11 enhanced title "Figure 1"
>  set output "/dev/null";
>
> to
>
>  set terminal png
>  set output "udgray.png"
>
> and ran
>
>  gnuplot debug.gp
>
> to generate a png file that looks the same as what is displayed on
> the screen.  Then I changed the first to lines of the file to be
>
>  set terminal postscript
>  set output "udgray.ps"
>
> and the colors appear to be inverted.  I'm using gnuplot 4.2
> patchlevel 2.  Can someone check to see whether this problem is fixed
> in newer versions of gnuplot?  If not, please report the problem.
>
> Thanks,
>
> jwe
>

I can confirm it with today's CVS snapshot.

Dmitri.
--
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Petr Mikulik]

> | octave> imagesc(peaks());colormap(gray())
> | octave> print("gray.png")          # png image is good
> | octave> colormap(flipud(gray))
> | octave> print("udgray.png")        # png image is good
> | octave> colormap(gray)
> | octave> print("gray.ps")           # ps image is good
> | octave> print("udgray.ps"))        # ps image is same as above!
> |
> | Apparently, when printing to postscript, flipping the colormap has no effect!
>
> Is this a bug in gnuplot, or are we somehow using it incorrectly?

Try
        colormap(rainbow)
instead of
        colormap(flipud(gray))
and you will see exactly the same result.
Try
        print('xxxx.ps', '-dpsc')
and you will see image with your desired color mapping.


The reason is that you are using a custom color map (COLOR map) which you
try to print to a monochrome postscript printer. Therefore gnuplot ignores
your specific color map and uses the default gray mapping instead
('set palette gray positive|negative gamma _gamma_').

You should print to color postscript to use a custom (Octave's) colormap.

In gnuplot, there is indeed an inconsistency of plots
        test
        splot x*y with pm3d
run under these situations:
        gnuplot # X11 color display
        gnuplot -gray # X11 gray display
        gnuplot -mono # X11 monochromatic display
and the same with postscript output
        set term postscript color
        set term postscript mono
Note that
        set term png
gives always a color output so that you cannot see any difference.

If gnuplot sends a custom color map to a monochrome postscript device, then
this would be considered as bug as well.

Any idea how to solve this ambiguity on gnuplot side?
I don't think this is very needed.


Octave could write an error message under this situation:

if any(any(colormap()-gray(rows(colormap())))) && is_mono_output
    fprintf('WARNING: using default gray mapping for printing on monochrome printer\n');
end


---
PM
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Ben Abbott]

On Jan 17, 2009, at 3:04 PM, Petr Mikulik wrote:

>> | octave> imagesc(peaks());colormap(gray())
>> | octave> print("gray.png")          # png image is good
>> | octave> colormap(flipud(gray))
>> | octave> print("udgray.png")        # png image is good
>> | octave> colormap(gray)
>> | octave> print("gray.ps")           # ps image is good
>> | octave> print("udgray.ps"))        # ps image is same as above!
>> |
>> | Apparently, when printing to postscript, flipping the colormap  
>> has no effect!
>>
>> Is this a bug in gnuplot, or are we somehow using it incorrectly?
>
> Try
> colormap(rainbow)
> instead of
> colormap(flipud(gray))
> and you will see exactly the same result.
> Try
> print('xxxx.ps', '-dpsc')
> and you will see image with your desired color mapping.
>
>
> The reason is that you are using a custom color map (COLOR map)  
> which you
> try to print to a monochrome postscript printer. Therefore gnuplot  
> ignores
> your specific color map and uses the default gray mapping instead
> ('set palette gray positive|negative gamma _gamma_').
>
> You should print to color postscript to use a custom (Octave's)  
> colormap.
>
> In gnuplot, there is indeed an inconsistency of plots
> test
> splot x*y with pm3d
> run under these situations:
> gnuplot # X11 color display
> gnuplot -gray # X11 gray display
> gnuplot -mono # X11 monochromatic display
> and the same with postscript output
> set term postscript color
> set term postscript mono
> Note that
> set term png
> gives always a color output so that you cannot see any difference.
>
> If gnuplot sends a custom color map to a monochrome postscript  
> device, then
> this would be considered as bug as well.
>
> Any idea how to solve this ambiguity on gnuplot side?
> I don't think this is very needed.
>
>
> Octave could write an error message under this situation:
>
> if any(any(colormap()-gray(rows(colormap())))) && is_mono_output
>    fprintf('WARNING: using default gray mapping for printing on  
> monochrome printer\n');
> end

As there is no routinesfor for the gnuplot backend that is  
simultaneously aware of the terminal type and whether or  not any of  
the figure's graphics objects are using a custom color map, I don't  
see any easy way to do that.

It may be necessary to make some compromise. We might (1) issue a  
warning even when the custom color map is not being used by any  
graphics objections, (2) force the use of -dpsc when a custom color  
map is set, or (3) leave the backend as it is.

Of those (1) looks more attractive to me.

Another possibility that occurs to me is to convert the custom color  
map to a monochrome version and have gnuplot respect that?

Petr, is that a possibility?

Ben



_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Ethan Merritt]

On Saturday 17 January 2009, Ben Abbott wrote:
> >
> >
> > The reason is that you are using a custom color map (COLOR map)  
> > which you
> > try to print to a monochrome postscript printer. Therefore gnuplot  
> > ignores
> > your specific color map and uses the default gray mapping instead
> > ('set palette gray positive|negative gamma _gamma_').


I think that gnuplot/postscript should honor a custom colormap
even if it is in monochrome mode, for the same reason that it
honors RGB colors even though it is in monochrome mode.
"set term post mono"  should set a default behaviour, but not
limit what the user can do via explicit commands.

So IMHO this really can be considered a gnuplot bug.

--
Ethan A Merritt

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Ben Abbott]

On Jan 17, 2009, at 6:51 PM, Ethan A Merritt wrote:

> On Saturday 17 January 2009, Ben Abbott wrote:
>>>
>>>
>>> The reason is that you are using a custom color map (COLOR map)
>>> which you
>>> try to print to a monochrome postscript printer. Therefore gnuplot
>>> ignores
>>> your specific color map and uses the default gray mapping instead
>>> ('set palette gray positive|negative gamma _gamma_').
>
> I think that gnuplot/postscript should honor a custom colormap
> even if it is in monochrome mode, for the same reason that it
> honors RGB colors even though it is in monochrome mode.
> "set term post mono"  should set a default behaviour, but not
> limit what the user can do via explicit commands.
>
> So IMHO this really can be considered a gnuplot bug.

For the case of a monochrome custom colormap, I share Ethan's opinion.

For the case of a RGB colormap, it might be a missing feature, but as  
converted from RGB to gray is a simple procedure I see no reason not  
support all custom colormaps when using the monochrome postscript  
terminal.

In any event, I have submitted a bug report.

        https://sourceforge.net/tracker2/?func=detail&aid=2516634&group_id=2055&atid=102055

Ben


_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Petr Mikulik]

> So IMHO this really can be considered a gnuplot bug.

It was designed this way when I have implemented pm3d; there were only gray
and rgbformulae palettes. The interpolated palette colours were added later.
So let us tell postscript to respect interpolated colour palette
preferentially to the colour/gray setting. Then the fix is a one-liner.

In postscript file, change
        Color true and
to
        Color InterpolatedColor or

The patch for gnuplot source code is on sourceforge.

> Another possibility that occurs to me is to convert the custom color map
> to a monochrome version and have gnuplot respect that?

With the above patch, any custom palette will keep the defined colours and
gnuplot will respect it.


I think that Octave could pass the custom colormap() through a "rgb2gray()"
function before printing to any monochromatic device (not just monochromatic
postscript). Then the plots
        print('mono.ps', '-dps')
        print('color.ps', '-dpsc')
will be same as in Matlab.

---
PM
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Ben Abbott]

On Jan 18, 2009, at 5:58 AM, Petr Mikulik wrote:

>> So IMHO this really can be considered a gnuplot bug.
>
> It was designed this way when I have implemented pm3d; there were  
> only gray
> and rgbformulae palettes. The interpolated palette colours were  
> added later.
> So let us tell postscript to respect interpolated colour palette
> preferentially to the colour/gray setting. Then the fix is a one-
> liner.
>
> In postscript file, change
> Color true and
> to
> Color InterpolatedColor or
>
> The patch for gnuplot source code is on sourceforge.
>
>> Another possibility that occurs to me is to convert the custom  
>> color map
>> to a monochrome version and have gnuplot respect that?
>
> With the above patch, any custom palette will keep the defined  
> colours and
> gnuplot will respect it.
>
>
> I think that Octave could pass the custom colormap() through a  
> "rgb2gray()"
> function before printing to any monochromatic device (not just  
> monochromatic
> postscript). Then the plots
> print('mono.ps', '-dps')
> print('color.ps', '-dpsc')
> will be same as in Matlab.
>
> ---
> PM

Petr,

I tried your patch

        http://sourceforge.net/tracker2/?func=detail&aid=2516634&group_id=2055&atid=102055

Unfortunately, 'mono.ps' and 'color.ps' inverted images (using the  
example below which accompanyied your patch).

        a=1./hilb(42);
        colormap(flipud(gray));
        imagesc(a); colorbar
        print('mono.ps', '-dps');
        print('color.ps', '-dpsc');

So it appears to me that the problem persists.

Ben
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Ben Abbott]

Ben Abbott wrote:

Petr,

I tried your patch

        http://sourceforge.net/tracker2/?func=detail&aid=2516634&group_id=2055&atid=102055

Unfortunately, 'mono.ps' and 'color.ps' inverted images (using the  
example below which accompanyied your patch).

        a=1./hilb(42);
        colormap(flipud(gray));
        imagesc(a); colorbar
        print('mono.ps', '-dps');
        print('color.ps', '-dpsc');

So it appears to me that the problem persists.

Ben

Quick update, Petr has added a second patch to sourceforge which resolves this problem for me.

If anyone else would like to test it, you can find the patch at the link below.

http://sourceforge.net/tracker2/index.php?func=detail&aid=2516634&group_id=2055&atid=102055

Ben

[Petr Mikulik]

I have patch gnuplot 4.2 and cvs so that it keeps the custom colour map
intact when printing to "postscript monochrome".

Now I propose that Octave is passing the colormap() through a "rgb2gray()"
function before printing to any monochromatic device (probably only "-dps"
and "-deps") so that the image will look the same whatever the drawing
backend is selected.

> >I think that Octave could pass the custom colormap() through a "rgb2gray()"
> >function before printing to any monochromatic device (not just monochromatic
> >postscript). Then the plots
> > print('mono.ps', '-dps')
> > print('color.ps', '-dpsc')
> >will be same as in Matlab.
>
> Unfortunately, 'mono.ps' and 'color.ps' inverted images (using the example
> below which accompanyied your patch).
>
> a=1./hilb(42);
> colormap(flipud(gray));
> imagesc(a); colorbar
> print('mono.ps', '-dps');
> print('color.ps', '-dpsc');

---
PM
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave