Community
Participate
Working Groups
Tested using http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/snippits/snippet112.html (changed to load a file instead of a red square) I was able to display jpg and png images fine, but not group 4 tiff files. I get only a solid white image. I converted it to group 3 using tiffcp, and it displayed correctly. Here is the output of tiffinfo on the file, in case it might help. (I would attach the file, but it contains confidential patient info) TIFF Directory at offset 0x8 Subfile Type: (0 = 0x0) Image Width: 1984 Image Length: 2150 Resolution: 200, 200 pixels/inch Bits/Sample: 1 Compression Scheme: CCITT Group 4 Photometric Interpretation: min-is-white Thresholding: bilevel art scan Date & Time: "2002:11:10 23:42:19" Software: "Kofax standard Multi-Page TIFF Storage Filter v2.01.000" Orientation: row 0 top, col 0 lhs Samples/Pixel: 1 Rows/Strip: 2150 Planar Configuration: single image plane
Hi, The TIFF decoder supports the following spec: Baseline TIFF decoder revision 6.0 + Extension T4-encoding CCITT T.4 1D Can you attach a TIFF file format constructed as the one that fails without the copyright problem? From the output, it is not clear if your encoding is CCITT T.4 2D - unsupported - or not).
Created attachment 9214 [details] Example image
Yes, the attached file contains a compression field with a value of 4 (Group IV T6 encoding CCITT T.6 bilevel encoding). This encoding is not part of the baseline TIFF decoder and is not supported by the SWT TIFF decoder. As you've previously mentionned, the extension Group III (specifically, T4- encoding CCITT T.4 1D - not the 2D variant) is supported.
Ah, I see. That's unfortunate. Are there plans to support this format? Also, if it's unsupported, it should probably throw an exception right?
I too would like to see additional TIFF compression schemes supported. SWT can not be used to manipulate the black-and-white check images our company receives from a bank because as they are the group 4 2-d variant. We also have TIFF images using lempel-ziv (LZW) compression to show grey-scale (stamps and franking are often lost with bi-level compression). These tiff files open as solid black images, no error is thrown.
Created attachment 10355 [details] A TIFF file which shows blank when loaded We did not assure whether this is group 4 TIFF, but it shows very well in Windows Painter under TIFF mode, as well as in other image applications. Thanks.
Do you plan to support the tiff group 4 2D variant in the 3.1 release?
We would also like to ask whether CCITT Group 4 compressed TIFFs will be supported in 3.1? We've build a RCP based Payments Processing application which is feed by images from an OPEX scanner. The original images produced by this scanner were .tif files with CCITT Group 4 compression which we were unable to display in our RCP framework.
Sorry no - there is no extra TIFF support committed for 3.1. If you have an implementation that supports these extensions and wish to contribute it please let us know.
Created attachment 30351 [details] TIF image loads as blank. ImageData.data all zeroes When I loaded this image it showed as a black rectangle. The Image has three colours. A white background and a black/red logo. The ImageData fot the TIFFileFormat gives a full set of zeroes in the data.
For info, I retested the images that are attached in comment 2, comment 6, and comment 10. As expected, the stream image constructor, Image(device, stream) still does not load these images correctly, but the file image constructor, Image(device, filename_string) that was recently rewritten to use native code, does read these images correctly. If you were already using that constructor, your code will just work now. If you were loading from a stream, or loading directly into ImageData, then as a work-around, if possible, you can now use Image image = new Image(display, "filename.tiff"); to load your images into SWT. So to summarize: this bug still exists, but there is a good work-around.
Is this fixed in SWT 3.2 release or in 3.3 M1? And could you explain if the Image(device, stream)-bug will fixed in 3.3 release?
>Is this fixed in SWT 3.2 release or in 3.3 M1? This bug (57382) is not fixed in either place. The Image(device, filename_string) bug is fixed in both 3.2 and 3.3. >And could you explain if the Image(device, stream)-bug will fixed in 3.3 >release? Maybe - not sure. I am not currently working on it because many other things have higher priority.
On June 20, 2003, UNISYS patent on the LZW algorithm expired(*). Will LZW_COMPRESSION be added into TIFFDirectory? * http://www.unisys.com/about__unisys/lzw
Please feel free to submit a patch, and I will look at it. I do not have time in my schedule to implement it myself in the 3.3 time frame. Please also be sure to read comment 11 which says that if you use Image myTiffImage = new Image(device, "filename_string.tif"); to load your image, then SWT uses native code, which *does* read these images correctly. If you really must use the stream Image constructor, then someone will need to provide a patch to the org.eclipse.swt.internal.image.TIFF* classes to make this work. Otherwise, this will not be done for 3.3.
Ok right, but the Image myTiffImage = new Image(device, "filename_string.tif"); use a native call to load the Image. Why is this not possible to use with new Image(device, InputStream)?
Because the native call does not know what a Java stream is.
Carolyn, thank you for posting the work around!
(In reply to comment #11) The work around provided has one serious limitation for us: Memory. We deal with TIFF images that are 75,000 by 10,000 pixels, depth = 1. We send hundreds of these modest sized (at least to us) images to our clients. In the old days we would have sent hundreds of paper plot that were 20 feet long by 36 inches wide. Each image represents a seismic section. A tiny and very incomplete example is shown here: http://gaia.earthsciences.dal.ca/style/SaltTect3.jpg The work around returns the TIFF as an Image. On linux GTK the Image.init() fails at int /*long*/ pixbuf = OS.gdk_pixbuf_new(OS.GDK_COLORSPACE_RGB, false, 8, width, height); If ImageData would use the native code it would solve our problem.
Created attachment 93710 [details] Patch for tif lzw decompression Attached is a patch for org.eclipse.swt.internal.image to support reading lzw compressed tiff images. It uses a slightly modifed class from the Apache Batik project.
Unfortunately the file image constructor is not always an adequate replacement for the stream image constructor. For example, I use the stream image contructor (or to be precise, the imageloader with a stream) to read images directly from zip archives. Because supporting all kinds of images directly seems to me like a lot of work (and second, my attached patch for lzw decompression e.g., is two times slower than the native call) I would like to see a bridge to a native call using a java stream (if this is even possible) or a good integration of java image i/o.
Created attachment 164213 [details] This tiff file loads all back ... Here is a sample from an HP scanner that loads as all black
Any news about this bug? I can work in Window using ActiveX plugin (Imaging Professional) but not in Linux.. So it would be nice to have BW encoder - decoder and multipage support in TIFF format. Thank you in advance, D.
*** This bug has been marked as a duplicate of bug 545032 ***
