[ome-devel] [ome-files-cpp] Cannot Write Multiple ROIs to Image Plane Using SaveBytes
Dennis Ai
dennis.ai at sri.com
Thu Jun 28 00:33:35 BST 2018
Roger,
Thanks so much for addressing this issue so quickly! I have done some testing
on your pull request and found some unexpected behavior. Let's say I have two
planes, where each plane has tiles A, B, C, and D.
Plane 0
--------
|A|B|
--------
|C|D|
--------
Plane 1
--------
|A|B|
--------
|C|D|
--------
If I write tiles A, B, C, D to plane 0, then A, B, C, D to plane 1, it works
correctly (see "one_plane_at_a_time.ome.tiff"). However, If I write tile A to
plane 0 and then plane 1, followed by tile B to plane 0 and then plane 1,
followed by tile C to plane 0 and then something completely bizarre happens
where only one of the ROIs get written properly
(one_tile_to_multiple_planes.ome.tiff).
Any idea why this might be happening?
Here's my code in C# (which is a thin wrapper around OMEFiles).
OMETIFFWriter writer = new OMETIFFWriter();
OMEXMLMetadata metadata = new OMEXMLMetadata();
CoreMetadata coreMetadata = new CoreMetadata();
PixelBuffer pixelBuffer =
new PixelBuffer(439, 167, 1, 1, 1, "int8", "XYZTC");
coreMetadata.SizeX = 439;
coreMetadata.SizeY = 167;
coreMetadata.SizeZ = 5;
coreMetadata.SizeT = 7;
coreMetadata.SizeC = 3;
coreMetadata.PixelType = "int8";
coreMetadata.BitsPerPixel = 8;
metadata.SetCoreMetadata(new CoreMetadata[] { coreMetadata });
writer.FileMetadata = metadata;
writer.CompressionType = "Deflate";
writer.TileSizeX = 32;
writer.TileSizeY = 32;
PixelBuffer strip1 =
new PixelBuffer(256, 64, 1, 1, 1, "int8", "XYZTC");
PixelBuffer stripEnd1 =
new PixelBuffer(256, 39, 1, 1, 1, "int8", "XYZTC");
PixelBuffer strip2 =
new PixelBuffer(183, 64, 1, 1, 1, "int8", "XYZTC");
PixelBuffer stripEnd2 =
new PixelBuffer(183, 39, 1, 1, 1, "int8", "XYZTC");
// Pixel buffer is copied to ROIs on the writer's plane.
CopyGradientToPixelBuffer(strip1);
CopyGradientToPixelBuffer(stripEnd1);
CopyGradientToPixelBuffer(strip2);
CopyGradientToPixelBuffer(stripEnd2);
writer.Series = 0;
for (int i = 0; i < writer.PlaneCount; i++)
{
writer.SaveBytes(i, strip1, 0, 0, 256, 64);
}
for (int i = 0; i < writer.PlaneCount; i++)
{
writer.SaveBytes(i, strip1, 0, 64, 256, 64);
}
for (int i = 0; i < writer.PlaneCount; i++)
{
writer.SaveBytes(i, stripEnd1, 0, 128, 256, 39);
}
for (int i = 0; i < writer.PlaneCount; i++)
{
writer.SaveBytes(i, strip2, 256, 0, 183, 64);
}
for (int i = 0; i < writer.PlaneCount; i++)
{
writer.SaveBytes(i, strip2, 256, 64, 183, 64);
}
for (int i = 0; i < writer.PlaneCount; i++)
{
writer.SaveBytes(i, stripEnd2, 256, 128, 183, 39);
}
writer.Close();
Thanks,
Dennis
-----Original Message-----
From: ome-devel <ome-devel-bounces at lists.openmicroscopy.org.uk> On Behalf Of
Roger Leigh
Sent: Thursday, June 21, 2018 6:30 AM
To: ome-devel at lists.openmicroscopy.org.uk
Subject: Re: [ome-devel] [ome-files-cpp] Cannot Write Multiple ROIs to Image
Plane Using SaveBytes
On 21/06/18 09:08, Roger Leigh wrote:
> On 20/06/2018 18:05, Dennis Ai wrote:
>> Roger,
>>
>> Thanks for the explanation. Unfortunately, I am still running into
>> the same problem.
> At the moment the behaviour is fixed. However, please see
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fome%2Fome-files-cpp%2Fissues%2F97&data=01%7C01%7Cdennis.ai%40sri.com%7C08f8ca1d805f4002a75d08d5d77b20cc%7C40779d3379c44626b8bf140c4d5e9075%7C1&sdata=GfHAOfLC40NuyLq%2F0Kn1JSe9xAaPP5W8dtIiQnlDXn4%3D&reserved=0
> which I just created. It looks like it should be a relatively simple tweak
> to this method:
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fome%2Fome-files-cpp%2Fblob%2Fmaster%2Flib%2Fome%2Ffiles%2Ftiff
> %2FIFD.cpp%23L345&data=01%7C01%7Cdennis.ai%40sri.com%7C08f8ca1d805f400
> 2a75d08d5d77b20cc%7C40779d3379c44626b8bf140c4d5e9075%7C1&sdata=2OsCvlf
> RY5F6xFNfjJOv%2F2k6qBIS2DPxJMQ9HjKvOXI%3D&reserved=0
>
>
> to alter the behaviour. Right now it finishes as soon as it
> encounters an incomplete or missing tile. Given the freedom to flush
> tiles as soon as they are fully covered we could simply change those
> break statements into continue statements. However, this would be
> inefficient for images with thousands of tiles. It would make more
> sense to mark completed tiles and then iterate over and flush these
> specifically. This could be done by either adding a covered flag to
> the TileCache value_type, or by maintaining a separate list of covered
> tiles.
Dear Dennis,
If you would like to have a look at
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fome%2Fome-files-cpp%2Fpull%2F99&data=01%7C01%7Cdennis.ai%40sri.com%7C08f8ca1d805f4002a75d08d5d77b20cc%7C40779d3379c44626b8bf140c4d5e9075%7C1&sdata=3RBr0bUY8Db6vUhW%2Bqr1zRcBE%2FTv1VgPaVO07KfkQ%2Fc%3D&reserved=0
this updates the cache flushing to opportunistically flush every tile if it's
fully covered. This should make it possible to write out the tiles by column
(rather than by row) without resulting in a huge tile cache and a sudden burst
of disc I/O at the very end. Hopefully this resolves the above concern. If
you would like to test it, I would be very interested in your results.
Regards,
Roger
_______________________________________________
ome-devel mailing list
ome-devel at lists.openmicroscopy.org.uk
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openmicroscopy.org.uk%2Fmailman%2Flistinfo%2Fome-devel&data=01%7C01%7Cdennis.ai%40sri.com%7C08f8ca1d805f4002a75d08d5d77b20cc%7C40779d3379c44626b8bf140c4d5e9075%7C1&sdata=wtJUIr7RRNHwwNEUibUq0nXeMx1qbDOIYHadsawYAnU%3D&reserved=0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: one_tile_to_multiple_planes.ome.tiff
Type: image/tiff
Size: 3335404 bytes
Desc: not available
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20180627/ddabec7a/attachment-0002.tiff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: one_plane_at_a_time.ome.tiff
Type: image/tiff
Size: 2472934 bytes
Desc: not available
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20180627/ddabec7a/attachment-0003.tiff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5124 bytes
Desc: not available
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20180627/ddabec7a/attachment-0001.p7s>
More information about the ome-devel
mailing list