Take the 2-minute tour ×
Video Production Stack Exchange is a question and answer site for engineers, producers, editors, and enthusiasts spanning the fields of video, and media creation. It's 100% free, no registration required.

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.

share|improve this question
    
What is your deliverable? –  filzilla Aug 1 '13 at 23:20
    
@filzilla You mean, screen size or something else? –  Bob Aug 8 '13 at 4:32
1  
@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 Aug 8 '13 at 14:45
add comment

2 Answers

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 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.

share|improve this answer
    
It looks like currently ML does not use compression for the RAWs from what I can gather from the ML forums. –  AJ Henderson Aug 2 '13 at 1:59
    
if I got it right, it would be around 260MB per second. I guess they do some kind of compression to YUV? –  Bob Aug 2 '13 at 4:51
    
@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 Aug 2 '13 at 13:32
1  
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 Aug 2 '13 at 19:50
1  
@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 Aug 3 '13 at 1:39
show 4 more comments

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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