<p>Keep in mind that it is 14 bit color and there are 8 bits to a byte.  So the uncompressed data rate would be height * width * 14 bits per pixel / 8 bits per byte * fps.  That said, I'm not sure if they store it completely uncompressed.  RAW images are generally compressed significantly, they are just compressed losslessly.  I'm not sure if the MagicLantern hack uses compression or not though.</p>

<p>As far as screen size for noticing the difference between 720p and 1080p, it doesn't have to be big.  Viewing distance makes a bigger difference, but it's fully possible to tell the difference between 1080p and 720p even on screens that are inches in size as long as they actually support 1080p and are viewed from fairly close.</p>

<p>While I wasn't able to find a CC version, Carlton Bale has a <a href="http://s3.carltonbale.com/resolution_chart.html" rel="nofollow">nice graph on his site</a> that shows the screen sizes and distances at which 20/20 vision can resolve the differences.  Note that someone with higher than 20/20 vision would see the differences further out.  It unfortunately only goes from 20 inch displays up though.  </p>

<p>In closer, it might be easier to use a pixels per inch measure.  Photographs are typically suggested to be printed at 300dpi or higher when in close.  A 4.7 inch screen at 720p has around 312 ppi.  Uping that to a 1080p resolution at 5 inches or so has a PPI of 415.  At arms length, it isn't going to be noticeable, but when you get in close to it, say watching in bed with it a few inches from your face, the difference will become quite noticeable.</p>

<p>Thinking about it another way, it really all has to do with how big of an area of your vision the screen takes.  So using a 50 inch screen as a guideline, if the display takes up the area of your vision that a 50 inch TV takes when sitting 8 to 10 feet away, then you won't see better than 720p with 20/20 vision.  If it is taking more than that area, then you will easily be able to see the difference.</p>

CC BY-SA 3.0
2013-08-02T01:59:56.143Z
It looks like currently ML does not use compression for the RAWs from what I can gather from the ML forums.
AJ Henderson
CC BY-SA 3.0
2013-08-02T04:51:12.730Z
if I got it right, it would be around 260MB per second. I guess they do some kind of compression to YUV?
zzzbbx
CC BY-SA 3.0
2013-08-02T13:32:01.147Z
@Bob - I guess they must since I think the data rate requirement is somewhere around 100MB a second as I recall.  I guess what they were all describing as "uncompressed raw" might not actually be uncompressed.  I had seen a page on their site somewhere that had a good summary of data rate requirements, but I couldn't find it when I went digging yesterday.
AJ Henderson
CC BY-SA 3.0
2013-08-02T19:50:48.860Z
With video, it would be '3 channels' instead of '3 colors'. Most DSLRs use chroma subsamping (4:2:0 is the most common) - so it is only the luma channels that uses the entire 14 bits. The other two chroma channels are reduced to a fourth of the original information. (Cameras that output 4:4:4 video are uncommon and expensive)
Bala Sivakumar
CC BY-SA 3.0
2013-08-02T20:17:29.557Z
@BalaSivakumar - Are you sure on this?  Everything I can find seems to indicate that they are taking the raw image data as shot from the sensor and putting it in a file.  The sensor data is per color I believe.  It has to be processed in YCbCr.  [More Detail](http://www.eoshd.com/content/10324/big-news-hands-on-with-continuous-raw-recording-on-canon-5d-mark-iii)
AJ Henderson
CC BY-SA 3.0
2013-08-03T01:39:49.490Z
@BalaSivakumar - ok, I did some double checking.  It is 14 bits per pixel, but it isn't because of chroma sub-sampling, it is because it is the raw values for each pixel prior to adjusting for the bayer filter.  Each pixel is either red, green or blue in raw data with no other color information.  The correct algorithm for data rate would not have the * 3 though.
AJ Henderson
CC BY-SA 3.0
2013-08-03T01:46:20.450Z
@Bob - note the update, after some additional checking I was wrong about the multiple of 3.  RAW only stores the pre-demosaiced values, so each pixel is only one color.
AJ Henderson
CC BY-SA 3.0
2013-08-03T02:05:38.217Z
@AJHenderson: You're right. My comment mixed multiple concepts - the 14bpp should be all luma. The color is 'inferred' during demosaicing according to the Bayer (or other) pattern. Thanks for correcting me!
Bala Sivakumar
CC BY-SA 3.0
2013-08-03T13:29:15.333Z
@BalaSivakumar - thanks for making me fact check as well.  It's a better answer now and we're all walking away with better info.
AJ Henderson
CC BY-SA 3.0
2013-08-02T01:53:06.647Z
2013-08-08T14:36:48.100Z
2013-08-08T14:36:48.100Z
AJ Henderson
<p>If you are recording RAW then you need to know what that really means, is there any compression or not ? You also need to know the colour space, RGB or YCbCr and if chrominance subsampling is involved.</p>

<p>It's only realistic to assume that the compression is lossless and in a real world example we would be looking at a worst case scenario of not being able to compress any better than the original amount of data. That's also assuming that such compression doesn't expand the data.</p>

<p>It seems that you are considering 14 bit video, as in 14 bit per colour channel. If I assume you are talking about uncompressed video, for RGB and YCbCr at 4:4:4 that means you need</p>

<p>width x height x 3 x 2 x fps bytes per second</p>

<p>To explain the constants:</p>

<ol>
<li>There are 3 colour channels</li>
<li>You need 2 bytes to store 14 bits - it is unlikely (but not impossible) that the software is going to be packing multiple 14 bits together without gaps in between. </li>
</ol>

<p>Check QuickTime's v216 format for an example of how 14 bits are typically encoded - 2 bytes.</p>

<p>For YCbCr 4:2:2 you will get 2 pixels encoded in 8 bytes (4 channels = Y0, U, V, Y1; at 2 bytes each) in this case the rate is</p>

<p>(width/2) x height x 8 x fps bytes per second</p>

<p>I'm assuming that your images are an even number of pixels across. Note that in all these calculations I'm assuming there are no padding bytes added to each line for memory alignment A.K.A. 'stride'.</p>

<p>Let's plug in some numbers for 30 fps:</p>

<ul>
<li>1080P at RGB/YCbCr 4:4:4 = 356 MB/s</li>
<li>720P at RGB/YCbCr 4:4:4 = 158 MB/s</li>
<li>1080P at YCbCr 4:2:2 = 237 MB/s</li>
<li>720P at YCbCr 4:2:2 = 105 MB/s</li>
</ul>

<p>If the RAW format is very raw, then you may have to recompute for demosaicking of colour filters.</p>

CC BY-SA 3.0
2013-08-12T19:31:55.397Z
2013-08-12T19:31:55.397Z
koan
<p>This question has probably been asked before, but could not find it. With the possibility of recording RAW video on a DSLR, file size matters because CF cards are limited.<br>
File size can be reduced by recording at 720p as opposed to 1080p. First of all, how do I compute the size needed for a certain resolution? I presume it would be </p>

<blockquote>
  <p>file_size_per_second = height x width x 14 x fps</p>
</blockquote>

<p>and the result must be divided by some compression factor, I guess, otherwise the number would be too large.<br>
Now, the second question is: for practical purposes, how does the size of the screen need to be  be in order to be able to notice differences between 1080p and 720p? Or, perhaps, does it also depend on what is being recorded?<br>
I'm asking this question, because I would go for 720p to save some space if it did not affect video quality significantly. </p>

CC BY-SA 3.0
2013-08-01T23:20:12.847Z
What is your deliverable?
filzilla
CC BY-SA 3.0
2013-08-08T04:32:52.567Z
@filzilla You mean, screen size or something else?
zzzbbx
CC BY-SA 3.0
2013-08-08T14:45:35.980Z
@Bob - is there any additional information that you are looking for that my answer doesn't provide?  I updated it with some more details about distances and screen sizes that someone with 20/20 vision should notice the difference at.
AJ Henderson
<video><video-quality>
DSLR RAW video: 1080p or 720p?
zzzbbx
# DSLR RAW video: 1080p or 720p?

(Asked by: username_0 on 2013-08-01)

This question has probably been asked before, but could not find it. With the possibility of recording RAW video on a DSLR, file size matters because CF cards are limited.  
File size can be reduced by recording at 720p as opposed to 1080p. First of all, how do I compute the size needed for a certain resolution? I presume it would be

> file\_size\_per\_second = height x width x 14 x fps

and the result must be divided by some compression factor, I guess, otherwise the number would be too large.  
Now, the second question is: for practical purposes, how does the size of the screen need to be be in order to be able to notice differences between 1080p and 720p? Or, perhaps, does it also depend on what is being recorded?  
I'm asking this question, because I would go for 720p to save some space if it did not affect video quality significantly.

**Tags:** video, video-quality

> **Comments:**
> **username_1**: What is your deliverable?  
> **username_0**: @username_1 You mean, screen size or something else?  
> **username_2**: @Bob - is there any additional information that you are looking for that my answer doesn't provide?  I updated it with some more details about distances and screen sizes that someone with 20/20 vision should notice the difference at.  

---

## 2 answers

### Answer by username_2 on 2013-08-02. Score: 3

Keep in mind that it is 14 bit color and there are 8 bits to a byte. So the uncompressed data rate would be height \* width \* 14 bits per pixel / 8 bits per byte \* fps. That said, I'm not sure if they store it completely uncompressed. RAW images are generally compressed significantly, they are just compressed losslessly. I'm not sure if the MagicLantern hack uses compression or not though.

As far as screen size for noticing the difference between 720p and 1080p, it doesn't have to be big. Viewing distance makes a bigger difference, but it's fully possible to tell the difference between 1080p and 720p even on screens that are inches in size as long as they actually support 1080p and are viewed from fairly close.

While I wasn't able to find a CC version, Carlton Bale has a [nice graph on his site](http://s3.carltonbale.com/resolution_chart.html) that shows the screen sizes and distances at which 20/20 vision can resolve the differences. Note that someone with higher than 20/20 vision would see the differences further out. It unfortunately only goes from 20 inch displays up though.

In closer, it might be easier to use a pixels per inch measure. Photographs are typically suggested to be printed at 300dpi or higher when in close. A 4.7 inch screen at 720p has around 312 ppi. Uping that to a 1080p resolution at 5 inches or so has a PPI of 415. At arms length, it isn't going to be noticeable, but when you get in close to it, say watching in bed with it a few inches from your face, the difference will become quite noticeable.

Thinking about it another way, it really all has to do with how big of an area of your vision the screen takes. So using a 50 inch screen as a guideline, if the display takes up the area of your vision that a 50 inch TV takes when sitting 8 to 10 feet away, then you won't see better than 720p with 20/20 vision. If it is taking more than that area, then you will easily be able to see the difference.

> **Comments:**
> **username_2**: It looks like currently ML does not use compression for the RAWs from what I can gather from the ML forums.  
> **username_0**: if I got it right, it would be around 260MB per second. I guess they do some kind of compression to YUV?  
> **username_2**: @Bob - I guess they must since I think the data rate requirement is somewhere around 100MB a second as I recall.  I guess what they were all describing as "uncompressed raw" might not actually be uncompressed.  I had seen a page on their site somewhere that had a good summary of data rate requirements, but I couldn't find it when I went digging yesterday.  
> **username_3**: With video, it would be '3 channels' instead of '3 colors'. Most DSLRs use chroma subsamping (4:2:0 is the most common) - so it is only the luma channels that uses the entire 14 bits. The other two chroma channels are reduced to a fourth of the original information. (Cameras that output 4:4:4 video are uncommon and expensive)  
> **username_2**: @BalaSivakumar - Are you sure on this?  Everything I can find seems to indicate that they are taking the raw image data as shot from the sensor and putting it in a file.  The sensor data is per color I believe.  It has to be processed in YCbCr.  [More Detail](http://www.eoshd.com/content/10324/big-news-hands-on-with-continuous-raw-recording-on-canon-5d-mark-iii)  
> **username_2**: @BalaSivakumar - ok, I did some double checking.  It is 14 bits per pixel, but it isn't because of chroma sub-sampling, it is because it is the raw values for each pixel prior to adjusting for the bayer filter.  Each pixel is either red, green or blue in raw data with no other color information.  The correct algorithm for data rate would not have the * 3 though.  
> **username_2**: @Bob - note the update, after some additional checking I was wrong about the multiple of 3.  RAW only stores the pre-demosaiced values, so each pixel is only one color.  
> **username_3**: @AJHenderson: You're right. My comment mixed multiple concepts - the 14bpp should be all luma. The color is 'inferred' during demosaicing according to the Bayer (or other) pattern. Thanks for correcting me!  
> **username_2**: @BalaSivakumar - thanks for making me fact check as well.  It's a better answer now and we're all walking away with better info.  

---

### Answer by username_4 on 2013-08-12. Score: 1

If you are recording RAW then you need to know what that really means, is there any compression or not ? You also need to know the colour space, RGB or YCbCr and if chrominance subsampling is involved.

It's only realistic to assume that the compression is lossless and in a real world example we would be looking at a worst case scenario of not being able to compress any better than the original amount of data. That's also assuming that such compression doesn't expand the data.

It seems that you are considering 14 bit video, as in 14 bit per colour channel. If I assume you are talking about uncompressed video, for RGB and YCbCr at 4:4:4 that means you need

width x height x 3 x 2 x fps bytes per second

To explain the constants:

1. There are 3 colour channels
2. You need 2 bytes to store 14 bits - it is unlikely (but not impossible) that the software is going to be packing multiple 14 bits together without gaps in between.

Check QuickTime's v216 format for an example of how 14 bits are typically encoded - 2 bytes.

For YCbCr 4:2:2 you will get 2 pixels encoded in 8 bytes (4 channels = Y0, U, V, Y1; at 2 bytes each) in this case the rate is

(width/2) x height x 8 x fps bytes per second

I'm assuming that your images are an even number of pixels across. Note that in all these calculations I'm assuming there are no padding bytes added to each line for memory alignment A.K.A. 'stride'.

Let's plug in some numbers for 30 fps:

* 1080P at RGB/YCbCr 4:4:4 = 356 MB/s
* 720P at RGB/YCbCr 4:4:4 = 158 MB/s
* 1080P at YCbCr 4:2:2 = 237 MB/s
* 720P at YCbCr 4:2:2 = 105 MB/s

If the RAW format is very raw, then you may have to recompute for demosaicking of colour filters.


---

