[ome-users] converting big ndpi-files

[Björn Quast]

Hi Felix,

its only a guess, but it might be due to the kind of rgb-value storage in your 
ndpi-files. Is this is a version of a tif container? So the rgb values might be 
stored as Chunky format: RGBRGBRGB and so on or as Planar format: RRRRRR.. 
GGGGG.. BBBBB...

You might also tell the ImageWriter that the written data are grayscale? 
Otherwise the copied header cause other programs to interpret them as RGB?

Best Björn
 



> 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=sharin
> g
 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

-- 
Dr. Björn Quast
Universität Bonn
Institut für Evolutionsbiologie und Ökologie
An der Immenburg 1
53121 Bonn
Tel.: 0228/735758   email: bquast at evolution.uni-bonn.de