Downsampling Tasks Skipped for Isotropic Inputs in Igneous Task Creation

[torms3]

Problem

In the Igneous task creation, specifically in the downsample_for_meshing and downsample methods, we've observed that downsampling tasks are skipped if the input data is already isotropic (if mip == target_mip:).

Impact

The issue arises when we want to process isotropic inputs through the downsampling pipeline, for purposes beyond merely making the data isotropic. The current code doesn't allow us to do so because the conditions check for isotropic data and skip the downsampling process altogether.

Proposed Solution

We propose a modification to the conditions in the mentioned methods so that downsampling tasks aren't automatically skipped for isotropic data. Providing an option or a flag to choose whether to skip isotropic inputs could be a possible solution.

We suggest something like:

def downsample_for_meshing(run_name, seg_cloudpath, mask, skip_isotropic=True):
    ...
    if skip_isotropic and mip == target_mip:
    ...

And similar for the downsample function.

Benefits

This modification will provide users with greater flexibility in managing their data processing pipeline, enabling them to pass isotropic data through the downsampling process if needed.

Looking forward to your thoughts on this.

[ranlu]

Technically the bot does not skip isotropic input. The downsample stops when the highest mip is isotropic, so if the input is already isotropic, nothing will be done. This is more of a design decision.

There are quite a few details to be decided about the default behavior if we want to do more

1. The first question is what should be called an isotropic resolution, there will always ambiguous cases like [32, 32, 48] or [64,64,48].
2. I suppose we want to downsample z dimension as well when we reached an isotropic resolution, but do we always want this? x/y dimension are still different in the sense that they are imaged in a single image while z are from different images.
3. One of the reason for downsample is to provide reasonable inputs for mesh and skeletonization, use the first isotropic resolution was a natural decision. If we decided to downsample more, do we still want to use the first isotropic resolution or use the lowest resolution or something specified by the user.

I doubt these questions have unique answers makes everyone happy, and I am not thrilled about providing parameters for every possible scenario either. Any suggestions?

[torms3]

I think it's necessary to introduce an optional explicit control for downsampling. Although it's not as common as dealing with anisotropic data, there are certainly cases where we need to handle isotropic data from FIBSEM. In these instances, we should have the capacity to explicitly specify the arguments for igneous's create_downsampling_tasks rather than relying on the default behavior designed for anisotropic data. This will allow us to both downsample and mesh the segmentation result from isotropic FIBSEM data.

[william-silversmith]

For isotropic data, you could potentially use 2x2x2 instead of 2x2x1. Igneous supports both.

…

On Tue, Jul 11, 2023, 5:10 AM Kisuk Lee ***@***.***> wrote: I think it's necessary to introduce an optional explicit control for downsampling. Although it's not as common as dealing with anisotropic data, there are certainly cases where we need to handle isotropic data from FIBSEM. In these instances, we should have the capacity to explicitly specify the arguments for igneous's create_downsampling_tasks rather than relying on the default behavior designed for anisotropic data. This will allow us to both downsample and mesh the segmentation result from isotropic FIBSEM data. — Reply to this email directly, view it on GitHub <#58 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATGQSJFLDWQKGFDI4IZXLDXPUKAZANCNFSM6AAAAAA2FJJ5RI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ranlu]

@torms3, I agree we should make dowmsample process smarter or flexible or both. I am just not quite sure about the best approach, I still hope to be able to expose a more abstract and limited interface as part of the segmentation process. Besides, if you want arbitrary access to igneous tasks, you can use the run igneous tasks command. I suppose for small cutout we do not care about downsample, and for larger dataset it is just one extra step. @nkemnitz did similar things for CNS.
If we really really want to expose the entire igneous interface, I wish it can be done automatically, using a static and dynamic parser of some sort (PR welcome as always), manually add/update it is quite tedious and error-prone.
@william-silversmith, yes, we used 2x2x2 when using igneous tasks explicitly. As part of the segmentation pipeline it is always 2x2x1 and stop downsample when the resolution is approximately isotropic.