0

Why do I not succeed into making this simple pdf → raster image → pdf round-trip file-size-stable?

$ # Get original file (8KB, just extracted from my scanner).
$ curl "https://nextcloud.mbb.cnrs.fr/nextcloud/s/Rgd4qgmt5mGdifR/download?file=scan.pdf" -o scan.pdf
$ du scan.pdf
8       scan.pdf

$ # Extract image from the file.
$ pdfimages -list scan.pdf
page   num  type   width height color comp bpc  enc interp  object ID x-ppi y-ppi size ratio
--------------------------------------------------------------------------------------------
   1     0 image    1653  2338  gray    1   8  jpeg   no         6  0   200   200 7012B 0.2%

$ pdfimages -all scan.pdf extract
$ du extract-000.jpg
56      extract-000.jpg # Much bigger than inside.

$ # Convert back into a pdf.
$ magick extract-000.jpg back.pdf
$ du back.pdf
32      back.pdf # Much larger than the original.
$ pdfimages -list back.pdf
page   num  type   width height color comp bpc  enc interp  object ID x-ppi y-ppi size ratio
--------------------------------------------------------------------------------------------
   1     0 image    1653  2338  gray    1   8  jpeg   no         8  0   200   200 28.2K 0.7%

What's happening? What are the determinants of file size in these three files?

  • scan.pdf: the original (extracted from a scanner machine) (8KB).
  • extract-000.jpeg: extract with vanilla pdfimages command (56KB).
  • back.pdf: vanilla convert with magick (32KB).

Can I control them? Can I make back.pdf the same size as scan.pdf without loosing image quality?

(the ultimate goal is to crop the image before getting back to pdf, and my question originates from my attempts to cropping surprisingly increasing the cropped result size instead of decreasing it)

2
  • see how these behave so the grayscale slab is 15 KB wrapped in PDF naturally bigger 15.7/15 KB As colour it is smaller 12/11 KB and as minified it is 0.8/0.1 KB all are the same image. However the extractor will produce different results a JPG PNG & JB2e OK but I said the input JPEG and output JPG will be byte identical and they are exactly the same number of bytes so why do they fail the difference test. that is because the GreyJPEG (1653x2338.Gjpg.pdf) is not a true copy of the source JPEG it was degraded from 100 to 95% quality so it was the building in this case caused PDF difference
    – K J
    Commented 2 days ago

1 Answer 1

0

The original scan.pdf (Sharp Scanned ImagePDF) seems to have a double filter encoded image (/Filter [/FlateDecode/DCTDecode]) which was natively scanned as a very poor quality JPEG (20%) then zipped, presumably to be optimally smaller!

Normally the aim with scanning is not to degrade at the scanning stage, thus better lossless LZW compression OR highest quality JPEG 100% would be preferred.

During extraction the image area is unzipped to provide the original poor JPEG which itself at over 50 KB is noticeably large.

My extraction shows as 52.4 KB (53,746 bytes) depending on how that is resaved as PDF that could become 56.6 KB (58,006 bytes).

On resave the JPEG at 100% of 20% it may thus be recoded in another editor as 34.8 KB (35,711 bytes)!

this seems to be close to your findings.

The problem seems to be at source where that image should have been better quality.

Depending on scanner manufacturer and user choices a similar scan can, as a PDF be between 0.8 KB and 8.0 MB. So the correct choices have drastic effects on size and performance.

If roundtripping is the aim, then a standard high quality JPEG in a PDF will retain exactly the same byte for byte data without degradation.

So any edits are not going to be the source image, but you can replace with better.

Presuming the aim is to trim the edges to 1600 x 2300 then that will be much smaller i.e. under 6 KB when saved as converted to JPX.

/Subtype/Image
/Width 1600/Height 2300
/ColorSpace/DeviceRGB
/BitsPerComponent 8
/Filter/JPXDecode
/Length 5735

here as temporary download is that PDF https://filetransfer.io/data-package/c7fZ73kl#link

NOTE: not all PDF readers may see that JPX image. Legacy SumatraPDF was the builder and my current Chromium (PDFium) Edge v125 does not show the heart, unless switched back to I.E. legacy Acrobat Reader DC Plug-in. However my current "Powered by Acrobat" Edge v128 does.

2
  • I'm not sure I understand everything, but at least the picture gets clearer. How have you been able to figure all that information? For instance, how could you tell how the original jpeg was compressed within the original scan?
    – iago-lito
    Commented 8 hours ago
  • When pdf is compressed zip like (flated) often an image description is not (not always the case). So first look at the file in a Hex editor for the image component and note its description looking in a small file with any suitable editor, l see /Img1 6 0 R thus the image is 6 0 obj and that in turn shows 6 0 obj <</Type /XObject/Subtype /Image/Name /Img1/Filter [/FlateDecode/DCTDecode] /Width 1653/Height 2338/BitsPerComponent 8/ColorSpace /DeviceGray/Length 7 0 R >> which I know /Filter[..] with 2 entries is double encoded thus 1st it was DCT (JPEG) then Flate (ZIP) PDFimage shows jpg!
    – K J
    Commented 8 hours ago

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .