GNOME Bugzilla – Bug 301557
Saving of grayscale TIFF fails ("Bits/sample must be 1 for Group 3/4 encoding/decoding")
Last modified: 2008-01-15 12:52:42 UTC
Please describe the problem: When saving a postprocessed black&white image, saving as TIFF fails with the message "Bits/sample must be 1 for Group 3/4 encoding/decoding". I had selected "No compression" in the TIFF options dialog, and GIMP's window title suggests the image is a "Grayscale" image. Indeed, I cannot convert the image to grayscale (it's grayed-out). However the original image when loaded could have been FAX Group 4 compressed... Steps to reproduce: 1. Try to save a grayscale image as uncompressed TIFF Actual results: Bits/sample must be 1 for Group 3/4 encoding/decoding Failed a scanline write on row 0 Expected results: A TIFF file should be created Does this happen every time? Yes (for the same image) Other information: Original TIFF image had been created by a printer/scanner.
I've found a solution also: In the TIFF options, select a different radio-button rather than "no compression". The select the "no compression" button again. Then save suceeds. Is it an uninitialized variable?
I can't reproduce this with GIMP 2.2.6, neither with a grayscale image nor an indexed (black and white) image.
Created attachment 45539 [details] Test-Image (TIFF) to show the effect Especially for you I've created a test image. Please do the following: Open the image Crop to the text Rotate the text a bit (straight) Crop away transparent borders Save as .. TIFF with default "no compression" enabled. ... BTW: There is an 8-byte TIFF created then. Hexdump: 0000000 4949 002a 0000 0000
This image is not grayscale but indexed. At least the CVS version (HEAD) of gimp seems to handle this image correctly. One should however note that CVS HEAD has but #150865 fixed.
bug #150865, of course
Reply to comment #4: I just checked: In the windows title my GIMP still says the image is "grayscale", and only after I convert it to indexed, the windows title actually says "indexed". So GIMP gets the image type wrong somehow. Still it does not answer why the TIFF plugin tries compression when the radio button is on "compression: none". Seems there are multiple bugs involved.
You're obviously not running CVS HEAD then. The tiff plugin in 2.2.x does not load black and white images as indexed images.
Fixed in both branches. Note that simply opening and saving the sample tiff is enough to trigger it. 2005-04-25 Manish Singh <yosh@gimp.org> * plug-in/common/tiff.c: Only store compression types we can actually handle in the save options parasite. Fixes bug #301557.
So not accepting unsupported-in-GIMP compression methods any more also fixes the bug that an unsupported-in-GIMP compression mode was displayed as "none", while internally it was different from "none" (the subject of this bug report)?
The default UI preference is seeded from the parasite value. Since the value didn't correlate with any GUI option, the GUI reflected "none", but the internal value was still being used upon actual save.