Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

architectures and nomenculature #42

Closed
mattersoflight opened this issue Aug 30, 2023 · 6 comments
Closed

architectures and nomenculature #42

mattersoflight opened this issue Aug 30, 2023 · 6 comments
Assignees

Comments

@mattersoflight
Copy link
Member

mattersoflight commented Aug 30, 2023

Now that 2D and 2.5D UNets from our 2020 paper are implemented in pytorch, we are exploring the space of architectures in two ways:
a) input-output tensor dimensions.
b) Using SOTA convolutional layers, particularly inspired by ConvNeXt.

At this point, the 2.1D network combines both. It is useful to have distinct nomenclature and models to compare these two innovations.

I suggest:

  • 2D, 2.5D, 2.1D, 3D architectures use classical convolutional layers and activations.
  • Architectures that use ConvNeXt design principles can use 2NeX, 2.5NeX, 2.1Nex, ... nomenclature.
@mattersoflight mattersoflight changed the title image translation architectures architectures and nomenculatures Aug 30, 2023
@mattersoflight mattersoflight changed the title architectures and nomenculatures architectures and nomenculature Aug 30, 2023
@ziw-liu
Copy link
Collaborator

ziw-liu commented Aug 30, 2023

On this note, since we are having many more models, the old initialization scheme based on dictionaries is starting to be restricting. I have been thinking about using dependency injection with lightning configs to initialize (and type check!) each underlying model component.

@ziw-liu
Copy link
Collaborator

ziw-liu commented Aug 30, 2023

We also potentially need better names to distinguish between:

  • 3D stem -> 2D encoder -> 2D decoder -> 2D head (currently called 2.1D)
  • 3D stem -> 2D encoder -> 2D decoder -> 3D head (currently called 2.2D)

@mattersoflight
Copy link
Member Author

mattersoflight commented Aug 30, 2023

@ziw-liu @edyoshikun let's use the following.

2.5D UNet: 3D input -> 3D encoder -> 2D decoder -> 2D output
3D UNet: 3D input -> 3D encoder -> 3D decoder -> 3D output
2.5D LUNet: 3D input -> 2D encoder -> 2D decoder -> 2D output
3D LUNet: 3D input -> 2D encoder -> 2D decoder -> 3D output
2.5D UNeXt: 2.5D, but with ConvNeXt layers
3D UNeXt: 3D, but with ConvNeXt layers

@mattersoflight
Copy link
Member Author

mattersoflight commented Aug 31, 2023

@ziw-liu

I have been thinking about using dependency injection with lightning configs to initialize (and type check!) each underlying model component.

The model design and the config file both become modular with dependency injection! Thanks for pointing out this pattern.

Please think through how sensible defaults for modules can be set, such that succinct calls to construct models (example below) still work.

# %% 2.5D UNet
model = VSUNet(
    architecture="2.5D",
    model_config={
        "in_channels": 1,
        "out_channels": 3,
        "in_stack_depth": 9,
    },
)

If your thought experiment is successful, let's start using this pattern to write new models (3D LUNet) and to refactor recent models (2.5D UNeXt, 3D UNeXt).

@ziw-liu
Copy link
Collaborator

ziw-liu commented Aug 31, 2023

2.5D UNeXt: 2.5D, but with ConvNeXt layers
3D UNeXt: 3D, but with ConvNeXt layers

Can we call these nD LUNeXt for consistency?

@ziw-liu
Copy link
Collaborator

ziw-liu commented Jun 28, 2024

#84

@ziw-liu ziw-liu closed this as completed Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants