Hi chrysn,
Quoting chrysn (2014-03-19 08:56:22)
> it is my impression that imagemagick's convert program can do exactly that
> (judging from converting differently compressed jpgs through `convert a.jpg
> a.pdf` and looking at the file sizes, and comparing an image with what comes
> out after roundtripping through convert and `pdfimages -j` -- were the dct
> not preserved, it could hardly not grow significantly and yet yield the
> exactly same image).
I can not reproduce your findings. Here is what I did:
$ convert img.jpg img.pdf
$ pdfimages img.pdf img.extr # not using -j to be extra sure there is
no recompression
$ compare -metric AE img.jpg img.extr-000.ppm null:
1.6301e+06
This means that 1.6301e+06 pixels are different. Is my method faulty? Can you
reproduce above findings?
> you cite convert for comparison[1], but only use Zip compression as convert
> option. had i not used imagemagick for this purpose for quite some time, i'd
> suggest you re-evaluate with the latest version of convert. what behavior do
> you get when not using any convert options?
See my test above. I'm using version 8:6.7.7.10+dfsg-1
After I found that imagemagick would always change the embedded jpeg I tried
using the -compress Zip option because that would obviously be lossless (but
result in a much larger file size). This is why it is listed in the README.
Maybe I should list above steps as well.
Thanks a lot for your feedback :)
cheers, josch
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
