Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #2213 > unrolled thread

Ghostscript pickling settransfer

Back to article view | Back to comp.lang.postscript

Contents

  Ghostscript pickling settransfer jdaw1 <jdawiseman@gmail.com> - 2015-04-14 14:01 -0700
    Re: Ghostscript pickling settransfer ken <ken@spamcop.net> - 2015-04-15 08:15 +0100
      Re: Ghostscript pickling settransfer jdaw1 <jdawiseman@gmail.com> - 2015-04-15 01:45 -0700
        Re: Ghostscript pickling settransfer ken <ken@spamcop.net> - 2015-04-15 10:04 +0100
          Re: Ghostscript pickling settransfer jdaw1 <jdawiseman@gmail.com> - 2015-04-17 01:35 -0700
            Re: Ghostscript pickling settransfer ken <ken@spamcop.net> - 2015-04-17 10:07 +0100
              Re: Ghostscript pickling settransfer jdaw1 <jdawiseman@gmail.com> - 2015-04-18 02:01 -0700
                Re: Ghostscript pickling settransfer ken <ken@spamcop.net> - 2015-04-18 11:23 +0100
                  Re: Ghostscript pickling settransfer jdaw1 <jdawiseman@gmail.com> - 2015-04-25 15:06 -0700
                    Re: Ghostscript pickling settransfer jdaw1 <jdawiseman@gmail.com> - 2015-05-15 06:37 -0700
                      Re: Ghostscript pickling settransfer ken <ken@spamcop.net> - 2015-05-15 15:37 +0100
                        Re: Ghostscript pickling settransfer Carlos <angus@quovadis.com.ar> - 2015-05-15 19:45 +0200
                          Re: Ghostscript pickling settransfer ken <ken@spamcop.net> - 2015-05-16 09:03 +0100

#2213 — Ghostscript pickling settransfer

In a thread entitled 'An empty correspondence with the CEO of Adobe Systems'
https://groups.google.com/forum/#!topic/comp.lang.postscript/_yxo2ZDiUnU

JDAW wrote:
> GhostScript ... encodes settransfer in a manner heeded by Acrobat
> Reader but ignored by Mac Preview

Ken wrote:
> If the settransfer is ignored by Mac Preview, even though its
> valid, surely this is a problem with Mac Preview, not pdfwrite ?

and later wrote
> FWIW, you are correct that Distiller is pickling the transfer funtion
> into the colours in the PDF file, while Ghostscript is preserving the
> transfer funtion.


Please, good people of comp.lang.postscript, is there any way in PostScript to force Ghostscript to 'pickle' settransfer? Doing it in the system call to Ghostscript doesn't work for me: it has to be in the PostScript. Is that possible?

[toc] | [next] | [standalone]

#2214

In article <96e660b0-b16f-46b9-8f27-a1245803224f@googlegroups.com>, 
jdawiseman@gmail.com says...
> 
> In a thread entitled 'An empty correspondence with the CEO of Adobe Systems'
> https://groups.google.com/forum/#!topic/comp.lang.postscript/_yxo2ZDiUnU
> 
> JDAW wrote:
> > GhostScript ... encodes settransfer in a manner heeded by Acrobat
> > Reader but ignored by Mac Preview
> 
> Ken wrote:
> > If the settransfer is ignored by Mac Preview, even though its
> > valid, surely this is a problem with Mac Preview, not pdfwrite ?
> 
> and later wrote
> > FWIW, you are correct that Distiller is pickling the transfer funtion
> > into the colours in the PDF file, while Ghostscript is preserving the
> > transfer funtion.
> 
> 
> Please, good people of comp.lang.postscript, is there any way in PostScript to force Ghostscript to 'pickle' settransfer? Doing it in the system call to Ghostscript doesn't work for me: it has to be in the PostScript. Is that possible?


Possibly you could redefine setcolor, setgray, setrgbcolor, 
setcmykcolor, sethsbcolor. The modified operation could apply the 
transfer function when setting the color.

Of course you would also have to do this for image, colorimage, 
imagemask and you would have to be extra careful with type 4 chrom-keyed 
masked images to ensure that you alter the mask color as well as the 
image data.

Then there's shfill, where you would have to recalculate the colours to 
include the transfer function.


Of course you are NOT supposed to apply transfer functoins like this, 
the transfer function only applies to a single colour space, and is 
intended to be applied after incoing colours have been converted into 
device space. Page 479 of the PLRM says:

"Transfer functions always operate in the native color space of the 
output device, regardless of the color space in which colors were 
originally specified."

So what *is* the native colour space of a PDF file ?


Also transfer functions are supposed to be device-specific, page 3 of 
the 3rd edition PLRM makes ths quite clear:

"Chapter 7, ?Rendering,? details the device-dependent aspects of 
rendering page descriptions on raster output devices (printers and 
displays). These include color rendering, transfer functions, 
halftoning, and scan conversion, each of which is device-dependent in 
some way."


Older versions of the specification, if I remember correctly, used to 
say that transfer functions should not be used to achieve special 
effects. Sadly a number of applications (Quark Xpress being a notable 
offender) ignored that and the 3rd edition PLRM acknowledges that ths is 
possible merely saying:

"Because transfer functions produce device-dependent effects, a page 
description that is intended to be device independent should not alter 
them."


Its not too hard to apply a single transfer function (ie a gray space) 
to all the components of simple spaces like RGB or CMYK, its not at all 
clear to me how you would apply it to, for example, a CIEBased colour 
space. I don't think that inverting the channels of a CIELab space will 
get you the inverse result. I should probably try that out......

Anyway, while its possible to alter a PostScript program to apply 
transfer functions as colours are specified, it looks lilke it would be 
quite a lot of work to me.


				Ken

[toc] | [prev] | [next] | [standalone]

#2215

As is typical on comp.lang.postscript, the answer is expert and quick. 

So it can't be done in PostScript.

> Possibly you could redefine setcolor, setgray, 
> setrgbcolor, setcmykcolor, sethsbcolor. 
Wouldn't work if the user of my code has bind'd the passed code parameters.

But it is strange that Distiller copes, even if the standard says it shouldn't. Perhaps Ghostscript is being more royalist than the King.

[toc] | [prev] | [next] | [standalone]

#2216

In article <39699421-a83d-4b05-bb61-c7730d7d2d02@googlegroups.com>, 
jdawiseman@gmail.com says...
> 
> As is typical on comp.lang.postscript, the answer is expert and quick. 
> 
> So it can't be done in PostScript.
> 
> > Possibly you could redefine setcolor, setgray, 
> > setrgbcolor, setcmykcolor, sethsbcolor. 
> Wouldn't work if the user of my code has bind'd the passed code parameters.
> 
> But it is strange that Distiller copes, even if the standard says it shouldn't. Perhaps Ghostscript is being more royalist than the King.

Not really. As I intimateed, its a difficult problem to see an answer 
to, especially when the colour spaces are not device spaces (ordinarily 
transfer funxtions can only be applied to device spaces, when 
rendering).

Device spaces are relatively easy to deal with, though if you had a 
colour transfer for a different space it would likely be difficult to 
apply it (what does it mean to apply a CMYK 4 channel transfer function 
to an RGB 3 channel space ? Which CMYK channel maps to which RGB channel 
?)

Separation and DeviceN spaces are, perhaps surprisingly, easy. At least 
for a single transfer function. They could be handled by applying the 
transfer function to each channel when the colour is specified, and 
altering the tint transform to incorporate the transfer into the device 
space tint transformation. However the same problem with colour transfer 
functions applies here as well.

I'm unsure how one would go about applying even a simple gray ramp 
transfer function to a complex space such as a CIEBased space (eg Lab) 
without converting the space into a device space.

I'm inclined to feel that applying transfer functions is likely to lead 
to odd results, but I would have to try it out with Distiller to see 
exactly what its doing with the more complex cases.

Because transfer functions are spcified as working in device space, 
applying them to something that *isn't* a device space is fraught with 
problems.

The whole original point of a transfer function was that it was device-
specific, so you could strip it out and replace it with a new one if you 
went to a different devioe.

Possibly we could come up with a means to implement this, yes, but it 
would be a new feature and would have to be done in the kernal code 
where we currently do colour space trnsformations. Its probably not 
impossible, but it *is* a lot of work.

And all because some PDF consumers can't correctly handle the existence 
of a transfer function......


		Ken

[toc] | [prev] | [next] | [standalone]

#2217

Just to be clear, my original question asked whether I can do this in my PostScript code (answer: no) rather than whether it should be done in the Ghostscript code (too much work for nonsensical gain). 

For completeness, my need is only about grays, a typical form being:
[ currenttransfer   /exec cvx   1   /exch cvx   /sub cvx  0.25  /mul cvx   1   /exch cvx   /sub cvx ] cvx bind settransfer

But the painting code might be supplied by my user, and be bind'd, thus disallowing the obvious redefinitions.

[toc] | [prev] | [next] | [standalone]

#2218

In article <38767aa8-82d4-4aa7-b8d6-7eea3d43f7ba@googlegroups.com>, 
jdawiseman@gmail.com says...
> 
> Just to be clear, my original question asked whether I can do this in my PostScript code (answer: no) rather than whether it should be done in the Ghostscript code (too much work for nonsensical gain). 
> 
> For completeness, my need is only about grays, a typical form being:
> [ currenttransfer   /exec cvx   1   /exch cvx   /sub cvx  0.25  /mul cvx   1   /exch cvx   /sub cvx ] cvx bind settransfer
> 
> But the painting code might be supplied by my user, and be bind'd, thus disallowing the obvious redefinitions.

Presumably as long as you redefne the operators before your users code 
runs, that shouldn't be a problem ?

For Ghostscript only; you can bind the systemdict definitions of 
operators so that should allow you to overcome any name binding done by 
the users code.

Or perhaps I simply don't fully appreciate the problem. In any event, 
doing ths in PostScript would seem to be quite a lot of work too.


		Ken

[toc] | [prev] | [next] | [standalone]

#2219

> Or perhaps I simply don't fully appreciate the problem. In any event, 
> doing ths in PostScript would seem to be quite a lot of work too.

This seems to be the key message. 



> Presumably as long as you redefne the operators before your users code 
> runs, that shouldn't be a problem ?

This is a 'fault' of the structure of my program, but the users def the parameters before my code is run. So not really.


Perhaps the best course would be to submit a bug report to Apple. Please, how should I best describe what Preview is failing to do?

[toc] | [prev] | [next] | [standalone]

#2220

In article <3934ebd5-4761-4622-86e7-88659475adb3@googlegroups.com>, 
jdawiseman@gmail.com says...
 
> > Presumably as long as you redefne the operators before your users code 
> > runs, that shouldn't be a problem ?
> 
> This is a 'fault' of the structure of my program, but the users def the parameters before my code is run. So not really.

I was thinking of something that would have to be run at the Ghostscript 
startup, since it would need to use some GS-specific stuff like 
delaybind so I guess not approriate anyway.

 
> Perhaps the best course would be to submit a bug report to Apple. Please, how should I best describe what Preview is failing to do?

It is failing to apply the transfer function defined in the graphcis 
state.



			Ken

[toc] | [prev] | [next] | [standalone]

#2225

Just to connect the two threads, this problem was previously discussed in 
https://groups.google.com/forum/#!topic/comp.lang.postscript/NJLAfvN_jwU

[toc] | [prev] | [next] | [standalone]

#2270

I have just discovered, in 'Adobe Acrobat 7.0.5 Acrobat Distiller Parameters, 2 Oct 2005', page 92, the parameter TransferFunctionInfo. 
> Determines how Distiller handles transfer functions, which are traditionally used to compensate for dot gain or dot loss that may occur when an image is transferred to film. For example, a file that is intended for output on a particular imagesetter may contain transfer functions that compensate for the dot gain inherent with that printer.  Valid values are: 
> Preserve
> Distiller preserves (passes into the PDF file) transfer functions.
> Remove
[...]
> Apply
> Distiller uses the transfer function to modify the data it writes to the PDF file, instead of writing the transfer function itself to the file. This value is ignored by Distiller 4.0 but supported by Distiller 5.0 and later. It is sometimes used to achieve artistic effects (although the PostScript Language Reference discourages such usage).

Apply seems to be 'Pickle'. Hurray! Does Ghostscript heed TransferFunctionInfo?

[toc] | [prev] | [next] | [standalone]

#2271

In article <db2c3a8f-f4a3-4624-824b-11aeeca3fab4@googlegroups.com>, 
jdawiseman@gmail.com says...
> 
> I have just discovered, in 'Adobe Acrobat 7.0.5 Acrobat Distiller Parameters, 2 Oct 2005', page 92, the parameter TransferFunctionInfo. 
> > Determines how Distiller handles transfer functions, which are traditionally used to compensate for dot gain or dot loss that may occur when an image is transferred to film. For example, a file that is intended for output on a particular imagesetter may contain transfer functions that compensate for the dot gain inherent with that printer.  Valid values are: 
> > Preserve
> > Distiller preserves (passes into the PDF file) transfer functions.
> > Remove
> [...]
> > Apply
> > Distiller uses the transfer function to modify the data it writes to the PDF file, instead of writing the transfer function itself to the file. This value is ignored by Distiller 4.0 but supported by Distiller 5.0 and later. It is sometimes used to achieve artistic effects (although the PostScript Language Reference discourages such usage).
> 
> Apply seems to be 'Pickle'. Hurray! Does Ghostscript heed TransferFunctionInfo?
 
That's the same as setting it from the Distiller user interface.

So the answer is still 'No', the pdfwrite device always writes transfer 
functions into the grpahcs state, it never applies them.

	Ken

[toc] | [prev] | [next] | [standalone]

#2273

[ken <ken@spamcop.net>, 2015-05-15 15:37]
> In article <db2c3a8f-f4a3-4624-824b-11aeeca3fab4@googlegroups.com>, 
> jdawiseman@gmail.com says...
> > 
> > I have just discovered, in 'Adobe Acrobat 7.0.5 Acrobat Distiller
> > Parameters, 2 Oct 2005', page 92, the parameter
> > TransferFunctionInfo. 
> > > Determines how Distiller handles transfer functions, which are
> > > traditionally used to compensate for dot gain or dot loss that
> > > may occur when an image is transferred to film. For example, a
> > > file that is intended for output on a particular imagesetter may
> > > contain transfer functions that compensate for the dot gain
> > > inherent with that printer.  Valid values are: Preserve Distiller
> > > preserves (passes into the PDF file) transfer functions. Remove
> > [...]
> > > Apply
> > > Distiller uses the transfer function to modify the data it writes
> > > to the PDF file, instead of writing the transfer function itself
> > > to the file. This value is ignored by Distiller 4.0 but supported
> > > by Distiller 5.0 and later. It is sometimes used to achieve
> > > artistic effects (although the PostScript Language Reference
> > > discourages such usage).
> > 
> > Apply seems to be 'Pickle'. Hurray! Does Ghostscript heed
> > TransferFunctionInfo?
>  
> That's the same as setting it from the Distiller user interface.
> 
> So the answer is still 'No', the pdfwrite device always writes
> transfer functions into the grpahcs state, it never applies them.

Maybe need to change the documentation then...

http://www.ghostscript.com/doc/9.16/Ps2pdf.htm#note_4

Btw, Ghostscript does apply the transfer function when writing to
another vector based format, Microsoft's XPS (the driver is incomplete
in other respects tho).

C.
-- 

[toc] | [prev] | [next] | [standalone]

#2274

In article <20150515194502.11569f06@samara.DOMA>, angus@quovadis.com.ar 
says...

> > So the answer is still 'No', the pdfwrite device always writes
> > transfer functions into the grpahcs state, it never applies them.
> 
> Maybe need to change the documentation then...
> 
> http://www.ghostscript.com/doc/9.16/Ps2pdf.htm#note_4

Obviously a typo, it shoudl be 'always preserved'.

 
> Btw, Ghostscript does apply the transfer function when writing to
> another vector based format, Microsoft's XPS (the driver is incomplete
> in other respects tho).

The XPS output code is *much* cruder than the PDF output code. It has 
been improved slightly recently but it still comes close to being an 
image wrapped up as an XPS file.

Also XPS doens't have as rich a colour model as PDF< and doesn't have 
the concept of transfer functions either, as I recall.


			Ken

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web