Bug 690125 - Gradient / Fill Pattern Conversion Issues
Summary: Gradient / Fill Pattern Conversion Issues
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: 8.63
Hardware: PC Windows XP
: P4 enhancement
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-17 09:01 UTC by Ralph Capasso
Modified: 2016-04-11 02:36 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Original PDF test case (1.46 KB, application/pdf)
2012-10-29 10:38 UTC, Christophe Braud
Details
CMYK to RGB transformation (841.89 KB, application/pdf)
2012-10-29 10:39 UTC, Christophe Braud
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Capasso 2008-10-17 09:01:20 UTC
I am attempting to convert a pdf document that contains a gradient
from CMYK to RGB using -dUseCIEColor option with the /
ColorConversionStrategy set to /sRGB.  As a result, the file size
increaes dramatically  One of our test files increased from 104K to
34MB.  The file renders correctly in a Acrobat Reader and GSView,
however, it takes an excessive amount of time.

The output pdf files are intended for online use, therefore, the
larger output is unacceptable.

Here is the command I am using to render the PDF:
gswin32c.exe -dSAFER -dNOPAUSE -dNOPAGEPROMPT -dSHORTERRORS -dBATCH -
sDEVICE#pdfwrite -dPDFX#true -sOutputFile#output.pdf -f
000002.joboptions input.pdf

The contents of 000002.joboptions are:
----Start File----
<<
       /ColorConversionStrategy /sRGB
>> setdistillerparams
<<
 /HWResolution [1200 1200]
 /PageSize [612.000 792.000]
>> setpagedevice
----End File----

With the -dUseCIEColor set, GS transforms the gradient into a
colorimage:

colorimage
s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!
s8W-!
...

I retrieved the ps output using this command.
gswin32c.exe -dSAFER -dNOPAUSE -dNOPAGEPROMPT -dSHORTERRORS -dBATCH -
sDEVICE#pswrite -sOutputFile#output-ps.ps  input-gradient.pdf

If -dUseCIEColor is not specified, the pdf converts correctly; the
file size is acceptable, render speed in the viewer is good, and all
images are converted to RGB.  However, the color translation is poor
and the output in regards to color is unacceptable.

Please let me know if anyone knows a way to resolve or workaround this
issue.

Thanks,
  Ralph
Comment 1 Ray Johnston 2008-10-17 10:08:55 UTC
Please attach the input.pdf so we can look into this.

If you wish, you can 'Edit' the attachment after you attach it and mark it as
'Private' so only Artifex staff can access it.

I've fixed the 'Component' to PDF writer (instead of PDF Interpreter). Once
we have the file and have duplicated the issue, we can assign it to the
correct person.
Comment 2 Ralph Capasso 2008-10-17 11:11:48 UTC
Created attachment 4517 [details]
Input File with Gradient

Attached is an example input.pdf discussed in this bug.
Comment 3 Ralph Capasso 2008-10-17 11:12:40 UTC
I have posted the input file. Please let me know if you need any additional
data.  Thanks for the quick response.

-Ralph
Comment 4 Ray Johnston 2008-10-23 09:42:58 UTC
I was able to duplicate the problem of creating a very large PDF file from the
attached file using:

gswin32c -dUseCIEColor -sDEVICE=pdfwrite -o x.pdf -c "<<   
/ColorConversionStrategy /sRGB >> setdistillerparams" -f input.pdf
Comment 5 Ken Sharp 2008-10-25 03:11:16 UTC
Hmm...

Setting the resolution to 1200 is inappropriate for a PDF file intended for
online use, the conversion to image takes the resolution into account, which is
why the output is so large. You can reduce the file size by reducing the
resolution, if you intend to print this at 1200 dpi you can probably reduce the
resolution to 300, which will result in an image 16 times smaller than at present.

If you don't specify UseCIEColor, the blend will be retained in (not converted
to) RGB. I'm surprised that colour fidelity is critical in an online document,
what are you using for a DefaultRGB colour space array ?

The reason that the blend is converted to an image, is because its hard (and
impossible in the general case) to convert a function which takes a single
parameter and returns an RGB colour into a function which takes the same
parameter and returns the 'same' colour in an arbitrary CIE space (which is what
UseCIEColor is doing).

The best that can be done is to convert the original function into a sampled
function, by sampling the final CIE colour space and using that to generate the
CIE colours for the gradient. This will *not* work for type 1 (function based)
shadings at all, and will give different answers to the image for other shading
types. Figuring out how many samples to take (unsampled values will have to be
interpolated) is going to be interesting.

I'm altering this to an enhancement, because the action at the moment is as
expected (so it isn't a bug), and produces a reasonable result even if it is
less than optimal.

Comment 6 Ralph Capasso 2008-10-25 07:38:16 UTC
Ke,

Thank you for your response.  You have provided me with a viable solution.  I
have reduced the resolution to 150dpi (via "-r" option) and the output is
perfectly acceptable.  I did not realize that the resolution of the rendered
gradient was producing 1200dpi output.  We definitely do not want that for
online.  I falsely assumed the resolution was inherited from the passed in
Distiller settings.  My sample excluded the Distiller image resample settings
because they didn't appear to have any effect which they do not.  Setting the
"-r" option produces perfectly usable output.

Thank you again for your help in resolving this issue. 

Best,
   Ralph
Comment 7 Christophe Braud 2012-10-11 15:32:28 UTC
Sorry to answer a 4yr old bug, but i have the same problem. 

I need to do a CMYK to RGB transformation for mobile device. My PDF contains multiple gradiants that are tranformed into "drawings". The result is very ugly, file are large and rendering take too musch time.

Can someone tell me if it's possible to ignore this type of filling when doing this conversion ? Or maybe a gradiant to PNG (like popple/GS do when doing pdf>ps>pdf conversion) ?

Thanks
Comment 8 Ken Sharp 2012-10-29 10:00:36 UTC
(In reply to comment #7)

> I need to do a CMYK to RGB transformation for mobile device. My PDF contains
> multiple gradiants that are tranformed into "drawings". The result is very
> ugly, file are large and rendering take too musch time.
> 
> Can someone tell me if it's possible to ignore this type of filling when doing
> this conversion ? Or maybe a gradiant to PNG (like popple/GS do when doing
> pdf>ps>pdf conversion) ?

Please read comment #5, using a lower resolution should be perfectly acceptable on a mobile device. The code *already* does a conversion to an image, that's why the output is large. You cannot convert to a PNG as PNG is not a supported image format in PDF (or PostScript for that matter).

Ignoring the gradients would be a 'bad thing' as the result would not be correct.
Comment 9 Christophe Braud 2012-10-29 10:38:21 UTC
Created attachment 9038 [details]
Original PDF test case
Comment 10 Christophe Braud 2012-10-29 10:39:06 UTC
Created attachment 9039 [details]
CMYK to RGB transformation
Comment 11 Christophe Braud 2012-10-29 10:42:00 UTC
(In reply to comment #8)

I attached two files where you can see that gradiant are not transform into PNG but into PDF script drawing (line by line approx !). I have an option to have an image, I'd love to use it :).
Comment 12 Ken Sharp 2012-10-29 16:14:27 UTC
(In reply to comment #11)

> I attached two files where you can see that gradiant are not transform into PNG
> but into PDF script drawing (line by line approx !). I have an option to have
> an image, I'd love to use it :).

Its not the same problem, as you already know because in your case the file does not decompose to a bitmap. Please don't lump 'similar' problems into existing bugs.

Your original shading is in DeviceRGB and does not need to be converted to RGB  at all. If I simply run a conversion here it is *not* converted. So there must be something about the command line you are using (which you haven't given) which is causing this.


In your case the file contains (spurious) transparency declarations (because the file has been produced by Cairo). and I presume this is causing the decomposition into rectangles, but it doesn't happen for me.
Comment 13 Ken Sharp 2016-04-11 02:36:45 UTC
For shadings of this type, when converting to a different colour space, pdfwrite now samples the input colour space, converts the samples to the required output space and writes a function to map the original input to the corresponding required output components. In short it now converts a function mapping values to colour samples in a given space to a function mapping values to colour samples in a different space.

For me this results in a file 30% smaller than the original supplied file, and the results are indistinguishable from the original (because the image on page 1 is a JPEG there are the usual problems caused by re-encoding to JPEG).

The file supplied in comment #7 did not cause a problem at the time, and still does not cause a problem with any command line I can concoct. Possibly there is a genuine problem here but, as noted at the time, its definitely not the same problem as the original report (as the shadings do not need converting). It is barely possible, since the file contains nonsense transparency operations, that an older version of the code degenerated to rectangles, but that seems unlikely. However in the absence of a command line, or a version number, and the fact that its not the same problem anyway, I'm going to ignore this one.