How do you use a TransposeCodec to indicate that the bytes in a chunk vary along the 1st axis quickest (aka F-order)?

[maxrjones]

zarr-developers/zarr-specs#189 replaced chunk_memory_layout with the Transpose codec. I'm struggling to figure out how to use that in-practice and would greatly appreciate help. This is a diagram of what I'm trying to do (from here in excalidraw):

I use a experimental imagecodecs wrapper to first apply a Bytes -> Bytes Deflate codec. After that, the byte string will contain 24 bytes representing the red, blue, and green values of an image pixel (each 8 bytes), repeating for each pixel in the image. I'm uncertain of how to go from this byte string to a (3, n, m) array where the first dimension represents the band using the V3 codec structure.

For context, the most common RGB storage format in TIFFs follows this encoding AFAIK and I'm trying to figure out how to represent that following the Zarr V3 spec to provide "virtual" zarr datasets in https://github.com/maxrjones/virtual-tiff/tree/RGB.

[maxrjones]

I was able to decode this data by writing a custom ArrayBytesCodec that's almost identical to Zarr's default Bytes codec but specifies order="F" when reshaping and subsequently gets the data into C-order in memory using numpy.ascontiguousarray() - https://github.com/maxrjones/virtual-tiff/blob/RGB/src/virtual_tiff/codecs.py#L94-L98. I'm sure this isn't the proper way to approach the problem though.

[d-v-b]

what happens if you use the default Bytes codec? I would guess that it would produce an array with the right dimensions, but in the wrong order. Using a Transpose codec on this array with an order parameter that reverses the input dimension order should effectively apply a C-to-F order conversion. At least I think that's how things are supposed to work.

[maxrjones]

@sharkinsspatial pointed out to me that the chunky/bil vs planar/bsq TIFF storage settings are a bit different from C vs F storage order, which explained why array returned from the default Bytes codec wasn't just a transposed version of the expected dataset. So it turns out we will need a specific codec for this type of data (e.g., ChunkyCodec prototype).