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

[Mathieu Malaterre]

> 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)
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 ? 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 ?

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...

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

> An other 'funny stuff' we never experienced is that Dicom norm says 
> the "meta elements" (group 0002) must *always* be coded in little 
> endian, and the remaining of the header must follow 'Transfert 
> Syntax'.

That should definitely goes into the 'report'.

> In gdcm we have an heuristic to guess if the endianity of the image 
> is equal to the endianity of the processor we're currently using, and 
> we only check Transfert Syntax value for compression purpose, not for 
> endianity purpose...

Ooops you lost me. I did not understant the last remark.

Now for more detail on the implementation of the 'report':
- Just use gdcmDebug::Error for instance.
- Later modify this class so the we use a ostream, instead of cerr/cout. Thus this will allow us the report error/problem either on cerr / or an ofstream (=file).

Thanks for reading me
Mathieu