Downsampling strategy when writing OME-Zarr

[tischi]

Do we use fixed down-sampling factors? That's not ideal when the input data is very anisotropic. It would probably be better to first only downsample the lowest resolution dimension. Not sure...

[tischi]

For writing N5 and OME-ZARR, I’m just directly using this class from BigDataViewer: https://github.com/bigdataviewer/bigdataviewer-core/blob/master/src/main/java/bdv/export/ProposeMipmaps.java . I haven’t made any changes – so I haven’t really looked into exactly how it chooses resolution levels.

Could we check what it would do for an input image with: X Y Z: 4000x4000x300

[K-Meech]

Sure! I can check this

[K-Meech]

@tischi What xyz resolution is this? I need both the dimensions (in pixels) and the voxel scaling

[tischi]

@martinschorb could you tell (s.a.)

[martinschorb]

https://github.com/mobie/centrioles-tomo-datasets/blob/new_crop/data/tomo/images/bdv-n5/MMRR_06_Grid1_c442.xml

<ViewSetup>
        <id>0</id>
        <name>MMRR_06_Grid1_c442</name>
        <size>2024 2024 577</size>
        <voxelSize>
          <unit>um</unit>
          <size>0.0015578000068664551 0.0015578000068664551 0.0015578000068664551</size>
        </voxelSize>
        <attributes />
</ViewSetup>

[K-Meech]

Ok - I tried with the size and voxelSize in the file from @martinschorb as below:

        final int maxNumElements = 64 * 64 * 64;
        final ExportMipmapInfo autoMipmapSettings = ProposeMipmaps.proposeMipmaps(
                new BasicViewSetup(0, "", new FinalDimensions(2024, 2024, 577),
                        new FinalVoxelDimensions("um", 0.0015578000068664551, 0.0015578000068664551, 0.0015578000068664551)),
                maxNumElements);

        int[][] resolutions = autoMipmapSettings.getExportResolutions();
        int[][] subdivisions = autoMipmapSettings.getSubdivisions();

This gives resolutions of (1,1,1), (2,2,2), (4,4,4), (8,8,8) and chunks of (64,64,64) for every level.

[tischi]

Could you also try for 2024, 2024, 24

[K-Meech]

This gives the same resolutions, but now with different chunks per level: (128, 64, 32), (128, 128, 16), (256, 128, 8), (256, 256, 4)

[martinschorb]

but why is x and y chunk size anisotropic in this case?

[tischi]

I could not explain my own code now, but it looks like for my imaris-writer implementation I am only down-sampling if the data is not too anisotropic:

    private void setDimensionsAndBinningsForThisResolutionLayer(
            long[] currentDimensions,
            int[] currentRelativeBinning,
            long[] lastDimensions,
            long lastVolume )
    {
        for ( int d = 0; d < 3; d++ )
        {
            long lastSizeThisDimensionSquared =
                    lastDimensions[ d ] * lastDimensions[ d ];

            long lastPerpendicularPlaneSize = lastVolume / lastDimensions[ d ];

            if ( 100 * lastSizeThisDimensionSquared > lastPerpendicularPlaneSize )
            {
                currentDimensions[ d ] = lastDimensions[ d ] / 2;
                currentRelativeBinning[ d ] = 2;
            }
            else
            {
                currentDimensions[ d ] = lastDimensions[ d ];
                currentRelativeBinning[ d ] = 1;
            }
            currentDimensions[ d ] = Math.max( 1, currentDimensions[ d ] );
        }
    }

[K-Meech]

So - what would need to be changed? Less downsampling for the images with anisotropic dimensions (but not voxel size)? It would be easiest to make an issue/PR on the BigDataViewer repo directly. Anything that's an issue for OME-ZARR writing, will also be present for anyone writing N5 from fiji too as it uses the same code.

[constantinpape]

just my 2cents: any heuristics to determine the downsampling factors and chunk size will likely lead to sub-optimal results in some corner cases. So it would be good to provide the option to specify this manually.

[K-Meech]

Good point! This is actually already possible in the project creator if you uncheck the box saying 'use default settings'

[tischi]

any heuristics to determine the downsampling factors and chunk size will likely lead to sub-optimal results in some corner cases. So it would be good to provide the option to specify this manually.

Yes, AND the heuristic (default) should be "as good as possible".

[tischi]

Is this still an issue?

[martinschorb]

I used the Python code, so cannot judge. I think I used the manual option once for the clem overview (2D) and this worked nicely.

[K-Meech]

Nothing has changed with the code here, so if you're still not happy with how the downsampling works, we'd have to make an issue / PR on the bigdataviewer repo directly. I think it works fine for now, at least for the images I've tried.