[ome-users] converting big ndpi-files

Melissa Linkert melissa at glencoesoftware.com
Tue Sep 22 16:42:34 BST 2015


Hi Felix,

> I started with the example here
> http://www.openmicroscopy.org/site/support/bio-formats5.1/developers/export.html
> … and encountered the following two problems
> 
> 1)
> If I try to copy the metadata like in the example, except that I call setSeries() first, the output files get much larger than the input. Also if I try to open them afterwards, bio-formats throws an error, about meta-data inconsistency.
> So I use:
> 	IMetadata meta = service.createOMEXMLMetadata();
> 	MetadataTools.populateMetadata(meta, 0, null, false, "XYZCT”, FormatTools.getPixelTypeString(FormatTools.UINT8), uw, uh, planeCount, 1, 1, 1);
> … to create new metadata for the output file.
> However I would prefer to just copy the metadata of the particular series and then call setSizeC(1) to indicate the new color dimension. Isn’t there a way to make a deep copy of the metadata store of the input file and then modify it?

Assuming the reader is set up as described in the documentation, you
should be able to do something like this:

  IMetadata meta = (IMetadata) reader.getMetadataStore();
  meta.setPixelsSizeC(new PositiveInteger(1), 0);

See also
http://downloads.openmicroscopy.org/bio-formats/5.1.4/api/loci/formats/meta/IMetadata.html

> 2)
> to read the pixel data I use 
> 	reader.openBytes(plane, ulc_x, ulc_y, bb_w, bb_h)
> giving the upper left corner coordinates and the bounding box with and height.
> 
> Then I extract a single color and write it with:
> 	byte[] plane = new byte[rgb.length / 3];
> 	int index = 0;
> 	for (int c = colorOffset; c <= rgb.length; c += 3) {
> 		plane[index++] = rgb[c];
> 	}
> 
> 	writer.saveBytes(pp, plane, wx, wy, ww, wh);
> 
> The result then looks like in this file
> https://drive.google.com/file/d/0B2J23DnK1IKySVNjNWxoaFJ4dU0/view?usp=sharing
> It seems that the data is somehow replicated 3 by 3 times. The number suggesting that it has something to do with the rgb. I can’t figure out why this happens though… any ideas?

Have you tried using the ChannelSeparator reader (see
http://www.openmicroscopy.org/site/support/bio-formats5.1/developers/file-reader.html#file-reading-extras)?
This can be used in place of ImageReader, and will automatically
separate each RGB channel into a separate image.  The plane index passed
to reader.openBytes(...) then controls which channel is returned.

If you prefer to implement the channel copying without ChannelSeparator, then it
is important to check the return values of reader.getRGBChannelCount() (the number of
RGB channels) and reader.isInterleaved() (how the channels are stored,
RGBRGB or RR..GG..BB..).  The above code assumes
reader.getRGBChannelCount() == 3 and reader.isInterleaved() == true, but
that may not always be the case.  The value of reader.isInterleaved() is
likely most important here, as the seemingly replicated images are
almost always indicative of an interleaving problem.

Regards,
-Melissa

On Fri, Sep 18, 2015 at 06:46:06PM +0000, MEYENHOFER Felix wrote:
> Hi everyone
> 
> I am trying to convert big ndpi files. To better manage the memory I want to write a plugin using ImageReader and ImageWriter.
> 
> The files have series (several resolutions), 11 slices (z-stacks) and are in RGB.
> The goal is to extract a grayscale stack of a given series (resolution). Furthermore some estimation of the bounding box of the tissue sections is performed on a series ndpi-files, processing a low magnification series. These bounding boxes are then used to determine the uniform image size holding all the tissue sections. So the input and output images might have different sizes. Also the goal is to write only the pixels that contain information about the tissue slice.
> 
> I started with the example here
> http://www.openmicroscopy.org/site/support/bio-formats5.1/developers/export.html
> … and encountered the following two problems
> 
> 1)
> If I try to copy the metadata like in the example, except that I call setSeries() first, the output files get much larger than the input. Also if I try to open them afterwards, bio-formats throws an error, about meta-data inconsistency.
> So I use:
> 	IMetadata meta = service.createOMEXMLMetadata();
> 	MetadataTools.populateMetadata(meta, 0, null, false, "XYZCT”, FormatTools.getPixelTypeString(FormatTools.UINT8), uw, uh, planeCount, 1, 1, 1);
> … to create new metadata for the output file.
> However I would prefer to just copy the metadata of the particular series and then call setSizeC(1) to indicate the new color dimension. Isn’t there a way to make a deep copy of the metadata store of the input file and then modify it?
> 
> 2)
> to read the pixel data I use 
> 	reader.openBytes(plane, ulc_x, ulc_y, bb_w, bb_h)
> giving the upper left corner coordinates and the bounding box with and height.
> 
> Then I extract a single color and write it with:
> 	byte[] plane = new byte[rgb.length / 3];
> 	int index = 0;
> 	for (int c = colorOffset; c <= rgb.length; c += 3) {
> 		plane[index++] = rgb[c];
> 	}
> 
> 	writer.saveBytes(pp, plane, wx, wy, ww, wh);
> 
> The result then looks like in this file
> https://drive.google.com/file/d/0B2J23DnK1IKySVNjNWxoaFJ4dU0/view?usp=sharing
> It seems that the data is somehow replicated 3 by 3 times. The number suggesting that it has something to do with the rgb. I can’t figure out why this happens though… any ideas?
> 
> 
> Best, 
> 
> Felix
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users



More information about the ome-users mailing list