After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 150865 - Images with a black and white 1-bit indexed palette should be saved as 1-bit grayscale tiffs
Images with a black and white 1-bit indexed palette should be saved as 1-bit ...
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Plugins
2.0.x
Other Linux
: Normal enhancement
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks: 162119
 
 
Reported: 2004-08-23 17:48 UTC by Peter S. Conrad
Modified: 2005-06-09 16:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Here are some files I created in the GIMP to test the bug. (30.00 KB, application/x-tar)
2004-08-23 20:13 UTC, Peter S. Conrad
  Details
Save two color indexed black & white images as 1-bit (4.65 KB, patch)
2004-08-24 16:31 UTC, Manish Singh
none Details | Review

Description Peter S. Conrad 2004-08-23 17:48:55 UTC
TIFF files saved with 1-bit depth are actually larger than grayscale images. 
For example, I saved a 72 dpi x 1 inch x 1 inch image in the following formats:
Grayscale, no compression: 5.4K
BW, no compression: 6.9K
Grayscale, Pack Bits: 1.4K
BW, Pack Bits: 2.2K
I'm a cartoonist, and I send my cartoons electronically to newspapers for 
publication. In my ancient PhotoShop LE (Mac) a 10 inch by 3.3 inch by 600 DPI 
comic strip saved as 1-bit TIFF is 1.4 MB. On the GIMP, if I convert to 1-bit 
and save as TIFF with no compression, it's 200-something MB; if I Pack Bits, it 
is 500-something MB! Saved as grayscale it is 12 MB. GIMP should be able to 
save 1-bit TIFF in a 1.4 MB file.
Comment 1 weskaggs 2004-08-23 19:08:58 UTC
I haven't been able to reproduce this phenomenon.  Could you please attach the
72x72 grayscale image to this bug report?  I assume you converted to BW by using
Image->Mode->Indexed and then selecting "Use black and white palette".  If not,
could you clarify what you did?

Finally, GIMP depends on a library called libtiff to write TIFF files, and
differences in that library could theoretically explain the results.  Could you
specify what Linux distro you are using, and if possible what version of libtiff?
Comment 2 Peter S. Conrad 2004-08-23 20:13:36 UTC
Created attachment 30872 [details]
Here are some files I created in the GIMP to test the bug.

The filenames reflect the bit depth and method of saving.
Comment 3 Peter S. Conrad 2004-08-23 20:20:18 UTC
>I assume you converted to BW by using
>Image->Mode->Indexed and then selecting "Use black and white palette".

Yes. Actually, I also tried creating a 2-color palette in the palette editor as
well, just to see if it would behave differently. But the results seem similar.
I'm running Fedora Core 2. Where is libtiff? 

By the way, I was able to take the grayscale TIFF into PhotoShop LE on a Mac and
modify it. So at least it's writing something that another TIFF-savvy app can
understand. But it's making really large files when I do Image > Mode > Indexed
> Use black and white palette and then save as TIFF with Pack Bits. If you like,
you can download www.peterconrad.com/shh/D0823.tif to see what I mean. This
image is correctly saved (by PhotoShop LE) as about 1.4 MB give or take, 1-bit
depth. If I were to put it in the GIMP and then Save As (after making sure to
use a black and white palette) it would be hundreds of MB. 
Comment 4 Peter S. Conrad 2004-08-23 20:56:34 UTC
My libtiff version is:

libtiff-3.5.7-16.1
Comment 5 Manish Singh 2004-08-23 22:10:33 UTC
What's going on here is that gimp's tiff save plugin always saves out indexed
images as with 8 bits per sample, where each sample represents an index into a
palette (gimp's internal representation), whereas the tiff you provided that
photoshop made saves it out as grayscale, with 1 bit per sample. Hence the 8-bit
grayscale image being 8 times the size of the 1-bit grayscale image.

The tiff plugin could be made smarter about this, and detect a black and white
palette and craft scanlines that represent the right thing.

Note that taking D0823.tif, loading it in gimp, and saving it out as grayscale
with lzw or packbits, results in filesizes well under a megabyte. As a
workaround, you could try converting to 1-bit b/w indexed in gimp, then back to
grayscale, and then save with compression.
Comment 6 Peter S. Conrad 2004-08-23 22:46:23 UTC
True. The problem is that publishers need me to send black and white that's
really black and white, and they don't want to have to manually open and process
the file on their end. So, for sending the files to newspapers, the workaround
doesn't really work-- even though it looks truly "black and white" onscreen, or
if I laser-print it. 
Comment 7 Manish Singh 2004-08-23 23:02:22 UTC
I don't follow. Indexing to two colors would mean it's really black and white,
converting it back to grayscale after that will preserve that.. it won't
magically add other shades of gray.
Comment 8 Peter S. Conrad 2004-08-24 00:30:52 UTC
True enough, but it's treated differently by the software at the print shop.

Grayscale graphics are treated as photos, with the darkest value being somewhere
in the 90-97% range. Black and white graphics are treated as pure black ink. So,
even though the file contains only black and white pixels, unless the printer
manually changes the file mode, the blacks come out as a dense halftone. Even if
that were not the case, the halftone kind of "resamples" the image, resulting in
fuzzy, halftoned edges to every black area.
Comment 9 Manish Singh 2004-08-24 00:49:05 UTC
But the file you gave that photoshop made *is* a grayscale image. There are only
differences in the tiff format metadata: the bw image has bits/sample == 1, and
the grayscale has bits/sample == 8 and the bw image specs that a 0 value is
white, while gimp specs a 0 value is black. I doubt the latter makes a
difference, does the print shop really make a distinction on the bits/sample value?
Comment 10 Peter S. Conrad 2004-08-24 01:23:49 UTC
Yes, because everyone uses PhotoShop, which draws a distinction between
grayscale and "line art" files. 0x00 is always black, and 0xFF is always white,
but the presence or lack of intermediate values determines how the black and
white values are treated by the printer-- in a photo, you almost NEVER want pure
black ink, and in line art you almost ALWAYS do.

What you're saying is absolutely correct, from the machine's point of view.
There's an abstract symbology built on top of that to help the printer decide
how to burn film from a file (whether to apply a halftone). And I've seen what
happens when you send a black and white image to the printer and they say "oh,
this one's grayscale." Even though there are only 0x00 and 0xFF in the file, you
get a halftone.

I'll try to find (and scan) an example-- I know there was one on the COVER of
the newsletter for the Graphic Artists Guild, if you can believe that. But I
think I threw it out a few weeks ago.
Comment 11 Manish Singh 2004-08-24 01:26:01 UTC
So photoshop actually has a "line art" image mode?
Comment 12 Peter S. Conrad 2004-08-24 05:46:08 UTC
Well, it's called (confusingly enough) "Bitmap." Now, you and I realize that EVERYTHING you edit in 
PhotoShop is a bitmap. But in PhotoShop, "Bitmap" means 1 bit per pixel. Grayscale means 8 bits 
per pixel, with a grayscale palette. Indexed means 8 bits per pixel with a color palette. RGB and 
CMYK are 24 and 32 bits per pixel, respectively.
Comment 13 Michael Schumacher 2004-08-24 06:53:23 UTC
A possible workaround would be to use convert from ImageMagick (or mogrify to
convert a whole dir of files):

convert -colors 2 file.tif file-bw.tif
Comment 14 Manish Singh 2004-08-24 14:39:32 UTC
Yeah, imagemagick does the right thing here.
Comment 15 Peter S. Conrad 2004-08-24 16:10:16 UTC
Hmmm... I'll look into that. Thanks!
Comment 16 Manish Singh 2004-08-24 16:31:10 UTC
Created attachment 30901 [details] [review]
Save two color indexed black & white images as 1-bit

Also, you could try this simple patch to the tiff plugin. This makes the tiff
save with very very similar metadata as photoshop does. This includes
normalizing to min-is-white, which results in a very small efficiency loss with
the default b&w palette gimp generates.
Comment 17 Sven Neumann 2004-11-30 13:06:27 UTC
Should this patch be applied to the TIFF plug-in or is it just here for
educational purposes?
Comment 18 Manish Singh 2004-11-30 19:08:58 UTC
There needs to be code in the loader side to detect a 1-bit image and make an
indexed image out of it. Otherwise, a load/save won't roundtrip correctly. So
the patch is incomplete as it stands.
Comment 19 Manish Singh 2005-01-01 19:13:51 UTC
2005-01-02  Manish Singh  <yosh@gimp.org>

        * plug-ins/common/tiff.c: Special case 1-bit black & white indexed
        images to save out as 1-bit grayscale MINISWHITE tiffs. Also load
        these images as indexed images into GIMP. Fixes bug #150865.
Comment 20 Sven Neumann 2005-06-09 16:42:31 UTC
*** Bug 307010 has been marked as a duplicate of this bug. ***