OpenSlide Only Recognizing Topmost Layer

Tue Jun 10 16:36:05 EDT 2014

Hi Timothy, See highlighted differences from tiffinfo below - in particular the Subfile Type and the following OpenSlide issue: https://github.com/openslide/openslide/issues/66

The SubfileType is a baseline TIFF tag, so you *should* be able to set it on your convert object.

Regards,
- Carl

ImageMagickResult.tif:
TIFF Directory at offset 0x898464 (9012324)
  Subfile Type: reduced-resolution image (1 = 0x1)
  Image Width: 33 Image Length: 44
  Tile Width: 256 Tile Length: 256
  Resolution: 0.140625, 0.140625 pixels/inch
  Bits/Sample: 8
  Compression Scheme: JPEG
  Photometric Interpretation: min-is-black
  FillOrder: msb-to-lsb
  YCbCr Subsampling: 2, 2
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 256
  Planar Configuration: single image plane
  Page Number: 9-10
  DocumentName: ImageMagickResult.tif
  White Point: 0.3127-0.329
  PrimaryChromaticities: 0.640000,0.330000,0.300000,0.600000,0.150000,0.060000
  JPEG Tables: (289 bytes)

JavaResult.tif:
TIFF Directory at offset 0x892316 (8987414)
  Subfile Type: multi-page document (2 = 0x2)
  Image Width: 33 Image Length: 44
  Tile Width: 256 Tile Length: 256
  Bits/Sample: 8
  Sample Format: unsigned integer
  Compression Scheme: JPEG
  Photometric Interpretation: min-is-black
  YCbCr Subsampling: 2, 2
  Samples/Pixel: 1
  Planar Configuration: single image plane
  Page Number: 9-10
  DocumentName: C:\Users\thk\Desktop\Result2.tif
  Software: GraphicsMagick 1.3.19 2013-12-31 Q16 http://www.GraphicsMagick.org/
  JPEG Tables: (289 bytes)

--
Carl Cornwell
Contractor
Lister Hill National Center For
   Biomedical Communications
National Library of Medicine
8600 Rockville Pike
Bldg. 38A, Room 10S1015D
Bethesda, MD 20894
Voice (301) 435-5187
________________________________
From: Kim, Timothy H. [timothy.h.kim at nist.gov]
Sent: Tuesday, June 10, 2014 3:19 PM
To: openslide-users at lists.andrew.cmu.edu
Cc: Blattner, Timothy J.
Subject: OpenSlide Only Recognizing Topmost Layer

Hi,

I am currently working on a Java project that uses the OpenSlide library to visualize large tiled pyramidal TIFF files. However, the image files that we are currently working with are single-layered full resolution TIFF images, which is not a compatible format with OpenSlide.

We are able to successfully convert these single-layered TIFF images into tiled pyramidal TIFF images that are compatible with OpenSlide by using ImageMagick’s “convert” command line tool.
i.e.)

                    convert image.tif -define tiff:tile-geometry=256x256 -compress jpeg 'ptif:newimage.tif'
After using this command to convert our single layerd TIFF into a pyramidal TIFF, OpenSlide works perfectly with the resulting image.

A problem arises because we wish to have everything implemented in Java without having to explicitly use the command line to convert these images into tiled pyramidal TIFFs. ImageMagick has a Java API called Im4java that acts as a Java interface to the ImageMagick command-line. Theoretically, running a convert operation through im4Java should mimic the “convert” command line utility of ImageMagick. Unfortunately this is not the case.

Here is the sample code from the project that converts an image to a tiled pyramidal tiff using the im4java library:
                     IMOperation convert = new IMOperation();
                     ConvertCmd cmd = new ConvertCmd(true);
                     convert.addImage(tempFile.getAbsolutePath());
                     convert.define("tiff:tile-geometry=256x256");
                     convert.define("tiff:rows-per-strip=16");
                     convert.compress("jpeg");
                     convert.addImage("'ptif:"+result.getAbsolutePath()+"'");
                     cmd.run(convert);

When we convert an image into a pyramidal TIFF using the im4java API, OpenSlide only recognizes the full-resolution layer of the image (Layer 0). OpenSlide can still open and visualize the image, but it is very laggy when scrolling and zooming because the pyramid functionality is lost. But if we use ImageMagick’s “identify” tool, it reveals that other layers do exist within the image:

$ identify JavaResult.tif
JavaResult.tif[0] TIFF 17314x22842 17314x22842+0+0 8-bit Grayscale DirectClass 8.988MB 0.000u 0:00.002
JavaResult.tif[1] TIFF 8657x11421 8657x11421+0+0 8-bit Grayscale DirectClass 8.988MB 0.000u 0:00.006
JavaResult.tif[2] TIFF 4328x5710 4328x5710+0+0 8-bit Grayscale DirectClass 8.988MB 0.000u 0:00.006
JavaResult.tif[3] TIFF 2164x2855 2164x2855+0+0 8-bit Grayscale DirectClass 8.988MB 0.000u 0:00.006
JavaResult.tif[4] TIFF 1082x1427 1082x1427+0+0 8-bit Grayscale DirectClass 8.988MB 0.000u 0:00.007
JavaResult.tif[5] TIFF 541x713 541x713+0+0 8-bit Grayscale DirectClass 8.988MB 0.000u 0:00.007
JavaResult.tif[6] TIFF 270x356 270x356+0+0 8-bit Grayscale DirectClass 8.988MB 0.000u 0:00.007
JavaResult.tif[7] TIFF 135x178 135x178+0+0 8-bit Grayscale DirectClass 8.988MB 0.000u 0:00.007
JavaResult.tif[8] TIFF 67x89 67x89+0+0 8-bit Grayscale DirectClass 8.988MB 0.000u 0:00.007
JavaResult.tif[9] TIFF 33x44 33x44+0+0 8-bit Grayscale DirectClass 8.988MB 0.000u 0:00.007

*JavaResult.tif is the image created using im4java’s convert operation through java

As you can see, the layers that are created are very similar to the layers created in the image converted through ImageMagick’s “convert” command line utility:

$ identify ImageMagickResult.tif
ImageMagickResult.tif[0] TIFF 17314x22842 17314x22842+0+0 8-bit Grayscale DirectClass 9.013MB 0.000u 0:00.003
ImageMagickResult.tif[1] TIFF 8657x11421 8657x11421+0+0 8-bit Grayscale DirectClass 9.013MB 0.000u 0:00.003
ImageMagickResult.tif[2] TIFF 4328x5710 4328x5710+0+0 8-bit Grayscale DirectClass 9.013MB 0.000u 0:00.003
ImageMagickResult.tif[3] TIFF 2164x2855 2164x2855+0+0 8-bit Grayscale DirectClass 9.013MB 0.000u 0:00.004
ImageMagickResult.tif[4] TIFF 1082x1427 1082x1427+0+0 8-bit Grayscale DirectClass 9.013MB 0.000u 0:00.004
ImageMagickResult.tif[5] TIFF 541x713 541x713+0+0 8-bit Grayscale DirectClass 9.013MB 0.000u 0:00.004
ImageMagickResult.tif[6] TIFF 270x356 270x356+0+0 8-bit Grayscale DirectClass 9.013MB 0.000u 0:00.003
ImageMagickResult.tif[7] TIFF 135x178 135x178+0+0 8-bit Grayscale DirectClass 9.013MB 0.000u 0:00.004
ImageMagickResult.tif[8] TIFF 67x89 67x89+0+0 8-bit Grayscale DirectClass 9.013MB 0.000u 0:00.004
ImageMagickResult.tif[9] TIFF 33x44 33x44+0+0 8-bit Grayscale DirectClass 9.013MB 0.000u 0:00.004

*ImageMagickResult.tif is the image created through the convert command line tool

Identify also has a –verbose flag that displays detailed information about an image file. When using diff to compare the 2 text files created from “identify –verbose” we found a few differences between the formatting of the 2 images. For example, “tiff:rows-per-strip:16” exists in ImageMagickResult.tif but not in JavaResult.tif. There are also discrepancies between the resolution and print size between each layer of the images.

If possible, could someone take a deeper look into the attached files that I copied over from the “Identify –verbose” command for each of the images? I would like to know specifically why OpenSlide has trouble recognizing the rest of the layers of an image created through im4java’s convert operation

You could download the initial TIFF image that I used for testing as well as the TIFF files created through both conversions over here:
http://bluegrit.cs.umbc.edu/~tblatt1/tiff_images.tar.gz

Disclaimer: Please do not distribute the TIFF files or the attached text files.

Regards,
Timothy Kim