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

[Roger Leigh]

On 28/06/18 00:33, Dennis Ai wrote:
> 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?

This comes down to the XY plane for each (Z, T, C) combination having a 
separate TIFF directory for that plane.  It's a requirement that each 
plane be written completely before moving to the next; the plane order 
is set by the DimensionOrder enumeration, and it is expected that 
ordering be followed.

What I think is happening is that when you switch to writing out a 
different plane, it's flushing the current partially written IFD, and 
moving onto the next, which leaves some tiles unwritten.

Unless libtiff allows revisiting of directories and updating of the tile 
offsets and sizes in place, this limitation is quite difficult to work 
around.  However, should it be possible we can certainly look into 
updating the TIFF writers to permit this.

One option would be to use TIFFRewriteDirectory().  However, this 
duplicates the entire IFD including all tile offsets and sizes.  This 
can end up being very costly--the metadata could occupy more space than 
the pixel data depending upon the write pattern.  For images with tens 
of thousands of tiles, this gets even more costly.

In the interim, we could certainly document these requirements more 
clearly, and we could also throw an exception if writing out of the 
required order.

In the longer term, supporting HDF-based, rather than TIFF-based 
containers would allow these constraints to be completely relaxed since 
it supports arbitrary updates to the underlying chunked storage. 
Similar improvements might also be possible with other container formats.


Regards,
Roger