On Wed, 22 Mar 2023, Tim Allison wrote:
Thank you, Richard, for raising this.  In looking at these file
formats, it looks like crw is based on ciff, cr2 is based on tiff and
cr3 is based on quicktime.

Always fun when the core of a format (or at least the container) swaps between versions!

For some file formats we do, application/x-this-app; version=1.0,
application/x-thisapp; version=2.0.  For others, we create separate
main mimes as you've done

A lot of the ";version=x.y" ones are where the structure is pretty similar, but you can spot the version from the mime type

A few do have very different structures, and hence parent types. image/vnd.dgn is the main one like that

Otherwise, we / the format authors give them whole different mime types for the different versions. application/vnd.ms-excel vs application/vnd.openxmlformats-officedocument.spreadsheetml.sheet being one such example


In the absense of any official mime types, I'd say the "best" will depend on if most programs handle all 3 versions pretty much the same, or if most programs only do 1-2 of them and don't handle the others / handle them in very different ways


Another option would be to subtype cr2 to crw and cr3 to crw, but then add cr2 to a supported format in our TIFFParser and cr3 to our mpeg/quicktime parser.

Did we ever get round to adding a quicktime / mp4 detector? Ideally we'd have something that checks for some well known atoms, and identify the specific subtype that the container holds from that.


I think we should improve our detection of these at the very least.  I
found some examples for cr2, if we can get examples for crw and cr3,
that'd be helpful.  The dropfiles link isn't working for me at the
moment. :(

I have a friend with a fancy canon camera that ought to be able to generate all of these, but he's a bit busy putting on a theatre production this week... Will try to get some in a week or two!


Some useful links (I want to document these for me.  You probably
already know them!)
[0] https://exiftool.org/canon_raw.html

Using our various IO utils, looks like writing a parser for the original format wouldn't be too much work. If Richard feels like contributing... :)

Nick

Reply via email to