Raw images are produced by cameras, scanners, etc. and typically give you more post-processing flexibility than JPEG images.
If I’m serving this kind of file from my web server, which media type (a.k.a. MIME type) should I use? I’m specifically interested in the CR2 files produced by recent Canon cameras, but answers could also address Adobe’s Digital Negative (DNG) format or raw files from other manufacturers’ cameras. (I didn’t see anything relevant in this list from the IANA.)
According to this XML file from the (defunct?) GNOME RAW Thumbnailer project, the MIME type for raw images in general is image/x-dcraw. Listed by their file extensions, here are the other file types mentioned in that file:
ARW: image/x-sony-arw
CR2: image/x-canon-cr2
CRW: image/x-canon-crw
DCR: image/x-kodak-dcr
DNG: image/x-adobe-dng
ERF: image/x-epson-erf
K25: image/x-kodak-k25
KDC: image/x-kodak-kdc
MRW: image/x-minolta-mrw
NEF: image/x-nikon-nef
ORF: image/x-olympus-orf
PEF: image/x-pentax-pef
RAF: image/x-fuji-raf
RAW: image/x-panasonic-raw
SR2: image/x-sony-sr2
SRF: image/x-sony-srf
X3F: image/x-sigma-x3f
It might be too late for the author of the question, but might be helpful for others struggling with the same problem.
For .CR2 it is image/x-dcraw.
For .DNG it is image/x-adobe-dng
Using the convention of Gnome raw thumbnailer might be an option but MIME is assigned by IANA based on reference standards and/or requests of the vendors, so is certainly a non-uffical way even though these are the MIME the vendors are using. The list of official IANA MIME can be found here. All the other list are actually unofficialial. Also, the Wikipedia list is often not updated.
If the MIME is not present in the list you could extract it using tools such exiftool and looking for MIME Type.
I would also consider to use application/octet-stream which is an official MIME type and is used for unknown types of binary data as explained in RFC 2046, at least the application will know that it is a binary file.
If you don't like this solution or a MIME used by the vendors and need to disambiguate from multiple RAW image files, I would follow the convention used for other proprietary image types in the standard: image/vnd.<manufacturer>.<filename extension> for instance for NEF by Nikon corporation and .mrv for Minolta:
image/vnd.nikon.nef
image/vnd.minolta.mrw
But of course this is a pure speculation and will be not recognized by other application.
Related
There have been several Q&A's on stackoverflow on the maximum length of media types (also known as MIME types), like this one and this one.
However, none of these seem to incorporate that media types can also have parameters. See for example this document
At a fundamental level, you can specify the type of a media file using a simple MIME type, such as video/mp4 or audio/mpeg. However, many media types—especially those that support video tracks—can benefit from the ability to more precisely describe the format of the data within them. For instance, just describing a video in an MPEG-4 file with the MIME type video/mp4 doesn't say anything about what format the actual media within takes.
[...]
video/webm; codecs="vp8, vorbis"
A WebM file containing VP8 video and/or Vorbis audio.
I've skimmed over RFC6838 but I can't seem to find any limit, nor any mention that the subtype length limit includes parameters.
It seems to me now there is no real limit to media type lengths if parameters are appended to them. Am I wrong?
What's the difference between application and text in media types and when do they use what?
For example there is text/html but on the other hand it's application/json.
Is this a historical thing?
This is described on the MIME types page of the mozilla documentation.
application refers to any kind of binary data while text is theoretically human readable.
type/subtype
The structure of a MIME type is very simple; it consists of a type and
a subtype, two strings, separated by a '/'. No space is allowed. The
type represents the category and can be a discrete or a multipart
type. The subtype is specific to each type.
A MIME type is case-insensitive but traditionally is written all in lower case.
Further down the page you can find a table containing the discrete types:
Type Description
text Represents any document that contains text and is theoretically human readable
image Represents any kind of images. Videos are not included, though animated images (like animated gif) are described with an image type.
audio Represents any kind of audio files
video Represents any kind of video files
application Represents any kind of binary data.
To answer your question about JSON, while you'll frequently come across JSON that is human readable it's primarily used for containing data and isn't necessarily intended to simply be read. Meanwhile a machine can always easily convert the data from JSON into an object (assuming the JSON is correctly formatted).
I have seen an example of what i intend to do from this question uploading documents to sql server i have this working fine, but how would you upload an .mpp file? What would be the type be for it I have been searching for a while but can't seem to find anything.
As detailed here, you can see a few different MIME types that could be used. The following is that list:
application/vnd.ms-project, application/msproj, application/msproject,
application/x-msproject, application/x-ms-project,
application/x-dos_ms_project, application/mpp,
zz-application/zz-winassoc-mpp
NOTE: "MIME type for [File Extension]" is a good phrase to use when searching for these things
Is there what could be considered a "default" mimetype?
I've seen "unknown/unknown" and "application/binary". But is there a default to revert to when no other MIME type is found?
The least specific official MIME type is application/octet-stream. Without any additional information, it says "here is a bunch of bytes, hopefully there is an application over on your end which knows what to do with them". Sometimes there is a file name which helps convey to the recipient what to do with the data.
"unknown" doesn't really add anything over this, except to confuse clients who don't support random unofficial MIME types. Ditto for application/binary; it's just a non-standard way of restating "octet-stream".
This is the answer to "What can I put in the Content-Type: header if I can't find an existing content type which adequately describes my data?" which is how I have interpreted this question. The proposed duplicate Unknown file type MIME? has a lengthy answer which discusses "How is my data interpreted if I don't put a valid Content-Type: header?" specifically in an HTTP context; the answer to that is protocol-specific (in email, for example, the default implied Content-Type: for MIME body parts which do not contain this header is text/plain; charset="us-ascii").
I am trying to develop a plugin/component that can change the media file format from one to another. Specifically, I need it to convert the "tiff" file to array/single copy of "jpg" image file.
Kindly guide, how I can implement it or is there any kind of tutorial link from where either I can download it or take some help to develop it. Thanks in advance.
We did this in our CMS (built on CakePHP 1.2; sorry if there are any significant discrepancies I'm not aware of) using a behaviour. That makes the controller logic very easy (in fact we use a baked controller without any modification at all).
Unfortunately TIFF isn't a supported file format in GD (the default image manipulation library in PHP). You'll need to use ImageMagick or an equivalent tool to do the actual conversion itself, but the logic for implementing it in your CakePHP project won't be any different to what I describe here.
The behaviour (in our case) was used to generate images as thumbnails as well as page resolution and to convert the uploaded file format into JPEG.
In its beforeSave() method it checked that data was specified (and that there was no error), and then pulled the tmp_name value from the posted data (and removed the posted data object).
In its afterSave() method, it actually performed the image conversion task itself (putting the generated images in the expected location on disk), then updated any foreign keys on extended models with the uploaded image's ID. We do this in the afterSave() operation so we have a database ID to use to name the files on disk.
In its afterDelete() method we unlink the files on disk.
Using the behaviour in the model is as simple as telling the model (where ContentImage is the name of the behaviour):
var $actsAs = array('ContentImage');
Although we also use the model to define the output directory since we had a few models that implemented the behaviour, and it felt like the right thing to do, e.g. in the model:
function getThumbnailDir() {
return WWW_ROOT.'img'.DS.'upload'.DS.'thumb';
}
and in the behaviour itself the output path becomes:
$Model->getThumbnailDir().DS.$Model->id.'.jpg'