[ome-users] converting big ndpi-files

[MEYENHOFER Felix]

Hello again

I looked around a bit more and tried
	Metadata outMeta = service.createOMEXMLMetadata(inMeta.dumpXML());
This seems to do a deep copy of the metadata. But this also copies everything. So I tried to find a way to select the metadata of a single series. The way I came up with so far is to use the getter methods for the different attributes to retrieve the information and then use the setters on the output metadata.
However there are many attributes and soon we run into the trouble of having to figure out for instance the experimenter index before being able to retrieve the information.

Concerning the manipulation on a higher level than with the attribute getters and setters, I could not find much documentation (maybe I just using the wrong keywords). But I was thinking that I am surly not the first guy wanting to select a single series of a file while conserving the metadata.
So are there any convenience methods, helping to do this with a couple of lines of code instead of hundreds?

Best,

Felix

> On 25 Sep 2015, at 16:48 , MEYENHOFER Felix <felix.meyenhofer at unifr.ch> wrote:
> 
> 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.
> 
> 
> 
> 
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users