« Return to Thread: Image resolution not preserved
Re: Image resolution not preserved
by Ken Sharp
::
Rate this Message:
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
>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
« Return to Thread: Image resolution not preserved
| Free embeddable forum powered by Nabble | Forum Help |
