Re: dicom support

[Andy Buckle]

Really nice. I hardly thought that my original email would elicit such
enthusiastic help.

I will definitely use that for now. My one reservation is that a user
would have to recompile to edit the values. It would be nice to have
them in some kind of text file. I wanted to avoid writing parsing code
if possible. Maybe using some standard octave functions for loading
and saving variables would be a good idea?

I wonder if we should continue off-list? I guess we have gone beyond
the interest of most of this list's subscribers.

Andy

On Mon, May 3, 2010 at 5:38 PM, Judd Storrs <address@hidden> wrote:
> Resending because the attachments were too large and bounced.
>
> 2010/5/3 Judd Storrs <address@hidden>:
>> On Mon, May 3, 2010 at 4:15 AM, Andy Buckle <address@hidden> wrote:
>>> I wanted to avoid having to parse dictionary files. Though, as we will
>>> need to do the lookup both ways, and don't want spaces and apostrophes
>>> in the names, we may have to. GDCM seems to use something more complex
>>> than just a single file for its dictionary.
>>
>> Since the gdcm developers intend to add keywords and keyword lookup in
>> the future, we can just use a simple workaround for now.
>>
>> I made a simple bi-directional lookup table based on the dicom3tools
>> dictionary as a bootstrap. This excludes the keywords that have
>> multiple ids such as the overlays ((60xx,0100)  OverlayBitsAllocated).
>> M does have these in its dictionary. I'll have to poke around and see
>> how M handles these cases. Maybe it returns these as cell arrays or
>> something. I don't think I have any DICOM files with these sorts of
>> elements so I'll have to hunt a bit.
>>
>> When keywords become available within gdcm it should be
>> straightforward to update that part.
>>
>>
>> --judd
>>
>



-- 
/* andy buckle */