Image resolution not preserved

[birksworks]

I'm using ghostscript to embed fonts in some existing pdf documents. The options
 -dEmbedAllFonts=true
 -dSubsetFonts=false
do this for me but the images in the resulting pdf document  have a lower resolution (72dpi) than those of the original document (300dpi).  I've tried setting many options that could affect this:

 -sDEVICE=pdfwrite
 -q
 -r300
 -dBATCH
 -dNOPAUSE
 -dSAFER
 -dPDFX
 -dPDFSETTINGS=/prepress
 -dEmbedAllFonts=true
 -dSubsetFonts=false
 -dJPEGQ=100
 -dAutoFilterColorImages=false
 -dColorImageFilter=/FlateEncode
 -dAutoFilterGrayImages=false
 -dGrayImageFilter=/FlateEncode
 -dUseFlateCompression=true
 -dTextAlphaBits=4
 -dGraphicsAlphaBits=4
 -dMaxSubsetPct=100
 -dAutoFilterMonoImages=false
 -dMonoImageFilter=/CCITTFaxEncode
 -dCompatibilityLevel=1.3

but with no luck.  Can anyone suggest a way to preserve image resolutions?

Thanks,
Bob

[Ken Sharp]

At 07:55 13/11/2009 -0800, birksworks wrote:


>but with no luck.  Can anyone suggest a way to preserve image resolutions?

Ghostscript already preserves images at their native resolution in general,
and even when it does not (for example flattening transparency) it uses the
specified resolution, in your case 300 dpi.

How are you determining the image resolution of the original images, and
the images in the created PDF file ?

You don't say which version of Ghostscript you are using, nor which
platform you are running on, and obviously you haven't supplied a test file
for us to look at, its going to be pretty nearly impossible to help you
without all that information. BTW you also don't seem to have discovered
the image downsample controls 'xxxImageDownsampleThreshold' and
'xxxImageDownsampleType'

If you are using the latest version of Ghostscript, and are sure this is
still a problem, then your best bet is to open a bug report at:

http://bugs.ghostscript.com

Once the report is open you can attach files to it, if they are sensitive
then you can mark them as private, which limits their availability to
Artifex employees.



                 Ken

_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[birksworks]

Thanks for the help, Ken and dingodog.  

I should have mentioned that I'm using Ghostscript 8.64 on Ubuntu 9.10.  I will create a simple test version of my file that reproduces the problem and make it available to the list.

Bob

[birksworks ()]

I've uploaded three files. The first (http://www.calcworks.net/pdf/input.pdf) is a small test file with images at 300dpi, the second (http://www.calcworks.net/pdf/output-few.pdf) was obtained by running GhostScript on the input file with the following minimal options

gs -sDEVICE=pdfwrite -q -dBATCH -dNOPAUSE -dSAFER -dPDFX -dPDFSETTINGS=/prepress -dEmbedAllFonts=true -dSubsetFonts=false -sOutputFile=output-few.pdf -f input.pdf -c quit

and the third (http://www.calcworks.net/pdf/output-many.pdf) was obtained by running GhostScript on the input file with the following many options

gs -sDEVICE=pdfwrite -q -r300 -dBATCH -dNOPAUSE -dSAFER -dPDFX -dPDFSETTINGS=/prepress -dEmbedAllFonts=true -dSubsetFonts=false -dJPEGQ=100 -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -dUseFlateCompression=true -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dMaxSubsetPct=100 -dAutoFilterMonoImages=false -dMonoImageFilter=/CCITTFaxEncode -dCompatibilityLevel=1.3 -dDownsampleColorImages=false -dDownsampleGrayImages=false -dDownsampleMonoImages=false -sOutputFile=output-many.pdf -f input.pdf -c quit

PDF Checkpoint says that output-few has images at 30dpi and that output-many has images at 72dpi. Of course, this could be a bug in PDF Checkpoint but since we couldn't find many other checkers, we decided to be cautious. If this checker gets it wrong (while getting others right), then perhaps other apps in a printer's workflow will be confused too.

Bob

[birksworks]

I've added links to the three pdf file:

http://www.calcworks.net/pdf/input.pdf
http://www.calcworks.net/pdf/output-few.pdf
http://www.calcworks.net/pdf/output-many.pdf

Bob

[Ken Sharp]

At 16:00 17/11/2009 -0800, birksworks wrote:


>PDF Checkpoint says that output-few has images at 30dpi and that output-many
>has images at 72dpi.

And what does it say about input.pdf ?

input.pdf specifies the image like this:

<<
/ColorSpace /DeviceGray
/Subtype /Image
/Length 323135
/Width 594
/Type /XObject
/BitsPerComponent 8
/Height 544
 >>

The amount of data is given by the Width and Height keys. This image is 594
samples wide and 544 samples high. Notice that no resolution is given, the
effective resolution of the image is given by seeing how large the area
covered is.

To start with in PostScript and PDF the image is assumed to cover the unit
square, and then the current transformation matrix is applied to scale it
into the desired output.

In your case this is given as :

142.5 0 0 130.5 0 2.072713 cm

So your image is scaled anamorphically, by a factor of 142.5 in the x
direction and 130.5 in the y direction. So your image now covers 142.5
units by 130.5 units. PDF units (like PostScript) are 72 to the inch, so
your image covers 1.98 inches by 1.81 inches (looks about right by visual
inspection).

I used the Acrobat Pro 9 measurement tools to verify this (screenshot
attached).

You image is therefore 594/1.98 = 300 dpi by 544/1.81 = 300.55 dpi.
Confirming your resolution.

Looking at output-few.pdf we see that the pdfwrite output is a little more
complex, and involves concatenated CTM operations. However, the image is
still defined as:

<<
/ColorSpace /DeviceGray
/Subtype /Image
/Filter /FlateDecode
/DecodeParms
<<
/Columns 594
/Predictor 15
 >>
/Length 97092
/Width 594
/Height 544
/BitsPerComponent 8
 >>

It has the same dimensions as before, so pdfwrite has preserved the image
resolution. Looking at the content stream we see:

q 0.1 0 0 0.1 0 0 cm
...
...
q 1425 0 0 1305 293.465 6261.06 cm
/R14 Do

The two cm operations are cumulative, so the actual CTM in force is :
142.5 0 0 130.5 29.3465 626.106. The calculation is thus the same as above,
and the resolution of the image is the same.

Finally we look at output-many.pdf and we see the same image yet again:

<<
/ColorSpace /DeviceGray
/Subtype /Image
/Filter /FlateDecode
/DecodeParms
<<
/Columns 594
/Predictor 15
 >>
/Length 97092
/Width 594
/Height 544
/BitsPerComponent 8
 >>

Because you have specified a resolution of 300 instead of the default 720
the numbers are a little different in the content stream:

q 0.24 0 0 0.24 0 0 cm
...
...
q 593.75 0 0 543.75 122.277 2608.77 cm
/R16 Do

We concatenate the matrix operations as before, yielding a CTM of
593 x 0.24 = 142.5
0
0
543.75 x 0.24 = 130.5
122.27 x 0.24 = 29.3448
2608.77 x 0.24 = 626.1048

The important values, the x and y scale are the same as the previous 2
cases, and therefore the image has the same resolution, 300 dpi.

Now, your PDF Checkpoint tool is out by a factor of 10 in the case of
output-few.pdf, which is exactly the scale factor applied by the initial
'cm' operation. In the case of output-many.pdf it is out by a factor of
4.166 which is exactly the same as the scale factor in the initial 'cm'
operation in that file (0.24).

It seems clear to me that the application is *not* properly interpreting
the PDF file, it looks like it is assuming that each 'cm' operation is
atomic rather than cumulative and only seems to be tracking the last such
operation. As a result it is applying only that matrix to the image to
determine its resolution. It should be applying the combined effect of the
matrices.


>  Of course, this could be a bug in PDF Checkpoint but
>since we couldn't find many other checkers, we decided to be cautious. If
>this checker gets it wrong (while getting others right), then perhaps other
>apps in a printer's workflow will be confused too.

The only app you should need to worry about is a PDF interpreter, since it
will be guided by what's in the PDF file, it won't get confused. If it
does, then its a bug in the application and you should report it to the
authors. There isn't anything we can do about other people's bugs.



                 Ken

_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[birksworks]

Thanks for the detailed explanation!  It's useful to understand exactly where things went wrong.  We have forwarded them to the PDF Checkpoint developer.  One last question:

The picture isn't distorted (i.e. the aspect ratio is visibly correct), so I assume the different x/y scaling is hard coded by the Python software to make up for rectangular screen pixels.  Does that make sense?  Is there a better solution?

Bob

[Ken Sharp]

At 14:04 18/11/2009 -0800, birksworks wrote:


>The picture isn't distorted (i.e. the aspect ratio is visibly correct), so I
>assume the different x/y scaling is hard coded by the Python software to
>make up for rectangular screen pixels.  Does that make sense?  Is there a
>better solution?

Its not really anything to do with screen pixels or such. As I said in
PostScript and PDF the image is nominally set on a 1x1 unit square, and the
CTM is used to scale that 1x1 co-ordinate space to the desired actual coverage.

If we did no scaling then your image would be placed in a square 1/72 of an
inch on the side, and the resolution would be 594*72 = 42768 dpi in the x
direction and 544*72 = 39168 dpi in the y direction. It would also of
course be distorted ;-)

The scaling is there so that the image covers the expected area, and also
to make sure that it does have the correct aspect ratio. Its just the way
that PostScript and PDF draw images.



                 Ken


_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel