[ome-users] converting big ndpi-files

[MEYENHOFER Felix]

Hi Melissa


> On 22 Sep 2015, at 17:42 , Melissa Linkert <melissa at GLENCOESOFTWARE.COM> wrote:
> 
> 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);

So I tried this:

	ImageReader reader = new ImageReader();
	ServiceFactory factory = new ServiceFactory();
	OMEXMLService service = factory.getInstance(OMEXMLService.class);
	IMetadata inMeta = service.createOMEXMLMetadata();
	reader.setMetadataStore(inMeta);
	reader.setId(inId);
	reader.setSeries(procSeries);

        IMetadata outMeta = (IMetadata) reader.getMetadataStore();
        outMeta.setPixelsSizeC(new PositiveInteger(1), 0);
        outMeta.setPixelsSizeX(new PositiveInteger(uw), 0);
        outMeta.setPixelsSizeY(new PositiveInteger(uh), 0);
	ImageWriter writer = new ImageWriter();
        writer.setMetadataRetrieve(outMeta);
        writer.setId(outId);

But inMeta and outMeta point to the same root (outMeta.root = OMEXMLMetadataImpl…)
Hence The modifications I to with the setters here above to not apply to both, the input and the output file, hence I get an error
	"loci.formats.FormatException: Buffer is too small; expected 1577745 bytes, got 525915 bytes.”
…because the output file only needs to hold one color (one third of the pixel)

So the question remains, how can I get separate copies of the metadata of the input file and modify one for the and output file? 

> 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.

no, I haven’t.

> 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.

You are right. I read interleaved but the flag was false.
Changing the loop to read out a block of bytes instead of every third one, got me the desired result.