Add ExtendedHeader Implementations
use h.exttyp to identify extended header format and parse into a human-readable type
types of extended headers
| CCP4 | Format from CCP4 suite |
|---|---|
| MRCO | MRC format |
| SERI | SerialEM. Details in the IMOD documentation. |
| AGAR | Agard |
| FEI1 | Used by Thermo Scientific and FEI software, e.g. EPU and Xplore3D, Amira, Avizo. Further details are available from the ThermoFisher software center. |
| FEI2 | FEI2 is an extended version of FEI1 with more metadata included. Further details are available from the ThermoFisher software center. |
| HDF5 | Metadata in HDF5 format |
My original thinking for how to do this was to create an abstract type AbstractMRCExtendedHeader, of which MRCExtendedHeader would be a special case, and then create custom types with human-readable fields for each of these format types, starting with the most common ones first. Then if an MRC file has an extended header type not in this list, the data would be dumped into an MRCExtendedHeader type. We could have a dictionary const that mapped current extended header types to corresponding Julia types, so that a user could roll their own custom AbstractMRCExtendedHeader and have the parser recognize it by type name. What do you think?
exthead branch shows your idea clearly. To add some comment, I'd like to make seperate files for each ExtendedHeader implementations(FEI1.jl, FEI2.jl, MRCO.jl...) and store it on sub directory src/ExtendedHeader while MRCExtendedHeader remains on src directory.
Oh, thanks! I had completely forgotten I had started working on this. I don't think I'll have time to continue this work soon. If you'd like to try, I'd be happy to review. I think the plan you've proposed sounds about right, except I'd prefer the file and directory names remain lower case.