Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#7 Converting JPEG to PDFs eats memory

closed
None
5
2012-01-18
2010-02-12
Seegras
No

I'm not sure if this is the right form to submit this. This is either a bug-report, or a misunderstanding on my part:

$ ls *.jpg | wc -w
482
$ du -s
215828 .
$ gm convert -list Resource
Resource Limits (Q8, 32 bits/pixel, 32bit address)
----------------------------------------------------
Disk: Unlimited (MAGICK_LIMIT_DISK)
Files: 256 (MAGICK_LIMIT_FILES)
Map: 1.9GB (MAGICK_LIMIT_MAP)
Memory: 1.9GB (MAGICK_LIMIT_MEMORY)
Pixels: 819.2MP (MAGICK_LIMIT_PIXELS)
Threads: 2 (OMP_NUM_THREADS)
$ gm convert -compress JPEG *.jpg some.pdf
Insufficient memory (case 4)

I set the MAGICK_TMPDIR to some fs with some 200 GB space left. this it did:
$ du -sh /opt/tmp/
14G /opt/tmp/

WELL.

I can't understand at all why GraphicsMagick even TRIES to unpack the jpeg-files. They can go into the pdf nearly unmodified. So why does it do that?

Discussion

  • Seegras
    Seegras
    2010-02-12

    Actually, there is a command which does what I expected gm to do:

    It's pdfjoin:

    for i in *.jpg; do mv $i $i.pdf; done ; pdfjoin --outfile some.pdf *.pdf

    Apart from the odity that you have to rename your jpegs to pdf, it's fast, and the result is one clean, small, and perfect PDF.

     
  • It is good to know that there was a workaround. GraphicsMagick always decodes its input files before it does anything more. If it did not do that, then it would not be able to support 100 file formats. There is already more than enough complexity without trying to be aware of special short-cuts between formats.

    I am closing this request since GraphicsMagick is not likely to ever support this short-cut (however worth-while).

     
    • assigned_to: nobody --> bfriesen
    • status: open --> closed