Dear DCMTK team and - users,
I am trying to assess the impact of known issues in DCMTK on our DCMTK based implementation. It looks fine except for Bug #369 (https://support.dcmtk.org/redmine/issues/369). I am having a hard time understanding what kind of images this bug refers to. So far I have seen hundreds of thousands of different images being decompressed without any flaws. So I am in doubt that this issue really matters in practice which may be the reason why it has been open for such a long time. Any hints about what causes the bug to occur would be appreciated.
The bug mentions some test images, e.g. "cabinf69.dio". I would like to get some impression of what they look like and play around with them a bit. But it seems that they are not part of the DCMTK package. Is there a chance to have a copy of these images in my lab? How can I get them?
Thank you very much and best Regards,
Markus
Decompression Bug #369 / Test data cabinet
Moderator: Moderator Team
-
- Posts: 99
- Joined: Tue, 2005-07-12, 13:50
- Location: Erlangen, Germany
-
- OFFIS DICOM Team
- Posts: 1445
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
Re: Decompression Bug #369 / Test data cabinet
The YCbCr to RGB conversion routine in the IJG JPEG library does not work correctly for cases where BitsStored < BitsAllocated. This is a case that is permitted in DICOM, but probably does not occur in practice (yet), because so far all color imaging modalities produce 24 bit "true color" (i.e., 8 bits/sample). It would happen if a modality started to produce an extended color range and store that, say, with 10 bits/sample. I have uploaded the two sample images that demonstrate the issue as an attachment to bug #369 in the issue tracker.
-
- Posts: 99
- Joined: Tue, 2005-07-12, 13:50
- Location: Erlangen, Germany
Re: Decompression Bug #369 / Test data cabinet
Thank you very much Marco!
I somehow missed to understand that the bug refers to *color* images where Bits Stored < Bits Allocated. I agree that this is not a very realistic scenario. Will look at the images anyway - thanks for providing them - but in fact your explanation is enough for me to assess the bug.
Thanks again,
Markus
I somehow missed to understand that the bug refers to *color* images where Bits Stored < Bits Allocated. I agree that this is not a very realistic scenario. Will look at the images anyway - thanks for providing them - but in fact your explanation is enough for me to assess the bug.
Thanks again,
Markus
Who is online
Users browsing this forum: Google [Bot] and 1 guest