rgbimage shift-rotates the image along the x-axis

[fredfriend]

Dear all,

I'd like to overplot data with gnuplot via "rgbimage". The image that is inserted is however always shift-rotated.

Normally I use 'with rgbimage' to import some graph of a published article, but here I'll talk about a 'silly' example:

As an example I generate a postscript file with gnuplot of y=sin(x). I crop the postscript file in Gimp (for instance) to remove the tick labels etc so that I'm left with the sin(x) plot and the borders (which run from -10<x<10 and -1<y<1). The cropped image is then saved as PNM image which I can read into gnuplot if I know the size in pixels.

Then I want to
plot "bla.pnm" binary array=639x887 format="%uint8" flipy not w rgbimage

and I get the following result:

 

please ignore the silly 90deg rotations of the axes, this is just due to the 'convert' program. The explanation is as follows:

The image is **properly** put from 0 to 639 on the X-axis and from 0 to 887 on the Y-axis. As you can see the top of the imported image (i.e. the top of the sine wave) is cut off and put below the bottom.

It is therefore 'shift-rotated' along the X-axis.

I looked at the imported image (the PNM) with different programs and there's no shift apparent in the image itself, so I think it's a gnuplot thing. I'm using gnuplot 4.3.0 and had this problem with several imported images from different sources.

Can anybody reproduce this error? Is this a bug of gnuplot?

any help would be much appreciated!

[fredfriend]

addition information to the report below:

I **can** properly plot the rgbimage in octave, even though this octave 3.2.0 uses exactly the same gnuplot binary.

(   in octave I simply do:  imshow('bla.pnm')   )

fredfriend wrote:

Dear all,

I'd like to overplot data with gnuplot via "rgbimage". The image that is inserted is however always shift-rotated.

Normally I use 'with rgbimage' to import some graph of a published article, but here I'll talk about a 'silly' example:

As an example I generate a postscript file with gnuplot of y=sin(x). I crop the postscript file in Gimp (for instance) to remove the tick labels etc so that I'm left with the sin(x) plot and the borders (which run from -10<x<10 and -1<y<1). The cropped image is then saved as PNM image which I can read into gnuplot if I know the size in pixels.

Then I want to
plot "bla.pnm" binary array=639x887 format="%uint8" flipy not w rgbimage

and I get the following result:

 

please ignore the silly 90deg rotations of the axes, this is just due to the 'convert' program. The explanation is as follows:

The image is **properly** put from 0 to 639 on the X-axis and from 0 to 887 on the Y-axis. As you can see the top of the imported image (i.e. the top of the sine wave) is cut off and put below the bottom.

It is therefore 'shift-rotated' along the X-axis.

I looked at the imported image (the PNM) with different programs and there's no shift apparent in the image itself, so I think it's a gnuplot thing. I'm using gnuplot 4.3.0 and had this problem with several imported images from different sources.

Can anybody reproduce this error? Is this a bug of gnuplot?

any help would be much appreciated!

[Hans-Bernhard Bröker-2]

fredfriend wrote:

> I'd like to overplot data with gnuplot via "rgbimage". The image that is
> inserted is however always shift-rotated.

No, it's just shifted, because you make incorrect assumption about the
contents of a PNM image file.

> The cropped image is then saved as PNM image

Strictly speaking, there is no such thing as saving an image as a PNM
file.  PNM is a family of three formats.  You save as either PBM, PGM or
PPM.

> I looked at the imported image (the PNM) with different programs and there's
> no shift apparent in the image itself, so I think it's a gnuplot thing.

You used all kinds of program that know about the PNM family of image
file formats.  But you told gnuplot that the file was a raw binary image
without _any_ format.  It's not, so you lied to gnuplot.  The behaviour
you see is the direct result of that lie.

The shift you see is the PNM file format header.  The way you told
gnuplot to read that file, it has to assume this header was part of the
image data.  It's not, and so all other file positions are off by its size.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
gnuplot-bugs mailing list
gnuplot-bugs@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-bugs

[fredfriend]

I'm sorry to learn that I've lied to gnuplot! This was never my intention.

Cutting off the header works indeed.

Part of the problem, to my opinion, is that I (any probably more users) don't know the differences between all these bitmap/pixmap types and the gnuplot manual is not very descriptive about how to tailor a given bitmap/pixmap so it gets accepted by gnuplot. It's probably not the role of gnuplot to describe file formats, but if it doesn't know what to do with the headers, where other programs do, then my conclusion (as a non-expert) is that gnuplot doesn't read (properly) PNM, PPM or whatever format.

So if gnuplot only accept images without the first (4) header lines, then I think it's a good thing to say/hint that in the manual.

Gnuplot is a very versatile and useful plotting program and I appreciate all the work done by all the authors!

and thank you for your fast response!

Hans-Bernhard Bröker-2 wrote:

fredfriend wrote:

> I'd like to overplot data with gnuplot via "rgbimage". The image that is
> inserted is however always shift-rotated.

No, it's just shifted, because you make incorrect assumption about the
contents of a PNM image file.

> The cropped image is then saved as PNM image

Strictly speaking, there is no such thing as saving an image as a PNM
file.  PNM is a family of three formats.  You save as either PBM, PGM or
PPM.

> I looked at the imported image (the PNM) with different programs and there's
> no shift apparent in the image itself, so I think it's a gnuplot thing.

You used all kinds of program that know about the PNM family of image
file formats.  But you told gnuplot that the file was a raw binary image
without _any_ format.  It's not, so you lied to gnuplot.  The behaviour
you see is the direct result of that lie.

The shift you see is the PNM file format header.  The way you told
gnuplot to read that file, it has to assume this header was part of the
image data.  It's not, and so all other file positions are off by its size.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
gnuplot-bugs mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/gnuplot-bugs

[Hans-Bernhard Bröker-2]

fredfriend wrote:

> Part of the problem, to my opinion, is that I (any probably more users)
> don't know the differences between all these bitmap/pixmap types and the
> gnuplot manual is not very descriptive about how to tailor a given
> bitmap/pixmap so it gets accepted by gnuplot.

Of course not.  There are virtually infinitely many image file formats,
most of which don't contain their data in a packed format that gnuplot
can't do anything with.  It would be madness to try and list recipes for
(all variations of) all of them.

> It's probably not the role of gnuplot to describe file formats, but
> if it doesn't know what to do with the headers, where other programs
> do, then my conclusion (as a non-expert) is that gnuplot doesn't read
> (properly) PNM, PPM or whatever format.

Well, guess what: it doesn't.  Did it promise otherwise?

> So if gnuplot only accept images without the first (4) header lines, then I
> think it's a good thing to say/hint that in the manual.

That's not what it does, so it would be wrong to put that in the manual.
  Gnuplot accepts raw binary image data.  If that's not what your input
is, it's up to you to find out how your image file can be transformed
into such a formats.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
gnuplot-bugs mailing list
gnuplot-bugs@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-bugs

[Hans-Bernhard Bröker-2]

fredfriend wrote:

> Part of the problem, to my opinion, is that I (any probably more users)
> don't know the differences between all these bitmap/pixmap types and the
> gnuplot manual is not very descriptive about how to tailor a given
> bitmap/pixmap so it gets accepted by gnuplot.

Of course not.  There are virtually infinitely many image file formats,
most of which contain their data in a packed format that gnuplot
can't do anything with.  It would be madness to try and list recipes for
(all variations of) all of them.

> It's probably not the role of gnuplot to describe file formats, but
> if it doesn't know what to do with the headers, where other programs
> do, then my conclusion (as a non-expert) is that gnuplot doesn't read
> (properly) PNM, PPM or whatever format.

Well, guess what: it doesn't.  Did it promise otherwise?

> So if gnuplot only accept images without the first (4) header lines, then I
> think it's a good thing to say/hint that in the manual.

That's not what it does, so it would be wrong to put that in the manual.
   Gnuplot accepts raw binary image data.  If that's not what your input
is, it's up to you to find out how your image file can be transformed
into such a formats.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
gnuplot-bugs mailing list
gnuplot-bugs@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-bugs


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
gnuplot-bugs mailing list
gnuplot-bugs@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-bugs