I have been converting .CR2 files (Canon's RAW format) to TIFF files to make a timelapse video in Photoshop. Upon doing so I was astonished to realise that the file size rocketed from 23.9MB in the case of the .CR2 files to 132.7 MB for the TIFF files (these are 5760 x 3840px images we are dealing with by the way). The images were converted in Lightroom from .CR2 to 16 bit TIFFs with no compression.

Initially I had naively expected no increase in filesize, as no new information is being created. Thinking further, I realised that because of the Bayer filter, only one R, G or B value per pixel is recorded in the raw file, and the rest are interpolated in the TIFF file.

This would explain a 3-fold increase in filesize. However 23.9MB to 132.7MB is more than a 5.5 times increase. I checked one of the tif files in Photoshop - it is a single layer with no alpha channels. Where are the extra megabytes coming from?

  • \$\begingroup\$ How many bits are the TIFF files? 16? How many bits are your .CR2 files? (at most it is 14 and could be less depending on which camera model you have) \$\endgroup\$
    – Michael C
    Aug 9, 2015 at 7:16
  • \$\begingroup\$ The TIFFs are 16 bpc. Huh, I always thought the .CR2 files were 16 bpc too. Just checked the manual - they are 14bpc. That accounts for a 3.4x increase in file size. Still a bit short... \$\endgroup\$ Aug 9, 2015 at 7:25
  • \$\begingroup\$ I think it would be more than 3.4 - You are going from a single 14-bit value for each sensor well to 3 16-bit values. And .CR2 files are also compressed in a non-lossy way. \$\endgroup\$
    – Michael C
    Aug 9, 2015 at 7:32
  • \$\begingroup\$ Aaah, I see. I didn't realise .CR2 files were compressed. I make it 5760*3840*16*3/(8*2*20) = 126.6MB worth of pure image date for the TIFF files. In the right ballpark now, but any idea what makes up the extra 6MB. Can't be metadata, surely? \$\endgroup\$ Aug 9, 2015 at 7:42
  • 1
    \$\begingroup\$ there's also this fancy plugin that applies some gradual adjustments over time, check this answer: photo.stackexchange.com/a/24549/35348 \$\endgroup\$
    – null
    Aug 17, 2015 at 12:26

1 Answer 1


TIFF is a container format which supports a collection of other standards and like any container what's in it will be entirely down to what you (or whoever wrote the TIFF export you're using) has decided to put in it.

At a guess from the file size your converter has gone to 16bpc/RGB uncompressed. If so then that file size looks about right. If it is uncompressed we can confirm it easily...

5760 x 3860 = 22,118,400 (total pixels)

x 3 = 66,355,200 (3 colours per pixel, R/G/B)

x 2 = 132,710,400 (total image size in bytes where 16-bits = 2-bytes)

132.7Mb matches your original file size. The actual file will be a little larger to accommodate the TIFF header, metadata and possibly a preview.

As to why the TIFF is so much larger, there are a couple of main reasons:-

Interpolation - each pixel on the sensor is one of either R, G or B. To get to a full RGB image the raw converter estimates the two other colours (such as R/B for G pixel) from the surrounding pixels. That means our raw file only needs to store 1/3rd of the data that our TIFF does before we start. The truly raw uncompressed sensor data being stored is just under 39Mbytes in this case.

Compression then comes in and takes that 39Mb down further - compression can be tuned if you know what type and format the data is versus general purpose compression algorithms and in the CR2 case they use a lossless JPEG which seems to drop the size by around 25%.

More info: CR2 is actually a TIFF based format which stores a lossless greyscale JPEG (according to this page) which is referenced by ExifTool: Canon Raw File Format - which is worth a read if nothing else than for Phil Harvey's rant about some of the (many) inadequacies of TIFF.

Additional info to cover comments: The 'extra' 6Mb is probably 0's and is just padding to make the 14-bit values fit the 16-bit (2-byte) boundary which Lightroom needs to use as it works with whole bytes. Lightroom encodes the output to match the depth it has worked to even if TIFF supported 14-bits/channel uncompressed, which IIRC, it doesn't and if it did you can assume pretty much nobody has implemented it so you'd end up with technically correct TIFFs which nobody can open (and not for the first time in my experience).

  • 2
    \$\begingroup\$ It might be more helpful in the grey calculation section to indicate the "X 2" is a shortcut for "X (16 bits per each color value per pixel/ 8 bits per bytes)". \$\endgroup\$
    – Michael C
    Aug 9, 2015 at 17:53
  • \$\begingroup\$ Yes, because the times 2 is really times 16 bits divided by 8 bits per byte. \$\endgroup\$
    – Michael C
    Aug 9, 2015 at 17:54
  • 2
    \$\begingroup\$ That calculation accounts for the 16bpc though. It turns out that there is no extra 6MB as I had thought. I only recently switched to Mac and hadn't realised that it uses 10^6 bytes as the definition for a MB rather than 2^20 as in Windows. Everything is accounted for! \$\endgroup\$ Aug 9, 2015 at 17:57
  • \$\begingroup\$ I didn't see any indication of your Mac in the question. Yes, a MB defined as 2^20 is almost 5% larger than a MB defined as 10^6. \$\endgroup\$
    – Michael C
    Aug 9, 2015 at 18:02
  • 2
    \$\begingroup\$ All of the color values for each pixel are interpolated using the values from surrounding pixel wells. i.e. even a pixel with a green mask will include interpolation from surrounding pixels to compute the green value of that pixel in the RGB output. This is due to the fact that the Bayer mask does not totally eliminate light from the other two colors passing through to each pixel well. \$\endgroup\$
    – Michael C
    Aug 9, 2015 at 18:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.