Open tischi opened 2 years ago
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
Sure! I can check this
@tischi What xyz resolution is this? I need both the dimensions (in pixels) and the voxel scaling
@martinschorb could you tell (s.a.)
<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>
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.
Could you also try for 2024, 2024, 24
This gives the same resolutions, but now with different chunks per level: (128, 64, 32), (128, 128, 16), (256, 128, 8), (256, 256, 4)
but why is x
and y
chunk size anisotropic in this case?
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 ] );
}
}
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.
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.
Good point! This is actually already possible in the project creator if you uncheck the box saying 'use default settings'
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".
Is this still an issue?
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.
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.
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...