From: fredfriend <van...@il...> - 2009-09-16 13:08:13
|
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: http://www.nabble.com/file/p25472029/gnuplot.png 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! -- View this message in context: http://www.nabble.com/rgbimage-shift-rotates-the-image-along-the-x-axis-tp25472029p25472029.html Sent from the Gnuplot - Bugs mailing list archive at Nabble.com. |
From: fredfriend <van...@il...> - 2009-09-16 15:13:31
|
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: > > http://www.nabble.com/file/p25472029/gnuplot.png > > 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! > > > -- View this message in context: http://www.nabble.com/rgbimage-shift-rotates-the-image-along-the-x-axis-tp25472029p25474244.html Sent from the Gnuplot - Bugs mailing list archive at Nabble.com. |
From: Hans-Bernhard B. <HBB...@t-...> - 2009-09-16 21:31:11
|
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. |
From: fredfriend <van...@il...> - 2009-09-17 14:04:37
|
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 > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-bugs > > -- View this message in context: http://www.nabble.com/rgbimage-shift-rotates-the-image-along-the-x-axis-tp25472029p25491353.html Sent from the Gnuplot - Bugs mailing list archive at Nabble.com. |
From: Hans-Bernhard B. <HBB...@t-...> - 2009-09-17 15:58:24
|
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. |
From: Hans-Bernhard B. <HBB...@t-...> - 2009-09-17 16:06:51
|
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 gnu...@li... https://lists.sourceforge.net/lists/listinfo/gnuplot-bugs |