The primary reason to extract the images exactly as is, bit-for-bit-identical, is that they’re typically already lossy-compressed (usually JPEG). Recompressing them will introduce further losses or increase the file size¹, or both.

Kudos to Josef Habr for suggesting The Unarchiver on StackExchange – I would never have found it on my own, even though I already had it installed and use it occasionally (for more traditional archive file formats, like Zip or StuffIt).

Frustratingly, Josef’s post aside, none of the recommendations you read online mention The Unarchiver, pointing instead to other options which are harder to install, harder to use, and don’t extract the images correctly. Worst of all, many people falsely claim that their suggested approach will extract the images losslessly. Examples include:

• pdfimages from Poppler – silently re-encodes images in some cases (contrary to what its documentation and users claim), such as if they have non-sRGB colour profiles, and fails to preserve the embedded ICC profile. Worse, the developers have known about this for nearly a decade and refuse to fix it.
• pdftoppm (et al) – explicitly convert the embedded images into another format, which while usually a lossless format (e.g. PNG or PPM) by default, still requires you to then re-encode them for use online etc. Plus, they typically don’t preserve ICC profiles.
• ImageMagick – doesn’t extract the images, merely renders the whole PDF page(s) as images, requiring further post-processing and inevitably reducing the image quality (due to mismatched output resolution and pixel alignment vs the embedded images’).
• Exporting pages as images from Preview or Acrobat Reader – obviously doesn’t preserve the extracted images as-is, requires re-encoding them with additional compression losses, etc.
• Screenshots via Preview or Acrobat Reader – ugh, I can’t even.
• Various websites – I mean, they might work, but why upload your personal data to some skeezy website when it’s easy and fast to just use The Unarchiver locally?

I saw a recommendation for File Juicer, but unfortunately the free trial doesn’t work for me – it claims it’s already expired – so I was unable to check that it actually works. Plus, it’s not free (USD$19 at time of writing) so that’s a strong disincentive compared to The Unarchiver.

1. It is possible, with some newer formats like AVIF, to recompress a JPEG in a way that arguably improves the image quality while also reducing the file size. AVIF encoders typically have some built-in smarts to recognise JPEG artefacts specifically, and try to remove them – a direct benefit visually since the artefacts are ugly and a benefit to [re]compression since the encoder then doesn’t need to waste time & output bits trying to preserve the artefacts.
   
   But, utilising this feature can require more care during compression to find the right trade-offs and ensure the result is in fact as good or better than the original – and in any case, AVIF recompression will work better from the original JPEG than a mangled version. ↩︎

This was a little hack I worked on back in 2004, with Mac OS X Tiger (10.4).  Yes, kids, macOS was called Mac OS X back in ye Olden Times.

Wow, Slashdot looked even uglier than I remember, back then.  Though amusingly my daily reading list hasn’t changed substantially – it still features Slashdot and MacSurfer’s Headline News.

Also… 1024 x 768.  That’s just over 5% of the resolution of my current display (27″ Retina iMac).  It’s nearly as big as my iPhone 6s’s screen.

Man, do I not miss those shitty old monitors.

I don’t recall what the exact impetus was for the project.  I do recall that I was spurred on by Claus Atzenbeck, who was doing some kind of academic work into graphical user interfaces and, IIRC, wanted a way to explore window rotation and general manipulation in a real OS.

Claus’s personal website still exists, all these years later, though alas the link to his relevant research is now broken.

What reminded me of this was finding an attribution to me in a header file that was associated with the project – CoreGraphicsServices.h.  This was something I generated (presumably with the help of class-dump or similar) from the CoreGraphicsServices framework, and then partially reverse-engineered (in the sense of figuring out parameter types, function prerequisites, etc).  It’s what was necessary to find & use the private APIs for doing window geometry manipulation.

And the only reason my name is on it is because I splatted a 3-clause BSD license into the header file I made, which in hindsight seems highly dubious since the APIs themselves are owned by Apple (insofar as one can ‘own’ APIs, I guess…).

A quick web search reveals a few more mentions:

• The aforementioned header is apparently used by Growl.
• “BOMGAR”, some kind of remote computer support software, apparently uses the header too.
• As does something on marsthemes.com, though at time of writing that website has been largely destroyed for some reason.
• This one particularly amuses me – a brief thread on cocoa-dev@ about the header, in which John C. Randolph categorically takes no particular position on the hack. :)

The source & other paraphernalia were originally posted on my La Trobe University student web hosting account, though of course that’s long gone.  Here’s the original StuffIt archive, if you’re interested.  I don’t actually know if it’s the very latest version – I do still have the project in full – but it’s the latest version I ever published, AFAIR.

I leave it as an exercise to the reader on how to decompress StuffIt files in this day and age. :)