Legacy ImageMagick Discussions Archive

Dear all =)

When having two or more jpg images that looks like to be the same, but with different sizes, it it temping to think that the biggest is the one with the fewest compression artifacts, but I can find cases where that is not the case, when zooming in.

Is there a way to measure with a command line program the "amount of artifacts" or "quality" of jpg images?

Ideally I would like to also run this on my png's as well to see if any of them have been jpg's at one point.

Hugs,
Jasmine =)

jasmine wrote:Is there a way to measure with a command line program the "amount of artifacts" or "quality" of jpg images?

Interesting question.

If you have an uncompressed source, and two jpegs made from that source, we can find which jpeg is closest to the source eg by comparing RMSE.

When we have JPEGs with no source, extreme processing will often reveal compression artifacts. For example Maximise local contrast. That result has clearly been fragmented into blocks of 8x8 pixels. Where the input was smooth skin, each block has a horizontal pattern (ie each column within the block is similar to other columns within the block), but is different to adjacent blocks. Sometimes the blocks are 16x16 pixels.

This suggests we can analyse an image to detect and measure JPEG artifacts, and compare two JPEGs for "badness", and test other images for the presence of artifacts. But I haven't investigated this.

snibgo wrote: ↑2018-07-16T05:22:42-07:00 This suggests we can analyse an image to detect and measure JPEG artifacts, and compare two JPEGs for "badness", and test other images for the presence of artifacts. But I haven't investigated this.

Somehow, I feel this problem should have come up before - esp. with new lossy formats on the rise it's certainly important to automatically determine if a source was (jpeg)lossy before, or it's safe to compress with another method.

Currently, a lot of sites convert to webp with cms plugins that re-compress everything by relying on Google's say-so that webp is smaller and better (disclaimer: I really like webp's lossless mode, and it has lossy with alpha).

I discovered this problem in extreme cases with webp, when either lossless (with pre-processing) or lossy with q100 actually resulted in a bigger file than the source png. It was a case of extreme blockyness - but it demonstrates other codecs can be very bad at converting jpeg compression.

Ideally, a codec like cwebp should generate a warning "This image has jpeg compression artifacts, do you really want to re-compress (y/n)?"