[Dcmlib] Re: some bugs with 'MONOCHROM1 ' and 'MONOCHROM2 '

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

>>Mathieu,
>>
>>In the 'dcm dataset', there is no image (except the Theralys one) 
>>with odd lengths.
>>A few weeks ago I downloaded an image whose some lengths of elements 
>>belonging to a shadow group (0009) are odd, so I think we can find a 
>>lot of others, in the world ...
>>What I meant is that the commit you did corrects the length *and* the 
>>string, in order to avoid further troubles (great !), but PrintHeader 
>>displays the length (and the string) as they are after the 
>>correction, so we cannot see at a glance if the image does contain an 
>>oddity or not.
>>    
>>
>
>Alright I understand your point, and I fully agree. I like being able to 'point' bad DICOM images.
>But one thing then, we should be consistent:
>1. Either keep everything from the buggy header (like 13 lenght for the broken GE image)
>  
>
Sometimes, there is an *actual* bug in the Header (the written length 
doesn't match with the written string.
We have 2 images :
- the  well known 'Broken GE image' :  2 lengths are '13', but the 
string is 10 characters long
- the less known (at least on the web) broken 'Siemens Leonardo' images 
(same kind of pb)
In this case, we need to correct it, everywhere (even in the display)

Sometimes, there is no bug, only a light violation of Dicom Rules (ex : 
Theralys images 'Version number' is announced as 3 characters long, and 
it is!
No problem for keeping, after reading, both original length and original 
string -we shall have to correct then at write time-, or correcting then 
at the very read time .
What I suggested is we should keep the abiblity to display (at 
PrintHeader time) the original length, so we could see at a glance, if 
there is an oddity or not.

>2. *OR* correct everything as we load the image.
>
>I think both 1 and 2 make sense. Therefore I would like to go the e-film way. Where we create the 'report' of problem found during the reading of the image. That is to say, when we do PrintHeader, do we really care about the 13 lenght from the GE image read ?
>
We don't.

> No, not really, what we are looking for is a warning from GDCM, that something was not DICOM compliant and this won't be preserve when the image will be written back. Does that make sense for you JP ?
>  
>
The bugs that make the image unreadable must be corrected (for instance 
: mismatch between 'length' and the string;
Stuff that don't strictly follow Dicom rules should be shown 'as is' (no 
matter if the length is made 'strict Dicom' at the reading time or not)

>BTW, currently, there is no real distinction between reading and writting. Thus writting manipulate the header from the image read (modifying some important field). For instance I am a bit concerned. consider the follozing scenario:
>- I read my jpeg compress DICOM
>- I write it on the disk (the header is changed since gdcm does not write jpeg compress).
>- I access some field, and gdcm answer me: yes your DICOM is not compress, whereas my input is...
>  
>
Oops! I though the formerly calles 'PixelData' class was designed to 
solve this problem ?

>Again I vote for separation between reading/writting. This is the main reason -I think- why gdcmFile was (is still) so complex.
>
>  
>
No objection

JPRx