Problem with Group 4 compression on B&W TIFF

[UDTP]

Greetings.

I'm running ImageMagick 7.0.8-49 portable Q16 x64 on Windows 10. I'm trying to apply Group4 compression to a folder full of bi-level (1bit) TIFF images using the command "convert -compress Group4 [input file] [output file]" When I run it, file size increases anywhere between 200-300%. So I go from an image that's 3621KB to one that's 9501KB. I've tried various options (-monochrome, -type bilevel, -depth 1, etc.) in various orders but nothing seems to make a difference. The compressed files are always much larger than the original.

I should add that these images are converted from 24bit color images to bi-level in Photoshop. I use IM as Photoshop does not offer group 4 compression and I need to use it to comply with a standard I do not control.

Here's a link to an example image
https://drive.google.com/file/d/13r_xbj ... sp=sharing

Thanks in advance for the help.

[fmw42]

Proper IM syntax would be to read the image first. Though that may not make a difference in some cases.

ImageMagick see your image as uncompresses with

Filesize: 3706920B

So 3.7 MB


I ran

Code: Select all

convert 00000004.tif -compress group4 x.tif

On my Mac OSX Sierra using IM 6.9.10.49 Q16 with LIBTIFF, Version 4.0.10

The result was

Filesize: 9.27754MiB

Converting 9.3*1.024 = 9.5 MB

So indeed the size increases. But I am not an expert on TIFF compressions to know if this is expected.

The main issue that I have is that your TIFF does not look like it is bilevel. It views as shades of gray and not just black/white. The meta data does say bilevel, however. If I zoom in, it is made of black dots on white background. So it looks dithered in some way. I am not sure how that affects group4 compression.

[UDTP]

The image was upsampled (400->600 DPI) prior to the conversion from color to B&W using photoshop's default bicubic interpolation. But no changes are made to the image after conversion to B&W other than my attempt to apply compression.

I've never run into this issue before despite having worked with similarly processed files. I've read somewhere that there can be issues with images that go through this sort of workflow but that it typically means a lower compression ratio. I've seen that with some images in the past. But this sort of size increase is really something else. I wasn't sure if there was something about the image that might lead to this sort of issue as I am also not really well versed in the intricacies of compression. I appreciate your feedback though. I will give it a shot with an image that hasn't been upsampled and see if that makes a difference.

[fmw42]

If you upsample with bicubic, it will interpolate new colors. So how is it that it is labeled as bilevel?

[246246]

I'm not sure it is the case but Group4 compression may produce larger size file than the original at the worst case.

From https://en.wikipedia.org/wiki/Group_4_compression

A worst-case image would be an alternating pattern of single-pixel black and white dots offset by one pixel on even/odd lines. G4 compression would actually increase the file size on this type of image.

[UDTP]

The color image is upsampled with bicubic and then converted to bi-level. The example image I posted is a bi-level image and one of the files I am trying to apply the compression to.

The worst case described in the wiki article is, I think, a checkerboard pattern. I can see that as an issue with some images but in this case 100+ images are all affected by this issue. Most of them are images of text, supposedly one of the things Group 4 compression is optimized for. But I'm still seeing file size increase 200-300% on those images after compression.

Thank you both for your feedback.

[snibgo]

For the linked image, "-compress Zip" gives a smaller filesize than the input (uncompressed) or Group4.

For any compression method, there will generally be some images for which the "compression" increases the file size. That's life.

[UDTP]

I'm forced to use group4 compression in order to meet standards over which I have no control. If I had my way these would be served up as low quality JPEG's since the only thing of matter in them is the content. But I'm not the one making the rules and that is life; I'm doing what I'm told not necessarily what I want.

I understand that there are sometime images that causes issues. The problem is that I am seeing this issue with 100+ images all from the same volume/batch. It shouldn't, and hasn't in my experience with about 400K images I've processed in this fashion, be so consistently an issue. I'd like to determine if it is Imagemagick or some aspect of the files that's causing it. I don't know the fine detail of compression or Imagemagick, which my use of is largely limited to this operation. Hence my posting.

[snibgo]

I should add that these images are converted from 24bit color images to bi-level in Photoshop.

From your sample, it seems that the Photoshop conversion has included dithering. If you have a choice, I suggest you try it without dithering. (Dithering reduces the accuracy of individual pixels, and mid-grey leads to chequer-board patterns.)

[fmw42]

Your image does have nearly alternating black and white pixels. Zoom in and you will see that. So the comment about group4 having larger compressions sizes for that situation makes sense for your image.

Try reprocessing without dithering.

[snibgo]

A comparison of Group4, with and without dithering:

Code: Select all

magick xc:White xc:Black +append -write mpr:BW +delete toes.png -remap mpr:BW -compress Group4 x.tiff

magick xc:White xc:Black +append -write mpr:BW +delete toes.png +dither -remap mpr:BW -compress Group4 x2.tiff

Filesizes:

Code: Select all

13/06/2019  19:19            20,142 x.tiff
13/06/2019  19:19             1,432 x2.tiff