Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2005-11-13 09:30:33
Attachments:
avs_image_13nov2005.patch
|
Ethan A Merritt wrote: > On Saturday 12 November 2005 06:26 pm, Daniel J Sebald wrote: > > >>If >>"convert" created a slightly more sophisticated format that contains the >>array dimensions and data point format, we could support that format. > > > You could write in an AVS input mode. > AVS format is xsize, ysize and then a stream of Alpha/Red/Green/Blue > pixels. > > Attached is a patch for AVS format (*.avs *.x). Here are some sample commands: set datafile binary filetype=auto plot "mandrill.x" binary with rgbimage Let me know how it works with the "convert" script strategy. Information about pixel width, height, image offset, etc. is of course lost using "convert" to avs file format. Those values would have to be specified at the command line if needed. And then there is the issue of monochrome images. [BTW, there may be a bug in the binary code. The command plot "mandrill.x" binary format='%*uchar%uchar%uchar%uchar' u 1+2+3 with image should work. But it doesn't seem to be doing the expected thing. I'll look for this later.] This comes with a no warranty. It is a start and I can do more in the future, but near term I'm very busy. If you have some tweaks, let me know. I used the test image at: http://astronomy.swin.edu.au/~pbourke/dataformats/avs_x/ and it looks correct, except I don't if the x-axis direction is correct. If you have images that you know after passing through convert come out the wrong x-direction, the following line of code in the patch: df_bin_record[0].scan_dir[0] = 1; should be changed to df_bin_record[0].scan_dir[0] = -1; Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-14 00:00:25
|
On Sunday 13 November 2005 01:36 am, Daniel J Sebald wrote:
>
> Attached is a patch for AVS format (*.avs *.x).
Very nice.
With some minor tweaking, I think this should go into cvs.
> Here are some sample commands:
>
> set datafile binary filetype=auto
> plot "mandrill.x" binary with rgbimage
Or in my case
set datafile binary filetype=avs
plot "< convert ~/images/photo.jpeg avs:-" binary with rgbimage
That works. But these variants don't:
set datafile binary filetype=avs
set style data rgbimage
plot "< convert ~/images/photo.jpeg avs:-" with rgbimage
warning: Skipping data file with no valid points
x range is invalid
plot "< convert ~/images/photo.jpeg avs:-" binary
Read grid of zero width
I don't think these failures have anything to do with the patch,
however. I think the binary and rgbimage modes are not correctly
picked up from the default style in any case.
> This comes with a no warranty.
> If you have some tweaks, let me know.
Unfortunately, AVS format does not guarantee any particular byte order.
You normally get whatever byte order is native to the machine the image
was created on. Therefore any application that reads AVS images should
check for sanity of the xwidth and ywidth values at the head of the file,
and try a different byte ordering if they are absurd.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2005-11-14 01:02:31
|
Ethan A Merritt wrote: > On Sunday 13 November 2005 01:36 am, Daniel J Sebald wrote: > >>Attached is a patch for AVS format (*.avs *.x). > > > Very nice. > With some minor tweaking, I think this should go into cvs. > > >>Here are some sample commands: >> >>set datafile binary filetype=auto >>plot "mandrill.x" binary with rgbimage > > > Or in my case > set datafile binary filetype=avs > plot "< convert ~/images/photo.jpeg avs:-" binary with rgbimage > > That works. But these variants don't: > set datafile binary filetype=avs > set style data rgbimage > plot "< convert ~/images/photo.jpeg avs:-" with rgbimage > warning: Skipping data file with no valid points > x range is invalid > plot "< convert ~/images/photo.jpeg avs:-" binary > Read grid of zero width > > I don't think these failures have anything to do with the patch, > however. I think the binary and rgbimage modes are not correctly > picked up from the default style in any case. OK, these are the problems I was running into and concluded there is some bug floating around here. Thanks. I'll look into it. > Unfortunately, AVS format does not guarantee any particular byte order. Actually, according to this: http://astronomy.swin.edu.au/~pbourke/dataformats/avs_x/ "the format assumes a byte ordering as per SGI/MACIINTOSH/Motorola processors" > You normally get whatever byte order is native to the machine the image > was created on. Therefore any application that reads AVS images should > check for sanity of the xwidth and ywidth values at the head of the file, > and try a different byte ordering if they are absurd. So, I think this is covered by the following two lines in the patch: + df_bin_file_endianess = DF_BIG_ENDIAN; + read_order = byte_read_order(df_bin_file_endianess); The first line indicates that the file is big endian (Mac/SGI/Motorola) by definition and the next line determines what type of swapping (if any) is needed based upon the computer's endianess. Then after reading in the xwidth/ywidth there is + df_swap_bytes_by_endianess((char *) &M, read_order, 4); + df_swap_bytes_by_endianess((char *) &N, read_order, 4); which swaps according to little/big/middle endian if the format doesn't match that of the CPU. Dan |
|
From: Petr M. <mi...@ph...> - 2005-11-13 13:10:51
|
>> Indeed. In fact, we should not add any code at all to gnuplot >> if the conversion can be done externally. And it can, easily. >> Since ImageMagick can convert almost anything to a raw RGB stream, >> I'd think you can do it now with no extra code at all: >> >> plot "< convert pic.jpeg rgb:-" with image >> >> If you need to tweak the code to make that work, then please >> do so and post a patch. If it works already, just contribute >> some documentation. > > This of course is a good solution. What is necessary are two things: > > A good documentation how to use this, and for Windows users who will not > know a programme that outputs rgb data, a clear description how the input I don't agree this is a good solution. This form plot "< convert pic.jpeg rgb:-" PLENTY OF OPTIONS with image is really ugly and user unfriendly. I propose gnuplot reads png, gif and jpeg files directly using the GD library. This won't add any new code into gnuplot but it will make this feature portable to gnuplot for Windows, for OS/2, for Mac. The ImageMagick is usually installed on modern Linux systems, but I doubt for elsewhere. Look at zimg, which can also read directly these files thanks to the GD library (right, Johannes?): --- PM |
|
From: Daniel J S. <dan...@ie...> - 2005-11-13 18:22:11
|
Petr Mikulik wrote: > > I don't agree this is a good solution. This form > plot "< convert pic.jpeg rgb:-" PLENTY OF OPTIONS with image > > is really ugly and user unfriendly. The master of scripts bucks the trend. :-) > I propose gnuplot reads png, gif and > jpeg files directly using the GD library. This won't add any new code > into gnuplot but it will make this feature portable to gnuplot for > Windows, for OS/2, for Mac. So that I understand, you're saying that all the routines that would make it easy to read png/gif/jpeg are already present in gnuplot because of the library's use for generating these types of outputs on the terminal side? Then sure, it is probably wise to support those directly, Petr. I like that idea. I like both ideas, really. I'd say add the AVS support. (It's only 20-30 lines of code.) And put the script along with the other scripts on the web page. I don't think one escapes the PLENTY_OF_OPTIONS problem with png/gif/jpeg because there too there is no information about image position, pixel spacing, and so on. I think the primary reason for a person to put an image into gnuplot is to provide axes, annotation and that sort of thing, requiring more details than just the image. The EDF format is the most complete format I've seen; I'm sure there are others. So, those familiar with png/gif/jpeg, are there issues of convenience here for annotation? Dan |
|
From: Petr M. <mi...@ph...> - 2005-11-13 19:10:04
|
>> I don't agree this is a good solution. This form >> plot "< convert pic.jpeg rgb:-" PLENTY OF OPTIONS with image >> >> I propose gnuplot reads png, gif and jpeg files directly using the GD >> library. This won't add any new code into gnuplot but it will make this >> feature portable to gnuplot for Windows, for OS/2, for Mac. > > So that I understand, you're saying that all the routines that would make it > easy to read png/gif/jpeg are already present in gnuplot because of the > library's use for generating these types of outputs on the terminal side? Exactly. > I like both ideas, really. I'd say add the AVS support. (It's only 20-30 > lines of code.) OK with me. > I don't think one escapes the PLENTY_OF_OPTIONS problem with png/gif/jpeg > because there too there is no information about image position, pixel > spacing, and so on. I think the primary reason for a person to put an image > into gnuplot is to provide axes, annotation and that sort of thing, requiring > more details than just the image. Yes, the user can add these additional options. > So, those familiar with png/gif/jpeg, are there issues of convenience here > for annotation? Perhaps we can have one additional penguin from the "with image" demo in a png file instead of an .rgb. Actually, scanned images (e.g. from microscopes) are usually in .tiff, so converting them into png and adding axes and label by gnuplot is an example of an application of png files. --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-13 18:36:05
|
On Sunday 13 November 2005 10:29 am, Daniel J Sebald wrote: > I don't think one escapes the PLENTY_OF_OPTIONS problem with > png/gif/jpeg because there too there is no information about image > position, pixel spacing, and so on. I think the primary reason for a > person to put an image into gnuplot is to provide axes, annotation and > that sort of thing, requiring more details than just the image. I don't think we'll get very far on choosing a solution until we agree on what the problem is. Why, indeed, would anyone want to read in a jpeg image into gnuplot? I'd like to have a real application in mind before trying to guess the best way to support it. > So, those familiar with png/gif/jpeg, are there issues of convenience > here for annotation? Not sure I understand the question. You mean the application would be to use gnuplot to overlay a plot onto an existing image? That would be totaly backwards. Surely the straightforward path is to create a gnuplot plot, then read both the plot and the image into ImageMagick/GIMP/Photoshop to align, scale, and composite? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2005-11-13 19:54:48
|
Ethan A Merritt wrote: >>So, those familiar with png/gif/jpeg, are there issues of convenience >>here for annotation? > > > Not sure I understand the question. You mean the application would > be to use gnuplot to overlay a plot onto an existing image? > That would be totaly backwards. Surely the straightforward path > is to create a gnuplot plot, then read both the plot and the > image into ImageMagick/GIMP/Photoshop to align, scale, and composite? Yeah, how are people going to use this? My use is raw monochrome spectrogram images, time annotated along one axis, frequency along the other. I think of jpeg as being some kind of final image format for use in documents, html, etc. On the other hand, it wouldn't be too absurd to use a jpeg image as a portion of a plot. Say I've some quantitative data from a particle accelerator experiment and in one of the corners of the plot want to have the collision photo it corresponds to. Or say a company/lab has its trademark in jpeg format and wants to put it in the corner of a plot. Dan |
|
From: Harald H. <h.h...@tu...> - 2005-11-13 20:57:01
|
On Sun, 13 Nov 2005, Ethan A Merritt wrote:
> On Sunday 13 November 2005 10:29 am, Daniel J Sebald wrote:
> > I don't think one escapes the PLENTY_OF_OPTIONS problem with
> > png/gif/jpeg because there too there is no information about image
> > position, pixel spacing, and so on. I think the primary reason for a
> > person to put an image into gnuplot is to provide axes, annotation and
> > that sort of thing, requiring more details than just the image.
>
> I don't think we'll get very far on choosing a solution until we
> agree on what the problem is. Why, indeed, would anyone want to
> read in a jpeg image into gnuplot? I'd like to have a real application
> in mind before trying to guess the best way to support it.
Quite frequently, I want to "steal" data from scanned plots. There,
something like
set label picture 'filename.jpg' back at ...
would really be convenient.
Other applications could be company logos to be included into the plot, as
for example the FEA code ABAQUS does in the self-produced plots.
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-14 17:04:38
|
On Monday 14 November 2005 03:38 am, Jonathan Thornburg wrote:
> On Fri, 11 Nov 2005, Ethan A Merritt wrote:
> >>> set size 2,2
> > ^^^^^^^^^^^^^
> > Don't do that.
>
> This leaves unanswered the question of what's the "right" way to
> produce a postscript file whose natural size when printed/viewed is
> larger than the default (in either x and/or y). Until there's an
> alternative mechanism
Sorry, I should have posted a specific announcement here as well as
to the SourceForge tracking list.
Please give a thorough workout to SourceForge patch #1356114
set term post size <foo>in,<baz>in
Also handles units of cm or pixels.
Here is a repeat announcement
Initial Comment:
Enough talking about it, here is actual code.
Synopsis
========
Specify explicit bounding box for postscript-based
terminals in inches, centimeters, or points.
e.g. default is equivalent to
set term post size 10in, 7in
Details
=======
Adds a parsing routine parse_term_size(*x, *y,
default_units) that can be called by any terminal
driver. I've only implemented it for post.trm and
gd.trm, but any terminal that already allows a size can
be trivially converted to use the new routine.
Default_units is either INCHES, CM, or PIXELS.
This tells the routine how to interpreat a bare number
in the size spec. Pixel-based terminals will normally
select PIXELS as the default units, but post.trm
defaults to INCHES.
This will get you US paper size "legal":
set term post landscape size 14, 8.5
This will get you paper size A4:
set term post size 29.7cm, 21.0cm
And this will get you a 3 inch by 5 inch PNG image if
display on a monitor with approximately 72 dpi resolution:
set term png size 3in, 5in
Notes
======
We need some mechanism to specify a resolution other
than 72dpi for pixel-based terminals.
With this in place, there should never be a need for
specifying size > 1 to postscript terminals. This
mechanism gets the bounding box right for large plots,
which the old mechanism never did.
Please give this a workout. I've tested it, but I
don't have any old scripts that produced oversize
postscript images, so I can't easily compare backwards
compatibility in real cases.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Petr M. <mi...@ph...> - 2005-11-15 18:10:42
|
> We need some mechanism to specify a resolution other > than 72dpi for pixel-based terminals. Bitmap terminals would need yet another option "resolution" for specifying the dpi value. > With this in place, there should never be a need for > specifying size > 1 to postscript terminals. OK with me. --- PM |
|
From: Jonathan T. <jt...@ae...> - 2005-11-17 13:14:09
|
Hi,
On Mon, 14 Nov 2005, Ethan Merritt wrote:
> Sorry, I should have posted a specific announcement here as well as
> to the SourceForge tracking list.
>
> Please give a thorough workout to SourceForge patch #1356114
>
> set term post size <foo>in,<baz>in
>
> Also handles units of cm or pixels.
[[...]]
Thanks, this looks like just what I was looking for.
I'm tied up for the next 2-3 weeks, but shortly after that I'll
try it out.
Of course, for _portable_ gnuplot scripts (ones which I can put into
our local cvs repository, and expect my coauthors to be able to run
with whatever random gnuplot version they have) I'll have to stick to
the old 'set size > 1' for another year or two, but in the long run,
I think Ethan's patch is a clean solution to the problem.
ciao,
--
-- Jonathan Thornburg <jt...@ae...>
Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
Golm, Germany, "Old Europe" http://www.aei.mpg.de/~jthorn/home.html
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam
>
>
> Here is a repeat announcement
>
>
> Initial Comment:
> Enough talking about it, here is actual code.
>
> Synopsis
> ========
> Specify explicit bounding box for postscript-based
> terminals in inches, centimeters, or points.
> e.g. default is equivalent to
> set term post size 10in, 7in
>
> Details
> =======
> Adds a parsing routine parse_term_size(*x, *y,
> default_units) that can be called by any terminal
> driver. I've only implemented it for post.trm and
> gd.trm, but any terminal that already allows a size can
> be trivially converted to use the new routine.
>
> Default_units is either INCHES, CM, or PIXELS.
> This tells the routine how to interpreat a bare number
> in the size spec. Pixel-based terminals will normally
> select PIXELS as the default units, but post.trm
> defaults to INCHES.
>
> This will get you US paper size "legal":
> set term post landscape size 14, 8.5
>
> This will get you paper size A4:
> set term post size 29.7cm, 21.0cm
>
> And this will get you a 3 inch by 5 inch PNG image if
> display on a monitor with approximately 72 dpi resolution:
> set term png size 3in, 5in
>
> Notes
> ======
>
> We need some mechanism to specify a resolution other
> than 72dpi for pixel-based terminals.
>
> With this in place, there should never be a need for
> specifying size > 1 to postscript terminals. This
> mechanism gets the bounding box right for large plots,
> which the old mechanism never did.
>
> Please give this a workout. I've tested it, but I
> don't have any old scripts that produced oversize
> postscript images, so I can't easily compare backwards
> compatibility in real cases.
>
>
> --
> Ethan A Merritt merritt@u.washington.edu
> Biomolecular Structure Center
> Mailstop 357742
> University of Washington, Seattle, WA 98195
>
>
|
