Enet4
commented
3 months ago Thank you for reporting. That does seem a little bit too intense for decoding. Maybe the amount of parallelism can be reduced through environment variables or build parameters, but I am not sure about this. In any case, I suspect that any code changes would have to go through the gdcm-rs crate.
Additionally, I would like to propose a feature request: could the gdcm feature in dicom-pixeldata be designed to handle all transfer syntaxes unless an alternative feature (e.g., openjpeg-sys, rle) is specified? This way, gdcm would serve as the default for transfer syntaxes (when included) but would be overridden if another feature is also included.
I agree that using GDCM as a backup for image encoding implementations would be nicer than existing as a full-blown pixeldata backend. It requires some harmonization work at pixeldata, for an integration that will (hopefully) become less important over time as the DICOM-rs project makes its own integrations with popular image encodings (#125). Feel free to let me know if you are interested in pursuing this.
Hi @Enet4,
I have noticed an issue/bug specifically when using the gdcm feature and decompressing pixel data with JPEG 2000. Specifically, the decompression process utilizes all system cores available (no matter what I do) while decompressing. It is particularly noticeable with large multiframe dicoms (mammo DBT).
As far as I can tell, it doesn't occur with any other encapsulated pixel data decompression from GDCM, and this is probably an upstream issue with GDCM itself. Using openjpeg-sys instead seems to be the solution :)
Additionally, I would like to propose a feature request: could the gdcm feature in dicom-pixeldata be designed to handle all transfer syntaxes unless an alternative feature (e.g., openjpeg-sys, rle) is specified? This way, gdcm would serve as the default for transfer syntaxes (when included) but would be overridden if another feature is also included.