search

UCL / STIR

Software for Tomographic Image Reconstruction
http://stir.sourceforge.net/
Other
104 stars 89 forks source link

Units for images #670

Open KrisThielemans opened 3 years ago

KrisThielemans commented 3 years ago

@danieldeidda and I were discussing possibilities for adding units (Bq/ml,...) to images (and other data). There's a no std::units sadly. Here's a few links. I haven't checked them properly:

We'd need something small, Apache 2.0 compatible, and ideally with some conversion between strings and units.

AnderBiguri commented 3 years ago

I would say that using the one that will cause less extra dependencies can be a motivation, to not over-complicate STIR too much and ensure future maintainability, so I'd vote for boost.

That said, I have no idea :) So you guys chose the one you like more!

KrisThielemans commented 3 years ago

These days I generally avoid boost libraries if they are compiled (it creates no end of trouble with shared/mult-threaded/whatever builds and linking). Luckily, boost::units seems header-only.

It doesn't provide mechanisms to parse units, but maybe this isn't terrible as the list we need it probably quite small.

Anyway, I'm hoping that someone will step up and say that this is a fun project and look into the above libraries :-)

AnderBiguri commented 3 years ago

Makes sense. I am far from an expert on what is best linking/compiling-wise so I may not be able to give too meaningful comment then... In case you have not seen it (and for future readers that may want to investigate this), LLNL has, as you commented above, a large list of unit libraries, and so does PhysUnits. I'd say that with my minimal knowledge, we fall more into those secondary libraries than using LLNL/units.

With a brief look, I liked https://github.com/nholthaus/units , but requires C++14. Compile time, header-only. It is also overwhelmingly used by the C++ community, if :star: are any measure of that. It also has very solid docs ( :smile: ).

This other one seems quite good and used by the community: https://github.com/mpusz/units . The authors of this one are trying to get their library/code/approach into C++23. Thats a plus, for long term support of STIR, as if what we use ends up being the same/similar as std::units in C++23, everything is much easier to maintain. But.... C++20.

If we need to be flexible to C++ versions, then https://github.com/martinmoene/PhysUnits-CT-Cpp11 seems OK (plus has a C++98 separate repo), but I am not convinced its better than boost::units. Skimming through the readme seems that it lacks, for example, offset-based conversions (K to C).

Those are the ones that I think are better. Some of the ones listed are either in Sourceforge or in Google Code, and not update in very long time, so I haven't looked deep into them. I also did not really investigate much all those that have less than 10 GitHub stars. A bit arbitrary, but if we are comparing with boost or >500 GitHub star libraries, I though that choosing an obscure library with 2 stars may bite us in the future.

KrisThielemans commented 3 years ago

Thanks for that!

STIR 5.0 is currently C++-11. I'm reluctant to jump immediately to C++-14 (maybe I'm too slow). That excludes the more exciting stuff I guess.

By the way, https://github.com/nholthaus/units seems a bit stale (2 years, with some PRs and issues since then, but no activity). https://github.com/martinmoene/PhysUnits-CT-Cpp11 is header-only, has some maintenance but really only in some documentation/references (maybe it's perfect already of course).

I wish that they'd write how they're different from others, as opposed to just giving a list.

Now we need to find a student or so...

KrisThielemans commented 3 years ago

I notice that the PET extension to BIDS recommends using CMIXF