Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2006-06-19 19:46:16
|
Ethan Merritt wrote: > On Monday 19 June 2006 11:11 am, you wrote: > >>As a part of the answer to "what special the ConTeXt terminal can do" >>(not necessary to "what one would want to have there"), here's an >>example that I wanted to show some time ago, but the support for such >>trickery in ConTeXt was first introduced last week: >> >> http://pub.mojca.org/gnuplot/sample/cow/gnuplot-cow.pdf > > > [shrug] That kind of plot is possible in many of the terminals now, > so long as you have a cow glyph to use in the first place. See the > stringvars demo. > > Even fancier variants of positioning glyphs/icons/pictures are possible > using the "with image" plot mode, but no one has put together a demo > for this [mis]use yet. It will become more powerful if/when we add > support for an alpha channel. (cc'ed to Dan Sebald; maybe this will > inspire him). Nothing like cow plots to motivate someone from the dairy state. (Actually, it just keeps slipping my mind.) Well, to get started, I'm going to add IC_RGBA to the list, i.e., typedef enum t_imagecolor { IC_PALETTE, IC_RGB, IC_RGBA } t_imagecolor; and adjust things accordingly to all the terminal drivers. The advantage of this, as opposed to simply changing IC_RGB to IC_RGBA is data reduction across the pipe in the case of X11 and generally just data reduction whenever. (I'm always for data reduction when 2D types of elements, e.g. surfaces, images, etc. are in play.) Dan -- Dan Sebald phone: 608 256 7718 email: daniel DOT sebald AT ieee DOT org URL: http://webpages DOT charter DOT net/dsebald/ |
|
From: Daniel J S. <dan...@ie...> - 2006-06-19 19:54:19
|
Daniel J Sebald wrote:
> Nothing like cow plots to motivate someone from the dairy state. (Actually, it just keeps slipping my mind.) Well, to get started, I'm going to add IC_RGBA to the list, i.e.,
>
> typedef enum t_imagecolor { IC_PALETTE, IC_RGB, IC_RGBA }
> t_imagecolor;
>
> and adjust things accordingly to all the terminal drivers. The advantage of this, as opposed to simply changing IC_RGB to IC_RGBA is data reduction across the pipe in the case of X11 and generally just data reduction whenever. (I'm always for data reduction when 2D types of elements, e.g. surfaces, images, etc. are in play.)
And as for command line syntax, we'll have "with rgbaimage" in a fashion similar to "rgbimage"? What about the possibility of mapping a particular pixel value to transparent, as I imagine a lot of glyphs might do? (Of course, we do that internally by playing a game with the alpha channel for images before we send it to the terminal driver.) For pm3d types of things we might just not plot the element associated with a transparent value.
gnuplot> set transparent 255
Then again, a lot of palette based images don't have alpha blending... Am I worrying about a non-problem?
Dan
|
|
From: Petr M. <mi...@ph...> - 2006-06-19 19:59:29
|
> images before we send it to the terminal driver.) For pm3d types of > things we might just not plot the element associated with a transparent > value. In case of pm3d plots, polygon's z-value out of zrange is equivalent to full transparency (polygon is not plotted). --- PM |
|
From: Daniel J S. <dan...@ie...> - 2006-06-19 20:02:20
|
Petr Mikulik wrote: >> images before we send it to the terminal driver.) For pm3d types of >> things we might just not plot the element associated with a >> transparent value. > > > In case of pm3d plots, polygon's z-value out of zrange is equivalent to > full transparency (polygon is not plotted). Ah... And what about syntax, Petr? "with rgbaimage" makes sense to you? (Most straight forward to program probably.) Dan |
|
From: Petr M. <mi...@ph...> - 2006-06-19 20:17:20
|
>> In case of pm3d plots, polygon's z-value out of zrange is equivalent to >> full transparency (polygon is not plotted). > > Ah... And what about syntax, Petr? "with rgbaimage" makes sense to you? > (Most straight forward to program probably.) OK. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-19 20:14:06
|
On Monday 19 June 2006 01:03 pm, Daniel J Sebald wrote: > Daniel J Sebald wrote: > > Nothing like cow plots to motivate someone from the dairy state. Moo. > And as for command line syntax, we'll have "with rgbaimage" in a > fashion similar to "rgbimage"? Remember that the decision whether to use transparency is a separate question from whether the external file contains an alpha channel. That is, `plot "foo" binary filetype=avs with rgbimage` already handles an input stream containing an alpha channel, but it is just discarded rather than being used in plotting. In the case of AVS, it *always* has an alpha channel. But I'm not sure how you generalize it to other input file types. > What about the possibility of mapping a particular pixel value > to transparent, as I imagine a lot of glyphs might do? That's part and parcel of the same issue. The input file might not contain a separate alpha channel, but we might nevertheless be able to generate one on the fly. > Then again, a lot of palette based images don't have alpha > blending... Am I worrying about a non-problem? No. It's a real problem. There has to be a mechanism to specify how many channels are to be read from the input, and a separate mechanism to specify how many channels are used in plotting. The latter may be as simple as a keyword "transparent". E.g. plot the same file twice, with and without transparency: plot "foo" binary filetype=avs with transparent rgbimage plot "foo" binary filetype=avs with rgbimage Or, following your suggestion, it could instead be plot "foo" binary filetype=avs with rgbaimage plot "foo" binary filetype=avs with rgbimage In either case the command is controlling whether the alpha channel is used on *output*. The input in this case always has an alpha channel, although that would not be true in general. All of this for post-4.2, of course. Let's defer detailed discussion til then -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Petr M. <mi...@ph...> - 2006-06-19 20:19:23
|
> `plot "foo" binary filetype=avs with rgbimage` I wish that gnuplot can read also png images. Usually gnuplot is compiled with libpng, so that should not be a problem. And people don't know about avs, but do about png. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-19 20:43:11
|
On Monday 19 June 2006 01:19 pm, Petr Mikulik wrote: > > `plot "foo" binary filetype=avs with rgbimage` > > I wish that gnuplot can read also png images. Usually gnuplot is > compiled with libpng, so that should not be a problem. It's not quite that simple. AVS is a streaming format. You can read it one pixel at a time and process as you go. PNG is much more complicated. I believe that the minimum you can read at one go is an entire line, and the more normal operation is to read in an entire image. Furthermore, there are numerous PNG encoding options, so you have to be prepared for reading and interpreting a lot of envelope information. And that's before we even get into the whole issues of truecolor/palette/colorspace/transparency/... I honestly think the best way to read in a png image is to filter it through ImageMagick and generate an AVS stream. plot "< convert image.png avs:-" binary filetype=avs -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-06-19 20:59:47
|
Ethan Merritt wrote: > On Monday 19 June 2006 01:19 pm, Petr Mikulik wrote: > >>> `plot "foo" binary filetype=avs with rgbimage` >> >>I wish that gnuplot can read also png images. Usually gnuplot is >>compiled with libpng, so that should not be a problem. > > > It's not quite that simple. AVS is a streaming format. > You can read it one pixel at a time and process as you go. > PNG is much more complicated. I believe that the minimum > you can read at one go is an entire line, and the more > normal operation is to read in an entire image. Furthermore, > there are numerous PNG encoding options, so you have to be > prepared for reading and interpreting a lot of envelope > information. > > And that's before we even get into the whole issues of > truecolor/palette/colorspace/transparency/... > > I honestly think the best way to read in a png image is > to filter it through ImageMagick and generate an AVS stream. > > plot "< convert image.png avs:-" binary filetype=avs AVS is unique in its simplicity, hence writing the code for that was pretty straightforward. Conceptually, any other image format support should move data about in a similar way. However, when we start talking more complex formats then it's best to use existing libraries just like GD for the output terminal side of things. It isn't that difficult, but I think we'd need to devise some method of including only hunks of executable code, just like what has been suggested for the terminal driver. Otherwise gnuplot starts to become bloated. Furthermore, if we go to that extent with images, why should any type of datafile format be excluded from this approach regardless of plot style? Dan |
