Added custom types for RAW image files

[PierBover]

I haven't been able to find any primary source, but these are the same mime types used by Google Cloud Storage for RAW files.

If you think it's more desirable to not have them in your database please close this PR.

[dougwilson]

Hi @PierBover I think adding anything is fine to the database, just needs to requisite data. This database pulls from the three sources listed at the top of the README, so anything added there is aggregated here. That is the main goal of this module. Of course, sometimes folks (for various reasons) are not interested in getting data into one of those sources, so we're OK adding them directly here, but we need a way to actually validate these are "real" or not, as in the past when we did not, it was just a war of PRs with different users saying the MIME was one thing or another, so we need some objective way to validate these.

[jakobo]

I don't currently need this, but I did some digging. It appears Canon, Adobe, et al. never published their extension/mime information. Extensions were figured out by the digital photography community by reading the files that came off their memory cards. The decision to use image/x-<vendor>-<type> for the mime can be traced to 2006 as a bug on the FreeDesktop project (underpins GNOME, KDE, and others).

link Almost every digital camera maker has its own proprietary RAW image file format. With the efforts of peoples like David Coffin, author of dcraw, it it now possible to manipulate most of those raw files in Linux and other OSS. Unfortunately, the lack of mime types make them pretty useless in Gnome, KDE and other desktop environments.

bug #3143 already propose to use the mime type "application/x-crw" for the Canon RAW file format. "application" seems incorrect to me since those files are images. Some applications such as gthumb, check on the mime category to select the files.

Also, that mime type does not reflect the fact that the format is specific to canon.

So I propose something of the form "image/x-vendor-ext"

So that answers why no official database has these and why they're named the way they are. If we're willing to take the FreeDesktop project at its word, then we can say that Shared Mime Info Database and xml file in data/freedesktop.org.xml.in is a primary source as the origin of these extension + mime pairings.

Hopefully this is enough @PierBover, where you can update the PR to reference either the original FreeDesktop bug or the first commit to use this mime as your source.

Alternatively, if we trust nginx, we can probably trust the GNOME/KDE folks and could just consume the FreeDesktop MIME database as a source.

[PierBover]

@dougwilson would that satisfy your requirements?

[dougwilson]

Thanks for that research. This project aggregates the three sources listed at the top of the readme. If there is no official source, then we don't add it here directly, as we do not have the resources to properly vet it and this is not meant to be a registry, just an aggregation.

Based on what you said, I suggest following the instructions in the readme for adding custom mime types: https://www.npmjs.com/package/mime-db#adding-custom-media-types

[ymarkus]

Would something like this be sufficient for custom types? https://www.nikonimgsupport.com/na/NSG_article?articleNo=000026447&configured=1&lang=en_SG It is from the vendor after all. Or this? https://www.nikonusa.com/en/learn-and-explore/a/products-and-innovation/nikon-electronic-format-nef.html

[dougwilson]

Thank you @ymarkus . Maybe I'm missing it, but I don't see any mime type listed on either of those pages?

[ymarkus]

Oh, so you need an exact mime type listed there? I thought some specifications would suffice, sorry. So as long as the vendor has no interest in publishing a mime specification, we're out of luck?

[ymarkus]

Just a question for clarification: For example in image/vnd.ms-dds, the source also has no mime information. What does that source have that we need for inclusion of these types?

[dougwilson]

This module's is just a database of mime types. Without a mime type at all, there is nothing to include in the database. Part of the mime type data includes known file extensions, if any. If there is no mime type for a file extension and one wants to propose one, the IANA provides a good process for this which I linked above. This module automatically pulls the data from the IANA database, so that Node.js modules can use it, which is neat. I would suggest if you would like to add/create a mime type for this file extension, just follow the steps at https://www.npmjs.com/package/mime-db#adding-custom-media-types and it'll be included in this module automatically.

[dougwilson]

Just a question for clarification: For example in image/vnd.ms-dds, the source also has no mime information. What does that source have that we need for inclusion of these types?

That type came from absorbing all type data from the original mime module for legacy purposes. All types not from one of the three databases listed at the top of the module will be removed in 2.0 of this database. We do not accept them any longer as the goal of this module is not to be a trlype registry; that is what IANA provides. This module is just to make those available as a Node.js module.