Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2006-10-11 17:07:46
|
I have just filled in the enclosed bug (announced to me by another gnuplot
user) ... could someone figure out an appropriate "filter" for the
postscript "image" operator so that the gamma correction works also for
"with image" as it works for "with pm3d"?
Thanks, Petr
---------- Forwarded message ----------
Subject: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript
output
https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1575425&group_id=2055
Summary: "with image" ignores gamma for postscript output
Initial Comment:
Setting of "palette gray gamma <g>" is ignored for
"with image" output into a postscript file (it is ok
for "with pm3d"). The following script demonstrates this:
set table "t.dat"; splot x; unset table
reset
set autoscale fix
set palette gray gamma 0.2
plot "t.dat" with image
#set term post color eps "Helvetica" 25
set term post mono eps "Helvetica" 25
set output "t.eps"
replot
set out; set term pop
|
|
From: Daniel J S. <dan...@ie...> - 2006-10-11 19:17:14
|
Petr Mikulik wrote: > I have just filled in the enclosed bug (announced to me by another gnuplot > user) ... could someone figure out an appropriate "filter" for the > postscript "image" operator so that the gamma correction works also for > "with image" as it works for "with pm3d"? I'm slowly losing fondness for the Greek letter gamma. :-) I'm guessing that the gamma correction is part of the palette created in the PostScript file and the image code is not using the palette. I'll investigate. May not be a quick fix. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-10-11 19:31:33
|
Daniel J Sebald wrote:
> I'm guessing that the gamma correction is part of the palette created
> in the PostScript file and the image code is not using the palette.
> I'll investigate. May not be a quick fix.
Actually the fix might not be too bad. Here is the issue:
/* Color and gray scale images do not need a palette and can use
* the 5 operand form of the image routine.
*/
if ((color_mode == IC_RGB) || (sm_palette.colorMode == SMPAL_COLOR_MODE_GRAY) || !ps_params->color)
five_operand_image = TRUE;
else
five_operand_image = FALSE;
I would like to keep the images condensed if possible. Is there a way to tell if the grayscale is linear from within post.trm? Or should I write a short little routine to verify it is?
I never new the default grayscale palette had gamma=1.5. Well, now I do.
Dan
|
|
From: Petr M. <mi...@ph...> - 2006-10-11 20:08:00
|
>> I'm guessing that the gamma correction is part of the palette created >> in the PostScript file and the image code is not using the palette. >> I'll investigate. May not be a quick fix. > > Actually the fix might not be too bad. Here is the issue: Yes, gamma plays a role only for the gray palette (not for colour palette). > I would like to keep the images condensed if possible. Is there a way to > tell if the grayscale is linear from within post.trm? > Or should I write a short little routine to verify it is? It is when "pm3dGamma != 1.0/1.5", so just one "if" is sufficient. Actually, there are two possibilities: (1) apply the gamma by a ps code: then there should be a bit advanced filter when reading the image -- something like that in pm3dConvertToImageGray.awk (2) apply the gamma when post.trm is writing the image numbers into the postscript file, and ignore pm3dGamma within the ps file The case (2) seems very easy to to code, but maybe you find a solution to (1). --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-10-11 20:21:45
|
On Wednesday 11 October 2006 10:07 am, Petr Mikulik wrote: > I have just filled in the enclosed bug (announced to me by another > gnuplot user) ... could someone figure out an appropriate "filter" > for the postscript "image" operator so that the gamma correction > works also for "with image" as it works for "with pm3d"? Shouldn't the gamma be a per-image correction rather than something to do with the current palette? I would have thought that the gamma correction belongs in the routine that reads in the data. That makes it terminal-independent. > > Thanks, Petr > > ---------- Forwarded message ---------- > Subject: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for > postscript output > > https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1575425& >group_id=2055 Summary: "with image" ignores gamma for postscript > output > > Initial Comment: > Setting of "palette gray gamma <g>" is ignored for > "with image" output into a postscript file (it is ok > for "with pm3d"). The following script demonstrates this: > > set table "t.dat"; splot x; unset table > reset > > set autoscale fix > set palette gray gamma 0.2 > > plot "t.dat" with image > #set term post color eps "Helvetica" 25 > set term post mono eps "Helvetica" 25 > set output "t.eps" > replot > set out; set term pop > > --------------------------------------------------------------------- >---- Using Tomcat but need to do more? Need to support web services, > security? Get stuff done quickly with pre-integrated technology to > make your job easier Download IBM WebSphere Application Server > v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121 >642 _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Petr M. <mi...@ph...> - 2006-10-11 21:01:47
|
> On Wednesday 11 October 2006 10:07 am, Petr Mikulik wrote: >> I have just filled in the enclosed bug (announced to me by another >> gnuplot user) ... could someone figure out an appropriate "filter" >> for the postscript "image" operator so that the gamma correction >> works also for "with image" as it works for "with pm3d"? > > Shouldn't the gamma be a per-image correction rather than something > to do with the current palette? Yes, it is; palette is updated (changed, written to ps file, ...) before each plot > I would have thought that the gamma correction belongs in the routine that > reads in the data. That makes it terminal-independent. No, it is for displaying, as all "set palette" properties. There, postscript is the only terminal that avoids calling cb2color because it implements this function by postscript primitives, so it should do it for "palette gray gamma" as well. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2006-10-11 21:48:14
|
Petr Mikulik wrote: >>On Wednesday 11 October 2006 10:07 am, Petr Mikulik wrote: >> >>>I have just filled in the enclosed bug (announced to me by another >>>gnuplot user) ... could someone figure out an appropriate "filter" >>>for the postscript "image" operator so that the gamma correction >>>works also for "with image" as it works for "with pm3d"? >> >>Shouldn't the gamma be a per-image correction rather than something >>to do with the current palette? > > > Yes, it is; palette is updated (changed, written to ps file, ...) before > each plot > > >>I would have thought that the gamma correction belongs in the routine that >>reads in the data. That makes it terminal-independent. > > > No, it is for displaying, as all "set palette" properties. There, postscript > is the only terminal that avoids calling cb2color because it implements this > function by postscript primitives, so it should do it for "palette gray > gamma" as well. Well, this may be the reason that PostScript looks different to me. On your treminals please try the following and look at all the output: set palette gray gamma 1.5 test palette set term png set output 'foo.png' test palette set output set term postscript eps set output 'foo.eps' test palette set output I see that the PostScript gamma implementation is slightly lighter near the "0" in the colorbox. I also see that the PNG output does not have the colorbox lined up with the axis borders as do the X11 and PostScript outputs. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-10-11 23:58:58
|
Ethan Merritt wrote: > On Wednesday 11 October 2006 10:07 am, Petr Mikulik wrote: > >>I have just filled in the enclosed bug (announced to me by another >>gnuplot user) ... could someone figure out an appropriate "filter" >>for the postscript "image" operator so that the gamma correction >>works also for "with image" as it works for "with pm3d"? > > > Shouldn't the gamma be a per-image correction rather than something > to do with the current palette? I would have thought that the > gamma correction belongs in the routine that reads in the data. > That makes it terminal-independent. Well, I was just writing a reply and wondering that myself: .... Hmm, well let's see. I think one of these is preferred over the other, but not sure which. With (2), would that mean cb2gray() is altered in some way? Or is there another function that would be applied? E.g., gray2gamma(cb2gray()). Don't know... I think conceptually we'd like to keep our data non-tranformed. I kind of like the way "test palette" behaves. That is a really powerful tool in a way. I'm thinking to avoid (2). Agreed? ... Let me point out something else I've noticed. Using "test palette", the gamma correction looks different between X11 and PostScript. Or at least it looks that way to me. The reason I say that is because in the X11 output I can't see the "0" within the black area, but I can see "0" within the black area in the PostScript file. Dan |
|
From: Petr M. <mi...@ph...> - 2006-10-11 21:50:37
|
> Hmm, well let's see. I think one of these is preferred over the other, but > not sure which. With (2), would that mean cb2gray() is altered in some way? no, you would call pow(gray, 1.0/gamma) before writing each pixel to the file. > gray2gamma(cb2gray()). Don't know... I think conceptually we'd like to keep > our data non-tranformed. > I kind of like the way "test palette" behaves. That is a really powerful > tool in a way. I'm thinking to avoid (2). Agreed? Yes. > Let me point out something else I've noticed. Using "test palette", the > gamma correction looks different between X11 and PostScript. Or at least it > looks that way to me. The reason I say that is because in the X11 output I > can't see the "0" within the black area, but I can see "0" within the black > area in the PostScript file. For me, they look pretty similar. (On the other hand, for publications, I like to change gamma...) BTW, there was a bug in 'test palette' which I've just fixed. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2006-10-11 23:09:57
|
Petr Mikulik wrote: >> Hmm, well let's see. I think one of these is preferred over the >> other, but not sure which. With (2), would that mean cb2gray() is >> altered in some way? > > > no, you would call pow(gray, 1.0/gamma) before writing each pixel to the > file. > >> gray2gamma(cb2gray()). Don't know... I think conceptually we'd like >> to keep our data non-tranformed. >> I kind of like the way "test palette" behaves. That is a really >> powerful tool in a way. I'm thinking to avoid (2). Agreed? > > > Yes. OK. I'll have to consult the book to see images can use PostScript's gamma feature. In the mean time, I've put a patch on SourceForge with the pow(gray,1.0/gamma) which seems to work. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-10-12 06:32:40
|
Daniel J Sebald wrote:
> OK. I'll have to consult the book to see images can use PostScript's
> gamma feature. In the mean time, I've put a patch on SourceForge
> with the pow(gray,1.0/gamma) which seems to work.
Petr,
The Adobe book indicates that gamma correction can be implemented with what is called a transfer function (the second level of color mapping). So, as an alternative, I simply added a line before the image definition (and a little extra cleanup):
if (sm_palette.colorMode == SMPAL_COLOR_MODE_GRAY)
fprintf(gppsfile, "%s{1.0 %g div exp} settransfer\n", space, sm_palette.gamma);
What this does is create the line below:
gsave
{1.0 0.2 div exp} settransfer
875 4740 translate
4959 -4240 scale
100 10 8
[ 100 0 0 10 0 0 ]
currentfile /ASCII85Decode filter
image
I'll send you the patch separately so that you may place it on SourceForge. [Would it be possible to change SF to allow attaching to someone else's bug report?] Let me know if that works.
I'm guessing that transfer functions could be widened in scope. So if you'd like to use a transfer function somehow rather than /pm3dGamma, let me know.
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-10-12 15:00:32
|
On Wednesday 11 October 2006 11:42 pm, Daniel J Sebald wrote:
> Daniel J Sebald wrote:
> The Adobe book indicates that gamma correction can be implemented
> with what is called a transfer function (the second level of color mapping).
> So, as an alternative, I simply added a line before the image definition
>
> if (sm_palette.colorMode == SMPAL_COLOR_MODE_GRAY)
> fprintf(gppsfile, "%s{1.0 %g div exp} settransfer\n", space, sm_palette.gamma);
"settransfer" is Level 2 PostScript, so your patch needs to be check the
"level1" flag and/or check for support dynamically.
>
> What this does is create the line below:
>
> gsave
> {1.0 0.2 div exp} settransfer
> 875 4740 translate
> 4959 -4240 scale
> 100 10 8
> [ 100 0 0 10 0 0 ]
> currentfile /ASCII85Decode filter
> image
>
> I'll send you the patch separately so that you may place it on SourceForge. [Would it be possible to change SF to allow attaching to someone else's bug report?] Let me know if that works.
>
> I'm guessing that transfer functions could be widened in scope. So if you'd like to use a transfer function somehow rather than /pm3dGamma, let me know.
>
> Dan
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Petr M. <mi...@ph...> - 2006-10-12 21:38:37
|
>> if (sm_palette.colorMode == SMPAL_COLOR_MODE_GRAY)
>> fprintf(gppsfile, "%s{1.0 %g div exp} settransfer\n", space, sm_palette.gamma);
I've changed it to
{pm3dGamma exp} settransfer
and applied the patch.
> "settransfer" is Level 2 PostScript, so your patch needs to be check the
> "level1" flag and/or check for support dynamically.
It's OK, the whole image section is within not(Level1).
---
PM
|
|
From: Daniel F. <boy...@gm...> - 2006-10-12 15:01:28
|
Hello, I have recently need to apply a patch to gnuplot to add some functionality. I applied it to the developer version of gnuplot (4.2). However, it seem that the aqua terminal is not an option for this version. Do you have any advice? Should I apply the patch to the current release version instead? Or are there some compile options that I can turn on to make it available? Regards, Daniel. |
|
From: Joe K. <jko...@co...> - 2006-10-12 16:06:53
|
on 10/12/06 9:01 AM, Daniel Farrell at boy...@gm... wrote: > Hello, > > I have recently need to apply a patch to gnuplot to add some > functionality. I applied it to the developer version of gnuplot > (4.2). However, it seem that the aqua terminal is not an option for > this version. Do you have any advice? Should I apply the patch to the > current release version instead? Or are there some compile options > that I can turn on to make it available? > > Regards, > > Daniel. > Daniel, AquaTerm works with gnuplot-4.2.rc1 on my G5 Mac built with OS X 10.4.8 and Xcode-2.4 developer tools. I did nothing more than my old configuration for gnuplot-4.0 to build it. All my old gnuplot and octave routines work properly with AquaTerm. The only issue that I have with AquaTerm is that octave now passes figure numbers via the gnuplot command line, not with set term. This means that all figures are Figure 0 for octave/gnuplot/aqua, which can become confusing when several windows are open. The wxt terminal will have the same issue. Joe |
|
From: Daniel F. <boy...@gm...> - 2006-10-12 17:41:16
|
Hi Joe,
Thanks for that, this seems quite strange but probably means I'm
doing something wrong! I just replaced the old version with the new
developer version (4.2 rc1) in /usr/local/bin and left my system
configuration the same too. gnuplot 4.2 rc1 gives out the following
when started:
set term aqua
^
".gnuplot", line 1: unknown or ambiguous terminal type; type just
'set terminal' for a list
Pretty clear then that my version at least don't know what aqua term
is! Also, in the 'help set term' documentation aqua is not listed as
an option.
I pulled it from cvs, the actually version of is:
$Revision: 1.16 $, dated $Date: 2006/09/10 10:43:50 $.
I'm running MacOS 10.4.8 with XCode 2.4 on a 1.5Ghz G4 PPC.
Regards,
Daniel.
On 12 Oct 2006, at 17:06, Joe Koski wrote:
> on 10/12/06 9:01 AM, Daniel Farrell at boy...@gm... wrote:
>
>> Hello,
>>
>> I have recently need to apply a patch to gnuplot to add some
>> functionality. I applied it to the developer version of gnuplot
>> (4.2). However, it seem that the aqua terminal is not an option for
>> this version. Do you have any advice? Should I apply the patch to the
>> current release version instead? Or are there some compile options
>> that I can turn on to make it available?
>>
>> Regards,
>>
>> Daniel.
>>
> Daniel,
>
> AquaTerm works with gnuplot-4.2.rc1 on my G5 Mac built with OS X
> 10.4.8 and
> Xcode-2.4 developer tools. I did nothing more than my old
> configuration for
> gnuplot-4.0 to build it. All my old gnuplot and octave routines work
> properly with AquaTerm.
>
> The only issue that I have with AquaTerm is that octave now passes
> figure
> numbers via the gnuplot command line, not with set term. This means
> that all
> figures are Figure 0 for octave/gnuplot/aqua, which can become
> confusing
> when several windows are open. The wxt terminal will have the same
> issue.
>
> Joe
>
>
|
|
From: Joe K. <jko...@co...> - 2006-10-12 20:07:43
|
on 10/12/06 11:40 AM, Daniel Farrell at boy...@gm... wrote: > Hi Joe, > > Thanks for that, this seems quite strange but probably means I'm > doing something wrong! I just replaced the old version with the new > developer version (4.2 rc1) in /usr/local/bin and left my system > configuration the same too. gnuplot 4.2 rc1 gives out the following > when started: > > set term aqua > ^ > ".gnuplot", line 1: unknown or ambiguous terminal type; type just > 'set terminal' for a list > > Pretty clear then that my version at least don't know what aqua term > is! Also, in the 'help set term' documentation aqua is not listed as > an option. > > I pulled it from cvs, the actually version of is: > $Revision: 1.16 $, dated $Date: 2006/09/10 10:43:50 $. > > I'm running MacOS 10.4.8 with XCode 2.4 on a 1.5Ghz G4 PPC. > > Regards, > > Daniel. > Daniel, Your config.log should tell you where the configuration script had problems with aqua. It's probably a misplaced header file or some such. Joe > > On 12 Oct 2006, at 17:06, Joe Koski wrote: > >> on 10/12/06 9:01 AM, Daniel Farrell at boy...@gm... wrote: >> >>> Hello, >>> >>> I have recently need to apply a patch to gnuplot to add some >>> functionality. I applied it to the developer version of gnuplot >>> (4.2). However, it seem that the aqua terminal is not an option for >>> this version. Do you have any advice? Should I apply the patch to the >>> current release version instead? Or are there some compile options >>> that I can turn on to make it available? >>> >>> Regards, >>> >>> Daniel. >>> >> Daniel, >> >> AquaTerm works with gnuplot-4.2.rc1 on my G5 Mac built with OS X >> 10.4.8 and >> Xcode-2.4 developer tools. I did nothing more than my old >> configuration for >> gnuplot-4.0 to build it. All my old gnuplot and octave routines work >> properly with AquaTerm. >> >> The only issue that I have with AquaTerm is that octave now passes >> figure >> numbers via the gnuplot command line, not with set term. This means >> that all >> figures are Figure 0 for octave/gnuplot/aqua, which can become >> confusing >> when several windows are open. The wxt terminal will have the same >> issue. >> >> Joe >> >> > |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-10-12 17:34:36
|
On Thursday 12 October 2006 09:12 am, Daniel J Sebald wrote:
> > "settransfer" is Level 2 PostScript, so your patch needs to
> > check the "level1" flag and/or check for support dynamically.
>
> I thought I read "settransfer" is Level 1 and "setcolortransfer" is
> Level 2.
You are correct.
I had not realized there was a distinction between them.
So "settransfer" should be OK by itself.
However, there is a little more to it...
The PostScript Language Reference Manual (3rd Edition) says:
Because the effect of the transfer function is device-dependent
settransfer should not be used in a page description that is intended
to be device-independent. Execution of this operator is not permitted
in certain circumstances; see Section 4.8.1, Types of Color Space.
Section 4.8.1 is rather long, but the relevant bit seems to be:
In certain circumstances, it is illegal to invoke operators that
specify colors or other color-related parameters in the graphics
state. This restriction occurs when defining graphical figures whose
colors are to be specified separately each time they are used.
Specifically, the restriction applies:
* After execution of setcachedevice or setcachedevice2 in a
BuildGlyph, BuildChar, or CharStrings procedure of a font dictionary
* In the PaintProc procedure of an uncolored tiling pattern
I don't think the setcachedevice restriction is relevant to gnuplot,
but gnuplot's pattern-fill does use PaintProc in uncolored tiling
patterns.
No idea what this means in practice, however. Perhaps it just means
that the gamma correction wouldn't affect the color of pattern fill
areas. That would be no big deal.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: Daniel J S. <dan...@ie...> - 2006-10-12 18:35:06
|
Ethan Merritt wrote: > So "settransfer" should be OK by itself. > However, there is a little more to it... There was a lot there to read. > The PostScript Language Reference Manual (3rd Edition) says: > > Because the effect of the transfer function is device-dependent > settransfer should not be used in a page description that is intended > to be device-independent. One would think that the PostScript interpretter would be smart enough to separate the settransfer and possibly remove it. I guess the assumption is that the interpretter might have its own gamma correction. Not sure. > I don't think the setcachedevice restriction is relevant to gnuplot, > but gnuplot's pattern-fill does use PaintProc in uncolored tiling > patterns. > > No idea what this means in practice, however. Perhaps it just means > that the gamma correction wouldn't affect the color of pattern fill > areas. That would be no big deal. I was hoping that the "gsave" isolates the transfer function for the image from that for the rest of the plot. But I'm not sure if PostScript works that way. Dan |
|
From: <br...@ph...> - 2006-10-12 20:30:43
|
Daniel Farrell wrote:
> I have recently need to apply a patch to gnuplot to add some
> functionality. I applied it to the developer version of gnuplot
> (4.2). However, it seem that the aqua terminal is not an option for
> this version.
It's an option for this version alright --- just not for your
compilation of it. Something must have gone wrong at "configure" time.
Probably you don't have all the libraries and headers installed to
compile programs using aqua; or they're in the wrong place.
|
