How to implement additional transfer syntaxes?

[ibaryshnikov]

Hi @Enet4 ! I'd like to implement additional transfer syntax in my local fork, in particular
JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]) 1.2.840.10008.1.2.4.70
Can you give any advice about doint it? Even link to a good doc would be helpful, because at the moment I'm stuck with the question how do transfer syntaxes work together, for example is any of the JPEG transfer syntaxes a big endian or little endian?
I also would be happy to share these changes once you are ready to accept PRs

[Enet4]

Hello!

I'm a bit surprised to find people already working on top of this project. My estimated plan for the time being is to launch the first release soon, hopefully this month. Afterwards, I intend to write a concrete roadmap for future developments, so as to also make way for having multiple contributors to the project.

Being able to add more transfer syntaxes is quite relevant, and I'll see what should be adapted in the currently existing crates to harness TS'es with some some form of data compression in an extendable fashion. Thank you for reporting!

[ibaryshnikov]

I'm making a prototype. I had good experience working with this library, thank you for your work! This library already handles half of the files I need to open. To open another half I need either to use C++ library or to make some additions here. As I'm compiling to WebAssembly, the task becomes more tricky.

[Enet4]

I have yet to make a more extensive documentation, but right now the library as is should provide partial support for any standard transfer syntaxes without data set deflating. That is, one should be able to load DICOM objects from files with that transfer syntax, but a proper abstraction for pixel data (as well as similar kinds of data such as waveform) is yet to be designed and implemented. The pixel data can still be retrieved in its encapsulated form and manipulated using other tools, if this happens to be a serious blocker.

In the future, full support can be added by other crates via the inventory registry pattern. The steps will be: (1) implement the necessary encoding/decoding adapters; (2) create a TransferSyntax instance encompassing the adapters; (3) submit it using the submit_transfer_syntax macro.

[ibaryshnikov]

This is solved by now, since there is a big selection of built-in transfer syntaxes, sumbit_transfer_syntax macro, and even the ability to provide an external transfer syntax registry, which was introduced in #17 (comment)