Order of axes for `CuImage.origin`? about cucim

[jakirkham]

Maybe a follow up item here is adding this to the docs

[gigony]

@jakirkham @thewtex

The dimension order of the origin is crucial for 3D images, such as CT/MRI images.

There has been some discussion on origin, spacing, and direction at ITK's board: https://discourse.itk.org/t/images-in-physical-space-in-python/2124/15.
I don't recall the conclusion of the discussion, but it appears that establishing a standard for image metadata across Python image libraries is important.

cuCIM operates with a plugin system, where the primary plugin is the cuSlide plugin.
The cuMed plugin is intended to handle CT/MRI volumetric data, but its implementation is not yet planned; currently, we have only a stub plugin implementation for this.

Currently, for Whole Slide Images, the origin metadata is not extensively utilized and is always set to [(0.0, 0.0, 0.0)]
(

cucim/cpp/plugins/cucim.kit.cuslide/src/cuslide/cuslide.cpp

Line 216 in 39f7c01

std::pmr::vector<float> origin({ 0.0, 0.0, 0.0 }, &resource);

).

[jakirkham]

Thanks Gigon! 🙏

When does this origin get set in CuImage construction? Is this part of the parse call here?

cucim/cpp/src/cuimage.cpp

Line 186 in 46da10e

is_loaded_ = image_format_->image_parser.parse(file_handle_.get(), image_metadata_);

Or does it happen somewhere else?

[gigony]

Thanks Gigon! 🙏

When does this origin get set in CuImage construction? Is this part of the parse call here?

cucim/cpp/src/cuimage.cpp

Line 186 in 46da10e

is_loaded_ = image_format_->image_parser.parse(file_handle_.get(), image_metadata_);

Or does it happen somewhere else?

@jakirkham
Correct, the method call would call static bool CUCIM_ABI parser_parse(CuCIMFileHandle_ptr handle_ptr, cucim::io::format::ImageMetadataDesc* out_metadata_desc) method here (

cucim/cpp/plugins/cucim.kit.cuslide/src/cuslide/cuslide.cpp

Line 216 in 39f7c01

std::pmr::vector<float> origin({ 0.0, 0.0, 0.0 }, &resource);

)