Can you please add '.gipl' in imageio/simpleitk_reader_writer.py by default

[mark-joe]

Hi all,

I raised this request in #1814, but then it seemed it was not necessary anyway so we dropped/closed the issue. After downloading latest version of nnU-Net (2.3.1) is again seems the gipl files are not handled automatically. So, and this is (apparently) a small request, can you please add '.gipl' to the supported_file_endings in the simpleitk_reader_writer.py (in directory imageio). We then can employ nnU-Net 'out of the box' in our department, and no source code changes are needed. Thanks!

[dojoh]

thanks for the inquiry, I will forward this to Fabian.

[dojoh]

as this is a very specific file format with not much use Fabian suggests that you create a fork on your end and add the support to the file format.

[mark-joe]

Hi dojoh,

Thanks for looking into this. Indeed gipl is not much used, but 100% natively supported in ITK and thus in quite many applications. I'm not familiar with git and forks, so I'm not gonna do that. It is adding one line to the mentioned file (simpleitk_reader_writer.py), see above. Never mind, thought it was handy for you and me, then we could update nnUNet a bit more often, but since version 2.4 we have update problems anyway, so we are gonna stick with 2.3.1 for a while.

[FabianIsensee]

Hey you know what? Let's just do it. Usually am hesitant about including stuff only very few people need because this only adds effort on our end when maintaining it looking forward. In this case the effort should be minimal and we can just drop support in case something breaks in the future. Can you please let us know what your issues with v2.4 are?

[mark-joe]

Hi Fabian,

Thanks for your cooperation, much appreciated! Please allow me to elaborate on the choice of gipl. I work at a radiotherapy department and it is obviously easiest if I can swap out files between the clinical delineation software and the auto-contouring solutions (like nnUNet) without format conversions. It so happens that gipl is among the formats most supported between all those programs. Since V2.4 we encounter several problems that are also reported on the issues, torch.compile, triton, GPU capabilities, I guess mostly pytorch and cuda stuff. I expect you introduced some new pytorch functionality in the code since V2.4. Again working in a clinical setting I cannot update/upgrade the clinical GPU servers my selves. The clinical maintenance cycles are not very suitable for fast paced developments like AI. Then again, we use autocountouring since 2019, somehow we manage, but not using the most up to date versions. Maybe for you also good to realize: the nnUNet software is entering many fields with many applications. I guess the type of users also has changed through the years, not only DL developers who are used to update the NVidia drivers and cuda twice a year. So, careful chosen updates, so that the majority of nnUNet users can keep up would be my advice. Or fast and slow update tracks. Just my two cents! Fabian, thanks for your continuous work on nnUNet!

[FabianIsensee]

Hey, thanks for the input! I know it can be hard for some users to keep up with rapid changes in the AI world, but at the same time there is also no obligation to update to more recent versions. If you are having troubles with keeping drivers and other parts of the software stack up to date due to external (and completely understandable) constraints then it's just easiest to stick to a known version. Given the fast paced environment we are in we cannot compromise innovation for the sake of keeping compatibility with dated environments. Please also keep in mind that we are just a bunch of researchers providing all of this for free for everyone to enjoy. None of us are full time developers. We don't have the resources to professionalize development more - we could only do that if we asked for a lot of money from our users. You'd surely agree that the world is a better place with such software being freely available :-)