Hacker News Reader

Comment by raphexion_ | Hacker News Reader

Congratulation. Great work. It is such an ancient but important standard.

I just spent around one year writing Wolfpacs, a dicom load balancer in pure Erlang. (In my spare time).

Question: what is your take on the headers that are "undecided"? For example,the headers that have either signed short (ss) or unsigned short (us) value representation. Most of the parsing is "stateless" but a few headers require "rules". "If previous headers X is Y then VR=OW". I wished they could have made the standard better in that regard.

View on HN

Thanks for the kind words! I will definitely check out wolfpacs.

As for your question: I've run into a couple scenarios that require "lookback" into the parsed Dataset to parse correctly. For example, parsing Native PixelData correctly requires looking back for the Rows Element, Cols element, BitsAllocated element, etc in order to correctly parse the NativePixel data. The futzy thing is that these context "elements" need to come from the current Sequence (if parsing within a sequence). So, I do most of my parsing of sequences recursively, with each recursive frame holding pointers to the already parsed elements in this sequence (it's a stack essentially for nested sequences).

Not sure if that answers your question? For most generic elements though, as a parsing library I try to parse it generically and make the value payload available to the caller in case they need to apply any special logic to interpreting it. Though if you have a specific usecase that needs something that is missing here, please let me know or open an issue :).

Nice! I'll take a look to it.

Usually, for something like that, I would use Orthanc plus a bit of Python or Lua scafolding. What advantages does WolfPACS provides?

Imagine that you have AI solution that do some calculations (e.g, stoke, bleeding in the brain). Often the calculations are very heavy and if you have a lot of data coming in you need to spread the load.

In dicom, a brain scan almost always span many, many dicom files. So when you push over one series, it can contain N images. Which means that there are N transactions to the server.

You cannot simply round-robin the load because all dicom files that belongs to the same series (study) must end up on the same worker.

So the goal of WolfPACS is to inspect the DICOM headers as they files come in, and route the files depending on the StudyUID and Calling AE.

So it is possible to associate certain workers with certain clients. So how a worker is picked is very flexible. Maybe you want to do some A/B testing. Or you want to take a worker offline "softly".

[1] https://github.com/wolfpacs/wolfpacs

Reply on news.ycombinator.com