Convert CR2 to TIFF

Canon derived CR2 from the TIFF/EP lineage, so the file opens with the same header and the same directory-of-tags structure that a TIFF does. That is why a tool can sometimes list what is inside a CR2 while being completely unable to show you the photograph, and why the registry records the container as TIFF.

None of that makes this conversion a relabelling. What sits in those directories is undemosaiced sensor data at 14 bits per channel — one colour per photosite, arranged on a Bayer grid — and no ordinary TIFF reader has any idea what to do with it. The picture that comes out of this page is a different object entirely: the finished JPEG the camera’s own processor wrote at the moment of capture, decoded and written out as a plain RGB TIFF.

What you get is the camera’s rendering, at full resolution on almost every EOS body. The picture style that was set — Standard, Faithful, Landscape, Monochrome — is in it, along with the white balance the camera chose and its own sharpening and noise reduction. A frame shot in Monochrome comes out monochrome, because the colour lives in the sensor data and the sensor data is not what was extracted.

For a submission that has to be in by Friday, this is usually fine and occasionally not. If the entry will be printed at exhibition size and judged on tonality, the highlight and shadow latitude in the 14-bit sensor data is the reason you shot raw and it is not in this file. That case wants Digital Photo Professional, Lightroom or darktable and a 16-bit export. This page is for the case where the specification says TIFF, the deadline is real, and the picture is already what you wanted it to be.

Submission specifications almost always ask for 300 dpi, and almost as often the person who wrote the form does not mean what the words say. Resolution in dots per inch is not a property of a digital picture; it is the ratio between the pixels you have and the size you print. A file has a pixel count, and a print has inches, and dpi is what you get when you divide one by the other.

The TIFF written here declares 72 in both resolution fields and sets the resolution unit to "none", which is the format’s way of saying it makes no claim about physical size. What satisfies the requirement is the pixel count: 6,720 by 4,480 from a 5D Mark IV is 22.4 by 14.9 inches at 300 ppi, and 5,760 by 3,840 from a 5D Mark III is 19.2 by 12.8. If a portal validates the tag rather than the arithmetic, set the print size in any editor and resave — that writes the number it is looking for without changing a pixel.

It is the plainest TIFF the format allows: no compression, big-endian byte order as the original specification defined it, photometric RGB, eight bits per sample, four samples per pixel with the fourth declared as alpha, and the whole image in a single strip.

Plain is deliberate. TIFF is less a format than a filing system for images, and its readers agree on less than you would hope — LZW is universally supported, Deflate is not, and JPEG-in-TIFF is a different picture inside a TIFF wrapper. Somebody who has been told to supply a TIFF is feeding a specific piece of software, and the uncompressed baseline is the one dialect every such reader accepts. The cost is size and it is paid in full.

Four bytes a pixel, no compression, plus about a kilobyte of header. Multiply the sensor dimensions and you have the answer: 5,760 by 3,840 is 88.5 MB, 6,720 by 4,480 is 120.4 MB, and a 50-megapixel 5DS at 8,688 by 5,792 is 201 MB.

Those numbers collide with real limits more often than photographers expect. Competition portals commonly cap uploads at 25 or 50 MB per file, email attachments at 25 MB, and some club submission systems at less. If the file is over the limit, the fix is a maximum width during conversion rather than a compression setting, because there is no compression setting — halving the width quarters the file.

The preview inside a CR2 carries whatever colour space the camera was set to, and that is a menu item most people set once and forget. If it says Adobe RGB, the numbers in the preview describe Adobe RGB colours. The TIFF produced here carries no ICC profile at all, so whatever opens it will assume sRGB and interpret those numbers as smaller, less saturated colours than they were meant to be.

The symptom is a print that comes back flat and slightly grey compared with what you saw on the camera. The prevention is either to set the camera to sRGB for anything going out this way, or to develop the CR2 properly in software that can convert Adobe RGB to the profile the printer asked for. This is the single most likely way for a technically correct submission to look wrong on the wall.

TIFF is routinely used at 16 bits per channel and that is why print workflows like it. This conversion writes eight, because eight is what an embedded camera preview holds — the 14 bits your sensor recorded were reduced to 8 by the camera’s own processor before the preview was ever written.

Eight bits is enough for a print that will only be printed. It stops being enough when the file is going to be worked on afterwards: pulling shadows up or recovering a sky in an eight-bit file produces banding that a 16-bit file would absorb. If the submission is a master that somebody else will retouch, tell them so, and send them the CR2 as well.

TIFF has a defined place for EXIF, IPTC, XMP and GPS, and this conversion fills none of them. The file is decoded to pixels and written out again, so the shutter speed, the aperture, the lens, the capture time and any location tag are absent from the result.

That matters both ways round for a submission. Competitions that require the capture data as proof of authorship will not find it in the TIFF, and the entry form is usually where that information is typed in anyway. On the other side, a print of your own garden no longer states where the garden is, which is a small gain worth having when the file goes to a stranger.

The whole job runs in the browser: the CR2 is read locally, scanned for its largest embedded JPEG, decoded and written out as a TIFF. There is no Canon software to install, no account and no queue, so a shortlist can be prepared on a work laptop, a borrowed machine or a tablet in a hotel.

Input files are accepted up to 100 MB on the free tier, which every CR2 clears with room to spare — a 30-megapixel frame is around 35 MB. The constraint on this pair is entirely on the output side, and it is arithmetic rather than a policy.

Converting does not consume the original, and the original is the only file that can produce a different rendering later. If the print comes back too dark, or the judge asks for a version without the camera’s sharpening, the answer is in the 14-bit sensor data and nowhere else.

A workable pattern for anyone entering things regularly: extract TIFFs for the entries as they are needed, keep the CR2 files organised by shoot, and only develop the handful that get selected. That way the deadline path and the careful path do not compete, and nothing that cannot be recovered has been thrown away.