#188 Large image resize is extremely inefficient

v1.0_(example)
closed-wont-fix
Algorithms (87)
7
2014-11-18
2012-04-29
B-2Admirer
No

Yesterday I tried to downscale a 43520x47872 image with GraphicsMagick. The command line I used was gm convert -limit pixels 2500MP -filter box -resize 50% DokshitsiCut.tif C:\DokshitsiCut.png.

I expected the conversion to take about an hour at most, but after six hours I was still faced with heavy HDD activity and no end in sight. By that time my patience was entirely spent, so I decided to call it quits, but not before determining what GraphicsMagick was doing, so that I could report it here. Turned out the program created three files in the temporary directory: gm3Vya4M of about 8 GB, gmIgdh9H of about 4 GB and gmURFlG6 of about 2 GB. A look at the Process Monitor revealed that it was writing data to gmURFlG6 by chunks and each chunk had the size of four bytes. That's right, FOUR BYTES.

I, of course, don't know for sure what planet the programmer who wrote the routine does live on, but with the technology we currently have on Earth such operations would probably take days even on an SSD, and on HDD... well, let's say they would take MANY days. No wonder that after so many hours the file mostly consisted of binary zeroes. In comparison, Adobe Photoshop CS5.1 completed the same task in about 17 minutes.

Discussion

  • B-2Admirer

    B-2Admirer - 2012-04-29
    • priority: 5 --> 7
     
  • Bob Friesenhahn

    Bob Friesenhahn - 2012-04-29

    Please try using the -scale algorithm rather than -resize. It works much better for large images. You are correct that -resize does not scale well. In fact -resize is even challenging for RAM-based image storage.

     
  • B-2Admirer

    B-2Admirer - 2012-04-29

    Please give me the exact command line I should use to downscale the DokshitsiCut.tif image to 50%

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2012-04-29

    A sad thing is that on reasonably modern 64-bit hardware running 64-bit Linux and with plenty of RAM the -resize operation takes about 20 seconds. If writing the PNG is included, it takes just under a minute. The operation required a whopping peak of 17GB of RAM.

    So Photoshop on your machine takes 17 minutes but if this task is really important to you, we now know that you can get it to under a minute with sufficiently powerful hardware, a 64-bit GraphicsMagick, and a 64-bit operating system.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2012-04-29

    With this size image, the -scale operation still requires a peak of 12GB of temporary (file/RAM) storage. The big difference between -resize and -scale is the patterns it uses while it accesses the image, and that -resizes uses two passes rather than one.

     
  • B-2Admirer

    B-2Admirer - 2012-04-29

    Do you really see anything even remotely useful about your last two comments? My report is about resizing images that don't fit into RAM. I fail to see what your rants about "reasonably modern 64-bit hardware running 64-bit
    Linux and with plenty of RAM" got to do with this.

    If I had a machine with enough memory to fit such an image, I would most certainly wouldn't bother myself with a badly documented and largely unknown CLI tool like GM, but just use a general purpose image viewer/editor like XnView, isn't that intuitively obvious?

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2012-05-01

    Sorry to see that you are in such a bad mood and not happy with the free software you found. As I suggested, give -scale a try. On a lowly Windows XP PC with a Core2 CPU and slow disk drive, it seems to take about 4 minutes to resize the image to 50% using -scale (roughly similar to time to load or save the image to TIFF). Using -sample takes about the same but there may be more artifacts. The disk is still the bottleneck.

    gm convert -limit pixels 2500MP DokshitsiCut.tif -sample 50% DokshitsiCut.png

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2012-05-01

    Actually, that should have been

    gm convert -limit pixels 2500MP DokshitsiCut.tif -scale 50% DokshitsiCut.png

     
  • B-2Admirer

    B-2Admirer - 2012-05-01

    It's not about my mood, I just don't like when people evade the question by talking off topic.

    Thanks for the command line given, but I have a question. Which algorithm will be used to resize an image when -scale 50% is specified? If it's nearest-neighbor, then that's not what I need. I need Bilinear for that image.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2013-10-19

    The pathetically slow resize once disk files are used is a fundamental property of the -resize operation because it performs random access. The workaround is to use -scale or -sample and (perhaps -sample followed by -scale) before a final -resize so that -resize can be done entirely in memory. Another option is to use -thumbnail which does this automatically.

    Since the algorithm is not fixable, I am going to close this in the "won't fix" category.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2013-10-19
    • status: open --> closed-wont-fix
    • Group: --> v1.0_(example)
     
  • B-2Admirer

    B-2Admirer - 2014-11-18

    What a shitheaded timewaster you are. I wonder why you even have bug reporting here. Once again, fuck you very much for your "help".

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks