Compressed picture speed

[AdmireWhite]

It takes me 5 seconds to compress a 3M image quality set to 0.2F zoom in 1f, is this speed normal?

[coobird]

Without a code snippet, it's a bit difficult to understand how you're using Thumbnailator, but I'm going to assume you're using .scale(1f) and outputQuality(0.2f). Without a image format, I'm just going to assume JPEG.

Since I don't have enough information about you're using Thumbnailator (like image format, image dimensions, etc.), I cannot give Thumbnailator-specific tips, but as a general tip on what affects image compression speeds, here are a few:

• Source image size -- the larger it is, the longer it will take.
• Output image quality settings -- this can depend on the codec (output format)
• Output format itself -- JPEG tends to be a bit faster to compress than PNG
• CPU -- slow CPUs can take longer to compress
• memory -- not enough memory may be leading to disk swapping causing longer processing times.

Other Java-specific possibilities are, running the program with an insufficient heap size can lead to more garbage collection which can cause longer processing times -- this can be a common problem on Java in general.

Bottom line is, without a bit more information about the source image and the execution environment, it's hard to track down what may be the issue.

[AdmireWhite]

code: Thumbnails.of(file).scale(1f).outputQuality(0.2f).toFile(file);

[AdmireWhite]

Hello, I have tried many pictures, but the speed is quite slow, which does not meet my expectation. I would like to ask, have you made statistics on the speed of compression? What would the result look like？

[coobird]

You've yet to mention information about your source files. It's hard to give more specific advice without that information. Everything depends on the conditions on which the software is running in.

Note that Thumbnailator is just a wrapper around Java's Graphics2D and Image I/O facilities. The compression speeds completely depend on the Image I/O codecs used which Thumbnailator has no control over.

Also note, the point of Thumbnailator is to create thumbnails, which you're not doing by using scale(1f) -- if you need a generic image conversion tool, you'll probably be better off to just use the ImageIO.read and ImageIO.write facilities directly -- that said, as mentioned in the previous paragraph, if the compression speeds are truly the issue, you'll experience similar problems.

[coobird]

By the way, have you checked the garbage collection activity on your program? Slow Java programs can be a result of large amount of GC, which can be a result of a insufficient heap. The worst case memory usage under .scale(1f) is like this:

sourceImageSize + destinationImageSize + temporaryImageSize

where each image size is calculated by 4 * imageWidth * imageHeight bytes. For a typical 10 megapixel image (3648 x 2736), the single image requires approximately 40 MB of memory, just for that raw image, not counting any other heap allocations. Then, that number is multiplied by 3 for the worst case using Thumbnailator under .scale(1f), so at least a 120 MB heap is required for that single image resize. (Edit: Looking at the code, it seems like this case would be 2x, so 80MB.)

Therefore, to really know what your speed issues are, you'll need to check what your JVM heap parameters are, along with what kind of source images you're working with.

[coobird]

Closing for inactivity.