[ome-devel] [ome-files-cpp] Cannot Write Multiple ROIs to Image Plane Using SaveBytes

[Roger Leigh]

On 20/06/2018 18:05, Dennis Ai wrote:
> Roger,
> 
> Thanks for the explanation.  Unfortunately, I am still running into the same problem.  I created the following test example (in my C# wrapper around OME-TIFF).
> 
> OMETIFFWriter tiffWriter = new OMETIFFWriter();
> OMEXMLMetadata metadata = new OMEXMLMetadata();
> CoreMetadata coreMetadata = new CoreMetadata();
> PixelBuffer pixelBuffer = new PixelBuffer(512, 64, 1, 1, 1, "int8", "XYZTC");
> 
> coreMetadata.SizeX = 512;
> coreMetadata.SizeY = 128;
> coreMetadata.SizeZ = 1;
> coreMetadata.SizeT = 1;
> coreMetadata.SizeC = 1;
> coreMetadata.PixelType = "int8";
> coreMetadata.BitsPerPixel = 8;
> 
> metadata.SetCoreMetadata(new CoreMetadata[] { coreMetadata });
> tiffWriter.FileMetadata = metadata;
> tiffWriter.CompressionType = "Deflate";
> tiffWriter.TileSizeX = 64;
> tiffWriter.TileSizeY = 64;
>              
> tiffWriter.Open(TestTIFFFilePath);
> CopyGradientToPixelBuffer(pixelBuffer); // This copies a gradient to the pixel buffer.
> tiffWriter.Series = 0;
> tiffWriter.SaveBytes(0, pixelBuffer, 0, 0, 512, 64); // This call works.
> tiffWriter.SaveBytes(0, pixelBuffer, 0, 64, 512, 64); // This call does not work.

Should there be a

   tiffWriter.close()

at this point, or is that implicit with C#?  That might be needed to 
flush the final updates to the tile offsets and sizes fields.  It can be 
explicit or implicit with the underlying C++ writer (it closes in the 
destructor if you don't do it before destruction), but I'm not sure how 
the object lifetime ties in with the C# wrapper.

> When I open the image, I get the attached image.  The first row of tiles is written (from the first saveBytes call).  The second row of tiles, when you open the image, is just a repeated version of the last tile in the first row.  My assumption, when I look at the file size of the image, is that the second row hasn't actually been written, and the last tile was just displayed for all unwritten tiles.

"tiffinfo -s" should help show what has been written.  This will show 
all the tile offsets and sizes.  Unwritten tiles should have an offset 
and size of 0.

> Also, can you point me to the documentation that states that the tiles must be written in linear order?  When I was previously working with libtiff (via LibTIFFNet), I don't recall having run into that limitation?

After re-reading the documentation, it looks like I'm mistaken and that 
libtiff should be happy with any order.  I think I've confused this with 
the behaviour of Bio-Formats, which OME Files copied during its initial 
implementation.  I think that's where the current restriction comes 
from.  It should be quite possible to lift the constraint.

> I could write tiles in any order I wanted.  Forcing the tiles to be stored in cache could be problematic for us, as in your example:
> 
>    ┌──┬──┐
>   A│01│23│B
>    │45│67│
>    ├──┼──┤
>   C│89│ab│D
>    │cd│ef│
>    └──┴──┘
> 
> We would like to write a whole slide image, but must do it in order of A-C-B-D, where A and C make up a strip, and B and D make up a 2nd strip.  Is there any way to force flushing?

At the moment the behaviour is fixed.  However, please see 
https://github.com/ome/ome-files-cpp/issues/97 which I just created.  It 
looks like it should be a relatively simple tweak to this method:

 
https://github.com/ome/ome-files-cpp/blob/master/lib/ome/files/tiff/IFD.cpp#L345

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.


Regards,
Roger