5
edits
(→Features: replaced "nasty" with "possible" bug as I think it's gone) |
(→Questions: minor updates to clarify current implementation as answers) |
||
Line 51: | Line 51: | ||
*Octave (and Matlab) stores images (y,x) and DICOM is intrinsically (x,y). Does Matlab transpose images when it loads them? | *Octave (and Matlab) stores images (y,x) and DICOM is intrinsically (x,y). Does Matlab transpose images when it loads them? | ||
**matlab reads the data from the dicom file as if it's a raw block of numbers (and then converts if necessary). | **matlab reads the data from the dicom file as if it's a raw block of numbers (and then converts if necessary). We think that current Octave/dicom behaviour is compatible with matlab. | ||
*I would like people to try m-files that worked with Matlab to let me know of problems. | *I would like people to try m-files that worked with Matlab to let me know of problems. | ||
*(not necessarily) Matlab related: I need examples of odd DICOM files. I have plenty with complex metadata, but I need some with unusual images. | *(not necessarily) Matlab related: I need examples of odd DICOM files. I have plenty with complex metadata, but I need some with unusual images. | ||
Line 62: | Line 62: | ||
**silently convert the metadata to match the pixel type? | **silently convert the metadata to match the pixel type? | ||
**error and do nothing? | **error and do nothing? | ||
*What does dicominfo do when a tag is not in its dictionary: | *What does dicominfo do when a tag is not in its dictionary. Answer: assign to a field like Private_3243_0010 (as Matlab) | ||
*dicominfo: Items in sequences are not necessarily the same, so | *dicominfo: Items in sequences are not necessarily the same, so are stored as nested structs like dcm.RTDoseROISequence?.Item_1.DoseUnits?(as Matlab) | ||
[[Category:OctaveForge]] | [[Category:OctaveForge]] | ||
[[Category:Packages]] | [[Category:Packages]] |
edits