Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2005-11-12 01:27:49
|
Ethan A Merritt wrote: > On Friday 11 November 2005 05:11 pm, Daniel J Sebald wrote: > >>I don't know if it is even that complicated. Certainly one can do that. >> But I'm constantly making the mistake of creating a plot half off >>screen in ghostview, then I expand out to some other page size beside >>"encapsulated" and there is the rest of the plot. > > > And right there you have the reason why the PostScript driver is > different from all the others - it let's you draw "off the screen". > If you come to rely on that, you will eventually find that some > other driver will be extremely unhappy that you are trying to > draw outside the pre-allocated space. I don't know what we are disagreeing on here. :-) >> For me, it would be much more interesting to enable gnuplot to >>read in common picture files as jpg or png. >> >>Noted. (And list members should note.) The capability to do so exists >>as part of the code. But there is debate on whether to allow this. > > > Really? You have code that reads in a jpeg file? Sorry. No. Right after I sent the email I thought I hadn't worded that too well... and I was right. What I meant was that we've organized the code so that it wouldn't be difficult for someone to add support for different image types. I recall debate about whether we should get to the point of supporting the myriad different image file formats. (And that was never my original intent. The original intent was for computer programs to exchange data through a pipe.) Dan |
|
From: Harald H. <h.h...@tu...> - 2005-11-12 12:02:41
|
On Fri, 11 Nov 2005, Ethan A Merritt wrote: > On Friday 11 November 2005 05:11 pm, Daniel J Sebald wrote: > > > > I don't know if it is even that complicated. Certainly one can do that. > > But I'm constantly making the mistake of creating a plot half off > > screen in ghostview, then I expand out to some other page size beside > > "encapsulated" and there is the rest of the plot. > > And right there you have the reason why the PostScript driver is > different from all the others - it let's you draw "off the screen". > If you come to rely on that, you will eventually find that some > other driver will be extremely unhappy that you are trying to > draw outside the pre-allocated space. > > > > set size 2,2 > ^^^^^^^^^^^^^ > Don't do that. Oh no, not again. For all postscript terminals, it's the only way to produce large plots. And for some other terminals, it also works as scale factor for the canvas. If you are allowed to reduce the canvas size using 'set size 0.7,0.7' you also have to be allowed to increase it by using 'set size 2.0,2.0'. And to maintain compatibility (to the old code where no clipping was done in most terminals) we will have to handle sizes above 1, too. Have you had a look at the new patch, #1353539? Here, correct clipping works for postscript, png, and fig. It sets term->canvas in all terminals, now. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Jonathan T. <jt...@ae...> - 2005-11-14 11:38:58
|
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 -- and for a long time after that due to
backwards compatability and delays in new gnuplot versions propagating
out to the user community -- people are going to continue doing just
what Ethan objects to.
Indeed, this past weekend I wrote
set term postscript enhanced eps solid color "Helvetica" 18
set output 'geodesics.eps'
set size 1.0, 1.5
unset key
...
set output
to produce a "right-sized" figure for a paper I'm writing. Is there
an alternative mechanism that I've missed in _current_ gnuplot?
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
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-15 19:16:02
|
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.
Please note that the original example that I responded to
was *not* using the PostScript driver. This was the
original complaint:
> set size 2,2
> set terminal png
> set output 'asdf.png'
> plot sin(x)
> set output
>
> Half of the tic marks are missing.
The png driver has always supported "set term png size xx, yy".
Nevertheless, since you ask....
> set term postscript enhanced eps solid color "Helvetica" 18
> set output 'geodesics.eps'
> set size 1.0, 1.5
> Is there
> an alternative mechanism that I've missed in _current_ gnuplot?
Step 1
set term post enh solid color "Helvetica" 18
set output 'geodesics.eps'
set size 0.5, 0.75
plot ...
set output
Step 2
add the string "EPSF-2.0" at the end of the first line of
geodesics.eps
No, I'm not saying this is convenient. That's why I'm
trying to push acceptance of the new patch to add explicit
size info to the "set term post" command.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Harald H. <h.h...@tu...> - 2005-11-12 12:02:44
|
On Fri, 11 Nov 2005, Daniel J Sebald wrote: > > Really? You have code that reads in a jpeg file? > > Sorry. No. Right after I sent the email I thought I hadn't worded that > too well... and I was right. What I meant was that we've organized the > code so that it wouldn't be difficult for someone to add support for > different image types. I recall debate about whether we should get to > the point of supporting the myriad different image file formats. (And > that was never my original intent. The original intent was for computer > programs to exchange data through a pipe.) When the image code was new, I started a little effort to use it to put a scanned image in a plot. After some reading I decided not to continue the work on it because I did not even know how to convert, say a png, to the specific gnuplot image format. Thus, I failed to use the image support. In my opinion, adding at least two common image formats, png (loss-less) and jpg (with losses), would really be helpful. At the moment, gnuplot only supports a "private" format, right? Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Daniel J S. <dan...@ie...> - 2005-11-12 22:47:26
|
Harald Harders wrote:
> On Fri, 11 Nov 2005, Daniel J Sebald wrote:
>
>
>>>Really? You have code that reads in a jpeg file?
>>
>>Sorry. No. Right after I sent the email I thought I hadn't worded that
>>too well... and I was right. What I meant was that we've organized the
>>code so that it wouldn't be difficult for someone to add support for
>>different image types. I recall debate about whether we should get to
>>the point of supporting the myriad different image file formats. (And
>>that was never my original intent. The original intent was for computer
>>programs to exchange data through a pipe.)
>
>
> When the image code was new, I started a little effort to use it to put a
> scanned image in a plot. After some reading I decided not to continue the
> work on it because I did not even know how to convert, say a png, to the
> specific gnuplot image format. Thus, I failed to use the image support. In
> my opinion, adding at least two common image formats, png (loss-less) and
> jpg (with losses), would really be helpful. At the moment, gnuplot only
> supports a "private" format, right?
First, let me preface this to say that we shouldn't embark on adding support
for a lot of images too soon without discussion. We don't want to get a
bloated plotting program. We'd need a well thought out strategy for
incorporating file formats. Petr and I put something together that we thought
was a start, but I'd hope for input and concensus of how to build on that.
To give you a general concept, Harald, take a look at datafile.c for:
df_bin_filetype_table_struct df_bin_filetype_table[] = {
{"gpbin", gpbin_filetype_function},
{"raw", raw_filetype_function},
{"rgb", raw_filetype_function},
{"bin", raw_filetype_function},
#if 1
{"edf", edf_filetype_function},
{"ehf", edf_filetype_function},
#endif
{"auto", raw_filetype_function} /* "auto" is trapped, but if the actual file extension is "auto" then use raw. */
};
#define RAW_FILETYPE 1
What this does is tell gnuplot that when if finds a file of extension "gpbin", "raw", "rgb", etc. to run the designer function for that file type. Petr's file breader.c gives an example for files of type EDF.
And the strategy is this: OK, we now have this generic manner for handling binary files. Aside from compression (a detail that needs to be worked out), if the data is in some type of rectangular format all you need do is fill in the structure for details about the data format. In other words, "edf_filetype_function" fills in all the details that one would fill in at the command line, like size of header, bytes to skip per line, etc. etc. Then just let the program continue onward.
So, we'd need a
{"png", png_filetype_function}
{"jpg", jpg_filetype_function}
{"jpeg", jpg_filetype_function}
But the sticking point is that there is compression or encoding for some of these formats. Perhaps not difficult to deal with. Create some intermediate, uncompressed file then fill in the details about that binary file and point gnuplot to it. Or, one could choose some other binary file to always convert to.
Hopefully this gives you an idea why things should be thought out. Are there better strategies? The main thing that concerns me is we get more and more core code for every new file format. Rather, I'd prefer some kind of "unix modules" or DLL approach.
Dan
|
|
From: Harald H. <h.h...@tu...> - 2005-11-12 23:07:34
|
On Sat, 12 Nov 2005, Daniel J Sebald wrote:
> First, let me preface this to say that we shouldn't embark on adding support
> for a lot of images too soon without discussion. We don't want to get a
> bloated plotting program. We'd need a well thought out strategy for
> incorporating file formats. Petr and I put something together that we thought
> was a start, but I'd hope for input and concensus of how to build on that.
[...]
> But the sticking point is that there is compression or encoding for some
> of these formats. Perhaps not difficult to deal with. Create some
> intermediate, uncompressed file then fill in the details about that
> binary file and point gnuplot to it. Or, one could choose some other
> binary file to always convert to.
I think this should be easy using the libraries libpng and jpeglib. But I
will not start working on that. The only issue to me is that I did not
understand how to use this function. What I would have needed was a
programme that converts jpeg or png to one of the gnuplot formats.
I believe that not may people will know how to deal with image support. By
the way. Is there anything written in the Gnuplot documentation which
exact file format is needed to put image data into the plot? I have not
found it yet.
At the moment, I have moved to the epslatex terminal with
set label '\includegraphics{asdf}' at ...
Best regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Daniel J S. <dan...@ie...> - 2005-11-12 23:23:00
|
Harald Harders wrote: > I think this should be easy using the libraries libpng and jpeglib. But I > will not start working on that. The only issue to me is that I did not > understand how to use this function. What I would have needed was a > programme that converts jpeg or png to one of the gnuplot formats. I like Ethan's suggestion in the previous email. RGB is as rudimentary as it gets. So if one converts to RGB there is the option of specifying at the command line what the size (bytes) the pixel values are. > > I believe that not may people will know how to deal with image support. By > the way. Is there anything written in the Gnuplot documentation which > exact file format is needed to put image data into the plot? Maybe, maybe not. We're just getting these ideas together. I have not > found it yet. Try help datafile binary help binary general filetype Again, try Ethan's idea and specify the data point size if necessary. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-12 23:11:51
|
On Saturday 12 November 2005 02:54 pm, Daniel J Sebald wrote: > Harald Harders wrote: > > On Fri, 11 Nov 2005, Daniel J Sebald wrote: > >>>Really? You have code that reads in a jpeg file? > >> > > First, let me preface this to say that we shouldn't embark on adding > support for a lot of images too soon without discussion. We don't want > to get a bloated plotting program. 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. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Harald H. <h.h...@tu...> - 2005-11-12 23:30:59
|
On Sat, 12 Nov 2005, Ethan A Merritt wrote: > On Saturday 12 November 2005 02:54 pm, Daniel J Sebald wrote: > > Harald Harders wrote: > > > On Fri, 11 Nov 2005, Daniel J Sebald wrote: > > >>>Really? You have code that reads in a jpeg file? > > >> > > > > First, let me preface this to say that we shouldn't embark on adding > > support for a lot of images too soon without discussion. We don't want > > to get a bloated plotting program. > > 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 file format looks like. For example, the file starts with two 8-bit unsigned ints containing the resolution in x and y direction, every pixel contains of three 8-bit chars for rgb, ... But this should be done by somebody who knows the image code. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Petr M. <mi...@ph...> - 2005-11-12 20:31:42
|
>>> Yes, of course. Postscript can do nearly everything except translucent >>> objects. I was always wondering how OpenOffice.org makes transparency in its postscript or pdf files. (When you print such presentations, it says "the file may be bigger" or a message like that.) --- PM |
|
From: Harald H. <h.h...@tu...> - 2005-11-12 21:12:01
|
On Sat, 12 Nov 2005, Petr Mikulik wrote: > >>> Yes, of course. Postscript can do nearly everything except translucent > >>> objects. > > I was always wondering how OpenOffice.org makes transparency in its > postscript or pdf files. (When you print such presentations, it says "the > file may be bigger" or a message like that.) PDF is capable of translucency, at least in recent versions. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Daniel J S. <dan...@ie...> - 2005-11-12 22:31:56
|
Harald Harders wrote: > On Fri, 11 Nov 2005, Daniel J Sebald wrote: > > >>>set size 2,2 >>>set terminal png >>>set output 'asdf.png' >>>plot sin(x) >>>set output >>> >>>Have of the tic marks are missing. > > > sed s/Have/Half/. > > >>Hmm. Not right of course, but this seems as though it may be a >>different bug. I see all the tic marks, but the annotation is what is >>missing. > > > That's what I meant. It's easy: All text that is requested with a screen > coordinate above 1 is not printed. It does not have to do with negative or > positive numbers. Just try another size than 2,2. Oh, I see what you are saying. (Got to explain a bit more.) The text clips, but not the lines. Yeah. > > >>>>Also, write a nicer do_arrow(), as Ethan suggests. I think I could do >>>>it fairly easily, but I simply don't have time now. It would have to >>>>wait until after the holidays. >>> >>>What do you want to improve? For me, the Postscript arrows are good >>>enough. >> >>I'd thought I'd read in the thread somewhere that better PostScript >>arrows clipped at the edge of the canvas were desired. Sorry. > > > If the line and the filled-path code supports correct clipping and the > original arrow code uses these clipped lines and filled paths, > parly clipping of arrow heads will be supported by every terminal. OK, here we get into a philosophical debate. If you have a full-featured resource like PostScript, shouldn't you allow the arrows to extend past the edge and let PostScript do the clipping? I can imagine some users who don't do things exactly right, but then can correct matters with an offset in there word processor or whatever. Someone shifts their EPS file into view and lo-and-behold, the arrow or line is cropped in a funny way. [Not too much different than the example you've shown for PNG.] [continued...] |
|
From: Harald H. <h.h...@tu...> - 2005-11-12 23:07:48
|
On Sat, 12 Nov 2005, Daniel J Sebald wrote:
> Oh, I see what you are saying. (Got to explain a bit more.) The text
> clips, but not the lines. Yeah.
Exactly.
> > If the line and the filled-path code supports correct clipping and the
> > original arrow code uses these clipped lines and filled paths,
> > parly clipping of arrow heads will be supported by every terminal.
>
> OK, here we get into a philosophical debate. If you have a full-featured
> resource like PostScript, shouldn't you allow the arrows to extend past the
> edge and let PostScript do the clipping? I can imagine some users who don't
> do things exactly right, but then can correct matters with an offset in
> there word processor or whatever. Someone shifts their EPS file into view
> and lo-and-behold, the arrow or line is cropped in a funny way. [Not too
> much different than the example you've shown for PNG.]
You are right. Gnuplot should not do any clipping for postscript, and the
terminal itself could add the postscript clipping on demand:
%%BoundingBox 50 50 350 250
[...]
/Clipping false def
gsave
Clipping {
newpath
moveto 50 50
lineto 350 50
lineto 350 250
lineto 50 250
closepath
clip
} if
[... all the rest of the file ...]
grestore
%%Trailer
Best regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Daniel J S. <dan...@ie...> - 2005-11-12 22:57:09
|
Harald Harders wrote: > On Fri, 11 Nov 2005, Ethan A Merritt wrote: > > >>On Friday 11 November 2005 05:11 pm, Daniel J Sebald wrote: >> >>>I don't know if it is even that complicated. Certainly one can do that. >>> But I'm constantly making the mistake of creating a plot half off >>>screen in ghostview, then I expand out to some other page size beside >>>"encapsulated" and there is the rest of the plot. >> >>And right there you have the reason why the PostScript driver is >>different from all the others - it let's you draw "off the screen". >>If you come to rely on that, you will eventually find that some >>other driver will be extremely unhappy that you are trying to >>draw outside the pre-allocated space. >> >> >>>>set size 2,2 >> >> ^^^^^^^^^^^^^ >>Don't do that. > > > Oh no, not again. For all postscript terminals, it's the only way to > produce large plots. And for some other terminals, it also works as scale > factor for the canvas. If you are allowed to reduce the canvas size using > 'set size 0.7,0.7' you also have to be allowed to increase it by using > 'set size 2.0,2.0'. And to maintain compatibility (to the old code where > no clipping was done in most terminals) we will have to handle sizes above > 1, too. I'm sort of in agreement with you, Harald. [My pipe dream has always been to find the time to write a document "How to layout plots in gnuplot".] But I would say I think there are two distinct concepts here, one the size of the plot with respect to the convas and another the size of the canvas with respect to the plotting device's inherent coordinate system. For example, with PostScript, if I were to make the _canvas_ size 2.0,2.0 without changing plot size, what I'd expect is font size, line thickness, etc. to "shrink" in a relativistic way. Similarly, if I set _plot_ size 0.5,0.5 without changing canvas size I'd expect font size, line thickness, etc. to "expand" in a relativistic way. Mantra? Clip to the canvas, not the plot? Should "subplots" have a canvas size too? Am I confusing matters worse than already are? Dan |
|
From: Harald H. <h.h...@tu...> - 2005-11-12 23:27:12
|
On Sat, 12 Nov 2005, Daniel J Sebald wrote:
> > Oh no, not again. For all postscript terminals, it's the only way to
> > produce large plots. And for some other terminals, it also works as scale
> > factor for the canvas. If you are allowed to reduce the canvas size using
> > 'set size 0.7,0.7' you also have to be allowed to increase it by using
> > 'set size 2.0,2.0'. And to maintain compatibility (to the old code where
> > no clipping was done in most terminals) we will have to handle sizes above
> > 1, too.
>
> I'm sort of in agreement with you, Harald. [My pipe dream has always
> been to find the time to write a document "How to layout plots in
> gnuplot".] But I would say I think there are two distinct concepts here,
> one the size of the plot with respect to the convas and another the size
> of the canvas with respect to the plotting device's inherent coordinate
> system.
Right. I agree. And I think we should have both. At the moment, screen is
a mixture of both, depending on the terminal:
postscript:
- screen coordinate system has fixed size
- screen coordinates of upper right corner of canvas is changing according
to 'set size'
png:
- screen coordinate system - scales with given size in 'set terminal'
- screen coordinates of upper right corner of canvas is changing according
to 'set size', and image size scales with 'set size', too.
fig:
- acts as png
x11:
- screen coordinate system scales with window
- upper right corner always has screen 1,1.
> For example, with PostScript, if I were to make the _canvas_ size
> 2.0,2.0 without changing plot size, what I'd expect is font size, line
> thickness, etc. to "shrink" in a relativistic way.
You mean, the fonts shall stay the same size, but glyph height is only 5%
of the canvas height instead of 10%? This is the case, also for line
thickness etc.
> Similarly, if I set
> _plot_ size 0.5,0.5 without changing canvas size I'd expect font size,
> line thickness, etc. to "expand" in a relativistic way.
That's the case.
> Mantra?
???
> Clip to the canvas, not the plot?
Depends on what you are doing. Parts of the plot, e.g. lines, vectors etc.
should clip to the plot. But free given labels and arrows should be
clipped to the canvas because it can be useful to place things outside the
plot.
> Should "subplots" have a canvas size too?
> Am I confusing matters worse than already are?
Yes, you are.
Let me conclude what I think now:
1.) The screen coordinate system should not be changed anymore (with the
exception that the clipping has to be fixed to the current 'set size'
to canvas size relationship in all terminals.
2.) Some new coordinate systems should be introduced:
- A canvas coordinate system that always runs from 0 to 1 on the canvas
- A subcanvas coordinate system that always runs from 0 to 1 on the
"single-multiplot-plot canvas"
- One or more coordinate systems with absolute sizes, e.g., mm,
inch=25.4mm, pt=1/72inch, pixel=(res in dpi)*inch.
3.) A resolution should be introduced which can be forwarded to the pixel
terminals for the output files and be used by the other terminals to
be able to calculate between pixel and the other absolute measures.
4.) The screen coordinate should be marked as 'deprecated'.
5.) 'set size' and 'set origin' before 'set terminal' should print a
warning because they have strange behaviour.
6.) 'set size' and 'set origin' after 'set terminal' should only affect
the plot, not the canvas. Sizes above 1 should be still allowed in
case somebody likes to have a half plot on the screen.
7.) 'set size', 'set origin' and the size measures for the terminals
should understand 'screen' coordinates (which size and origin do
exclusively, now) and all absolute coordinate systems (mm, inch, pt,
pixel, character). Not that character is the only absolute coordinate
system we have at the moment. Its measure only depends on the chosen
fontsize.
This approach has a couple of advantages:
- Compatibility to old scripts is maintained
- In future, we have a much clearer interface and it is possible to say "I
want a plot of 5 x 3 inches" (and this for all terminals). What to do
with the screen terminals is somehow unclear. But using the X server
solution (which should be accessable), even mm, inch, pt should be
possible.
What do you all think about this approach?
Best regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: <wie...@we...> - 2005-11-13 21:50:50
|
On Sunday 13 November 2005 00:32 Harald Harders wrote: > Let me conclude what I think now: > > 1.) The screen coordinate system should not be changed anymore (with the > exception that the clipping has to be fixed to the current 'set size' > to canvas size relationship in all terminals. > > 2.) Some new coordinate systems should be introduced: > - A canvas coordinate system that always runs from 0 to 1 on the canvas > - A subcanvas coordinate system that always runs from 0 to 1 on the > "single-multiplot-plot canvas" > - One or more coordinate systems with absolute sizes, e.g., mm, > inch=25.4mm, pt=1/72inch, pixel=(res in dpi)*inch. > > 3.) A resolution should be introduced which can be forwarded to the pixel > terminals for the output files and be used by the other terminals to > be able to calculate between pixel and the other absolute measures. > > 4.) The screen coordinate should be marked as 'deprecated'. > > 5.) 'set size' and 'set origin' before 'set terminal' should print a > warning because they have strange behaviour. > > 6.) 'set size' and 'set origin' after 'set terminal' should only affect > the plot, not the canvas. Sizes above 1 should be still allowed in > case somebody likes to have a half plot on the screen. > > 7.) 'set size', 'set origin' and the size measures for the terminals > should understand 'screen' coordinates (which size and origin do > exclusively, now) and all absolute coordinate systems (mm, inch, pt, > pixel, character). Not that character is the only absolute coordinate > system we have at the moment. Its measure only depends on the chosen > fontsize. > > This approach has a couple of advantages: > - Compatibility to old scripts is maintained > - In future, we have a much clearer interface and it is possible to say "I > want a plot of 5 x 3 inches" (and this for all terminals). What to do > with the screen terminals is somehow unclear. But using the X server > solution (which should be accessable), even mm, inch, pt should be > possible. > > > What do you all think about this approach? Sounds *very* reasonable. But I fear I won't be able to help with the implemtation. But don't let this suggestion get buried within the depths of this thread (or its mother thread, depending on the mail reader)! But what does "before 'set terminal'" mean (item 5)? The first time, the terminal is changed from the default one? You know: "Nach dem 'set terminal' ist vor dem 'set terminal'." ;-)) Juergen |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-13 00:23:41
Attachments:
tux.gif
|
On Saturday 12 November 2005 03:11 pm, Ethan A Merritt wrote: > I'd think you can do it now with no extra code at all: > > plot "< convert pic.jpeg rgb:-" with image Hey, it works! plot '< convert tux.gif rgb:-' binary filetype=rgb array=60x70 \ format="%uchar %uchar %uchar" flipy u 1:2:3 with rgbimage It would be nice if that long combination of options had some shorter form, though. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Harald H. <h.h...@tu...> - 2005-11-13 00:34:09
|
On Sat, 12 Nov 2005, Ethan A Merritt wrote: > On Saturday 12 November 2005 03:11 pm, Ethan A Merritt wrote: > > I'd think you can do it now with no extra code at all: > > > > plot "< convert pic.jpeg rgb:-" with image > > Hey, it works! > > plot '< convert tux.gif rgb:-' binary filetype=rgb array=60x70 \ > format="%uchar %uchar %uchar" flipy u 1:2:3 with rgbimage I'm not totally convinced. This is better: plot '< convert tux.gif rgb:-' binary filetype=rgb \ array=`identify -format '%wx%h' tux.gif` \ format="%uchar %uchar %uchar" flipy u 1:2:3 with rgbimage notitle > It would be nice if that long combination of options had some > shorter form, though. Oh yes! :-) Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Daniel J S. <dan...@ie...> - 2005-11-13 03:09:50
|
Ethan A Merritt wrote: > On Saturday 12 November 2005 03:11 pm, Ethan A Merritt wrote: > >>I'd think you can do it now with no extra code at all: >> >> plot "< convert pic.jpeg rgb:-" with image > > > Hey, it works! Cool. > > plot '< convert tux.gif rgb:-' binary filetype=rgb array=60x70 \ > format="%uchar %uchar %uchar" flipy u 1:2:3 with rgbimage > > It would be nice if that long combination of options had some > shorter form, though. Yes, the array size is a manual thing... or Harald has shown another feature for extracting the dimensions that I was unaware of. Well, that is nice. Can some scripts solve this? Or perhaps I could write a very generic routine based upon this concept. Is there a way to send out a system command from within a C program and route the data back in somehow? Would that be a (not very portable) solution? If "convert" created a slightly more sophisticated format that contains the array dimensions and data point format, we could support that format. Dan |
|
From: Harald H. <h.h...@tu...> - 2005-11-13 20:51:39
|
On Sat, 12 Nov 2005, Daniel J Sebald wrote: > > plot '< convert tux.gif rgb:-' binary filetype=rgb array=60x70 \ > > format="%uchar %uchar %uchar" flipy u 1:2:3 with rgbimage > > > > It would be nice if that long combination of options had some > > shorter form, though. > > Yes, the array size is a manual thing... or Harald has shown another > feature for extracting the dimensions that I was unaware of. > > Well, that is nice. Can some scripts solve this? Or perhaps I could > write a very generic routine based upon this concept. Is there a way to > send out a system command from within a C program and route the data > back in somehow? Yes. Have a look at Postscript's fontfile option. It starts programmes to convert pfb or ttf to pfa by a named pipe (popen() et al.). > Would that be a (not very portable) solution? Maybe, you could adapt the concept of postscript fontfile with a operating-system-dependent default command for conversion and with user-definable changes. > If > "convert" created a slightly more sophisticated format that contains the > array dimensions and data point format, we could support that format. What about the formats pnm, pbm? They are the most basic file formats I know, and they are portable (I believe pbm stands for portable bitmap). Many programmes can produce pnm and pbm. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Petr M. <mi...@ph...> - 2005-11-13 21:02:34
|
> What about the formats pnm, pbm? They are the most basic file formats I > know, and they are portable (I believe pbm stands for portable bitmap). > Many programmes can produce pnm and pbm. There are also portable pixmap (ppm) and portable graymap (pgm). --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-13 22:16:05
|
On Sunday 13 November 2005 12:57 pm, Harald Harders wrote: > What about the formats pnm, pbm? They are the most basic file formats I > know, and they are portable (I believe pbm stands for portable bitmap). > Many programmes can produce pnm and pbm. It's a matter of taste. The "unix way" is to string together separate modular tools rather than bloating every application with redundant code to perform the same job as existing tools. It seems to me a bad idea to turn gnuplot into a bitmapped image processing tool when there are many such tools already that gnuplot can pipe through. It is true, as Petr points out, that gnuplot already links to at least one library (libgd) that can read in png, gif and jpeg files. But that doesn't handle pnm, or eps, or any of the 3 dozen or so formats that ImageMagick can handle. Why add special code that only handles a few cases, when it is actually less work to add a single interface to a general tool that handles all cases? And if you really don't like piping for some reason, the ImageMagick routines are available as a shared library libMagick.so. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2005-11-14 00:59:20
|
Ethan A Merritt wrote: > On Sunday 13 November 2005 12:57 pm, Harald Harders wrote: > >>What about the formats pnm, pbm? They are the most basic file formats I >>know, and they are portable (I believe pbm stands for portable bitmap). >>Many programmes can produce pnm and pbm. > > > It's a matter of taste. The "unix way" is to string together separate > modular tools rather than bloating every application with redundant code > to perform the same job as existing tools. It seems to me a bad idea to > turn gnuplot into a bitmapped image processing tool when there are many > such tools already that gnuplot can pipe through. > > It is true, as Petr points out, that gnuplot already links to at least > one library (libgd) that can read in png, gif and jpeg files. But that > doesn't handle pnm, or eps, or any of the 3 dozen or so formats that > ImageMagick can handle. Why add special code that only handles a few > cases, when it is actually less work to add a single interface to a > general tool that handles all cases? > > And if you really don't like piping for some reason, the ImageMagick > routines are available as a shared library libMagick.so. This is pretty much where I stand on the matter as well. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-13 03:55:14
|
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. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
