4:4:4 10bit single CMOS HD project

Kyle Granger · February 24th, 2005, 05:31 PM

Obin, I have been normally using 48 and 50 FPS with the SI-1300 and SI-3000. It is possible to instruct the grabber to drop every other frame (or x frames), so you receive 24 or 25 (or have timelapse). (you probably know this)

It is *also* possible to increase the clock rate, and increase the number of lines in the vertical blanking period, and still maintain the desired framerate. This further reduces artifacts from rolling shutter, since the time per scanline is reduced. Caveat: there is a limit to the number of lines in the VB interval, though I can't say off the top of my head what that is. You might, for instance, have to run the camera at a 58.45 fps rate (with normal VB), add the additional (max) VB lines, set your skip to one, and then receive your 24.0000 or 23.9760 frames per second.

I know I am basically repeating what Steve said.

Florin Popescu · February 24th, 2005, 05:48 PM

Kyle and Obin,

If you guys can barely squeeze the data into RAIDs, how am I ever going to make into notebook hdds. Here's how..

As the data is scanned sequentially from the chip, a histogram of pixel or pixel differential is compiled for each frame, and when it's flushed from the buffer onto disk, it gets huffman coded. Variations thereabouts. A simple scheme requiring very few computational resources, time or memory... much less than jpg.

Not deterministic, sure, but you can't shoot uniform random noise over whole dynamic range even if you tried. Do you guys really write RAW data?

This type of lossless compression seems to get compression ratios of at least 2 (with everyone's favorite huffman coder).

Seems easier than getting getting that extra 10% out of the drive. And if you have to NLE or whatever, what's the use of a 100MB stream anyway?

Juan M. M. Fiebelkorn · February 24th, 2005, 07:05 PM

LOL hahaha, do you really believe what you are saying?
you are getting something like 94 Mbytes/s.
so you wanna huffman compress it to record it onto a Laptop 2.5 inch drive???
like what? a 2.5 inch 10K RPM one?
So your huffman will compress like 3:1 sustained or even more?

I'm not getting your point, really.not trying to be offensive...

Edit:Now that I see you are Dr. and Fraunhofer guy.Why don't you just make some kind of lossy codec for it, keeping at least 10 bit bitdepth.
You could even modify Xvid or simillar to accept 10 bit and compress the bayer.
May be even better avoid huffman and use a range encoder!!

Obin Olson · February 24th, 2005, 07:55 PM

we are using VB indeed it works well for what it is...as far as the save stuff I think that is exactly what we are doing ;) and thanks for the info! I did pass it on to our programmer just incase

Obin Olson · February 24th, 2005, 07:59 PM

www.dv3productions.com/pub/dog.tif

works fine for me....

Wow how gamma can help with the exposure of th image while shooting! I have been playing around with it with CineLink...looks like we will still need a way to show histogram? or maybe zebra... also i want to have a button that allows one to 'zoom in' on a live image for focus ..this will help lots...

I got a chance to hook up the touch screen monitor today an d 'playshoot' with no recording(as it's not working yet) ...touch screen is VERY good and EASY to use! bad thing is the screen has a weird tint to it with the touch surface...I don't like that...anyone seen a VGA splitter so that we could have a nice clear screen to frame with?

Obin Olson · February 24th, 2005, 08:15 PM

"I am using a commercial routine written in assembler to write to disk. I
have tried both the asynchronous version (Overlapped) of CreateFile with
WriteFile and fOpen, etc... and that are an order of magnitude slower than
the routine I use. I also tried copying memory to disk and a wide variety of
methods that did not work well either.

Right now I am writing a multithreaded test case and I have the basic
structure written. I hope to finish it tonight so that I can do extensive
testing in the morning... I'll keep you posted."

Kyle Edwards · February 24th, 2005, 08:26 PM

<<<-- Originally posted by Obin Olson : www.dv3productions.com/pub/dog.tif

works fine for me.... -->>>

maybe it wasn't finished uploading when you posted, coming in now.

Mark Nicholson · February 24th, 2005, 11:10 PM

I imagine that's going to look pretty amazing when it's fully working and the dead pixels have been taken care of. They say that S16 7212 has the same resolution, but I don't know, I've seen a lot of the 7218 printed and it doesn't appear to have nearly the resolution of this camera. I cant imagine how great those Zeiss primes will look on this monster. Actually now I'm really wondering how this would compare to 2-perf 35mm.

Great job. Can't wait to see more samples

Eric Gorski · February 25th, 2005, 01:10 AM

that really looks like scanned 35mm slide film. so exciting.

Kyle Granger · February 25th, 2005, 05:41 AM

>> "I am using a commercial routine written in assembler

Very Cool!

> If you guys can barely squeeze the data into RAIDs,

Florin, my system is 3-4 years old, and relatively underpowered for such an application, so I would not consider my results as a typical data point.

Jason and I have spent many emails trying to figure out the source of my bottleneck, and it is looking like the RAID controller is guilty. At 3ware's website, the docs on the 8006-2 do not mention onboard memory nor a cache, so I must assume there is none. That could explain the behaviour. It could also just be an inherent system-limit of the Precision 530. The synergistic interaction of all the components makes profiling difficult to find the exact cause. Or maybe I'm just not smart enough. ;-)

BTW, CPU usage stays below 25%, even while the writing is falling behind by about 8MB/sec.

For me right now, a Broadcom BC4452 is a little pricey, but the Promise SX4 has 64MB to 256MB onboard memory (user may add SIMM), and may work at 66MHz in a PCI-X slot (though the board is 32 bits).

Obin: VB is Visual Basic?

Audio Note:

BTW, my solution for sound is an old portable Sony DAT. I can download the sound digitally as a post-process. I have also tried MiniDisk, and it also works, although at 44.1, and with some compression.

I do use a clapper board. ;-)

To mask the computer noise, I just keep the box far away. I have made a master cable with mouse, keyboard, VGA, and two ethernet cables to run the computer "remotely", up to 20 meters away. I use a light 17" LCD screen as a viewfinder.

Wayne Morellini · February 25th, 2005, 05:58 AM

<<<-- Originally posted by Florin Popescu :
..
> available. tested it at about 25MB/s sustained write (that's DV speed ain't it). But say I get myself an even faster laptop with two HDDs and interleave/save. Back to that 2 number.

Mini DV is 25 megabits so your far ahead of DV.

> manage to squeeze 24fps1080p down to 50MBs (usb speed) and not overload cpu. At best, after lots of time spent scratching my facial stubble.

You can get that on 8 bit, 10 bit is going to be more. Most of these USB cameras send a pixel over 8 bits in two bytes, and they also burst out the screen, so even 8 bit 1080 24fps will not fit. From testing the highest format to use with USB 2.0 (that is not pixel packed or compressed, or buffered) is 720p. Because USB2.0 tends to lack good data support the processor has o pickup the slack, and Windows is not the most reliable beast for keeping good timing to pickup data (it usually has to be programmed around). The Gige cameras are much better, as at least the SI ones have a buffer and do pixel packing to make effective use of the bandwidth.

>In light of 3CCD 50MBs Panasonic coming out... well...

50M Bytes a second is going to be far ahead of 50M bits per second.
..

>Seems easier than getting getting that extra 10% out of the drive. And if you have to NLE or whatever, what's the use of a 100MB stream anyway?

People not getting the last 10% is probably what has caused so many 50%+ performance hits in PC's, the 10%'s accumulate. Best to isolate and squeeze really tight, do everything else and then attach a higher res/fps camera ;)

If you want to save money the price of the camera head (and software) is going to be the biggest saving factor. Currently I am testing a sensor here, while the results aren't anywhere near what I hoped, I think it could be far better than the Micron 1300, but very difficult to test the unit I got.

Theoretically, a Micron 1300, camera head might be had for $450, with buffer and Firewire. But the sensor has a few problems, that can be avoided with controlled lighting. Obin will testify that it is not the best to shoot with. But this is old technology so an even cheaper sensor of the same quality could be had for less. If you manufactured you could even come to a reasonable $100 price point.

Rob Scott is attempting cheap software, Obin is doing his.

The cheapest is, Cineralla for Linux, editing and capture (don't know about the capture).

The problem here is that there are multiple camera projects (not including others not mentioned here), and unless your a programmer (with all that realistic knowledge that they have) you shouldn't attempt one (and if you wanted to manufacture you should be an engineer too). So the little market here will soon be flooded, and you have to consider going further abroad. But as a hobby, why not.

Good luck.

Wayne.

Wayne Morellini · February 25th, 2005, 06:21 AM

<<<-- Originally posted by Rai Orz : edit:
Who would buy a camerahead with Altasens ProCamHD 3560 (1920 x 1080p, 12 Bit):

1.) with FireWire 1394b (800) max. 30fps (at 12Bit)

or

2.) Additional with build in double removable HDD disk frame to record direct full 12Bit RAW data up to 30fps on 2 x 2.5" HDDs. (In this case Firewire is only for prewiev and setup)

or

3.) max 60fps. Same as 2, but with 2 x build in double removable HDD disks to record direct up to 60fps on 4 x 2.5" HDDs.

Who are interested ?
And what would be your bid? -->>>

I would buy any of these, at a cheap price. The thing is that cameras here, and in the MV market place, are standardising on Gige (and after, maybe, GigaE) , so a dual interface camera with Firewire 800 ( and after 1600/3200) would be good for standard video market too.

1. I would say less than the price that Sumix is promising for their compressed, buffered, pixel packed Altasens).

2. $200-$300 extra (not including HDD's of course). That is the base price of a Linux PC now days.

3. About $300 extra over the 1. pruce (not including HDD's of course) but you'll probably sell a lot more.

As to where ever I will buy, I am still reserving my judgement until after I see the Sumix product.

So I would say, go with 1, but undercut Sumix greatly, drop 2, and put number 3 out just above Sumix price.

By the time your ready I would say that the Altasens price might drop even further.

Rolling shutter VS Global and Superfast lenses.

Now all this talk of squashing the Rolling shutter bug on the Altasens here/ If it can be done with no picture performance impact, I would say, yes, I prefer it over the present global shutter options. But then we get to the other point of no being able to take super fast lenses, how much restriction in their, and what about the 4/3 format that gets around this problem in the lens design itself, by seemingly artificially, narrowing the convergence angle of the light sent to the sensor. Can a simple adaptor segment be put between the Altasens and the lens to do the same?

Thanks Rai.

Wayne.

Kyle Granger · February 25th, 2005, 07:16 AM

Rolling Shutter Metric

We may need some common language to talk about rolling shutter artifacts. I have one modest proposal...

The artifacts are a result of two factors: the horizontal speed of an object in the frame, and the scanning time for the image. Here is an idea.

SWMS: Screen Width Milliseconds. This is how fast it takes an object to move the entire width of the screen.

FPS: Obvious. This is the scantime, expressed as its reciporcal, in frames-per-second, not including vertical blanking.

RSM: Rolling Shutter Metric. The product of these two figures. This is applied to an image sequence. AFAICT, the artifacts should be independent of the playback rate.

So, if your scantime is 60 fps, and the object moves across the screen in a half second, the RSM is 30000 (500*60). If you double the speed of your object (SWMS = 250), but also double your scanrate (120 fps), the artifacts should be the same. And the RSM is the same (30000).

So, an RSM or 30000 may be acceptable. But 11000 is maybe not accpectable.

Rolling shutter cannot ever be eliminated. Either it is there, or it isn't. But at what point is it visible and at what point is it acceptable?

Obin Olson · February 25th, 2005, 07:26 AM

I have never done much with film but this really blows me away with the "filmic" look it has with the soft tones and all

Jason Rodriguez · February 25th, 2005, 07:51 AM

Hey Kyle,

I like the Rolling Shutter Metric guide.

BTW, we do need to test and see just "how bad" rolling shutter really is, especially when we have the vertical blanking set really high, which means the clock on the chip is running at the equivalent of maybe 60fps, but we're only ouputting 48fps (and then dropping a frame for 24fps).

So Kyle, when you say FPS, but ignoring the vertical blanking, are you saying the fps that you'd be running if there was no veritcal blanking, or the fps after vertical blanking. I.e., you'd be at 60fps without vertical blanking, but you're at 48fps after vertical blanking. Do you use the 60fps in the RSM calculation, or the 48fps?

Overall, great idea!

February 24th, 2005, 05:48 PM	#2552
Florin Popescu New Boot Join Date: Feb 2005 Location: Berlin, Germany Posts: 5	Kyle and Obin, If you guys can barely squeeze the data into RAIDs, how am I ever going to make into notebook hdds. Here's how.. As the data is scanned sequentially from the chip, a histogram of pixel or pixel differential is compiled for each frame, and when it's flushed from the buffer onto disk, it gets huffman coded. Variations thereabouts. A simple scheme requiring very few computational resources, time or memory... much less than jpg. Not deterministic, sure, but you can't shoot uniform random noise over whole dynamic range even if you tried. Do you guys really write RAW data? This type of lossless compression seems to get compression ratios of at least 2 (with everyone's favorite huffman coder). Seems easier than getting getting that extra 10% out of the drive. And if you have to NLE or whatever, what's the use of a 100MB stream anyway? __________________ Dr. Florin Popescu Fraunhofer FIRST, Berlin

February 24th, 2005, 11:10 PM	#2558
Mark Nicholson Regular Crew Join Date: Oct 2002 Location: Eldorado Hills CA Posts: 68	I imagine that's going to look pretty amazing when it's fully working and the dead pixels have been taken care of. They say that S16 7212 has the same resolution, but I don't know, I've seen a lot of the 7218 printed and it doesn't appear to have nearly the resolution of this camera. I cant imagine how great those Zeiss primes will look on this monster. Actually now I'm really wondering how this would compare to 2-perf 35mm. Great job. Can't wait to see more samples __________________ Sacramento http://eyepatchfilms.com 2x HD-250, BR-HD50, Media Composer

February 24th, 2005, 05:31 PM	#2551
Kyle Granger Regular Crew Join Date: Feb 2005 Location: . Posts: 52	Obin, I have been normally using 48 and 50 FPS with the SI-1300 and SI-3000. It is possible to instruct the grabber to drop every other frame (or x frames), so you receive 24 or 25 (or have timelapse). (you probably know this) It is also possible to increase the clock rate, and increase the number of lines in the vertical blanking period, and still maintain the desired framerate. This further reduces artifacts from rolling shutter, since the time per scanline is reduced. Caveat: there is a limit to the number of lines in the VB interval, though I can't say off the top of my head what that is. You might, for instance, have to run the camera at a 58.45 fps rate (with normal VB), add the additional (max) VB lines, set your skip to one, and then receive your 24.0000 or 23.9760 frames per second. I know I am basically repeating what Steve said.

February 24th, 2005, 07:05 PM	#2553
Juan M. M. Fiebelkorn Major Player Join Date: Jun 2004 Location: Buenos Aires , Argentina Posts: 444	LOL hahaha, do you really believe what you are saying? you are getting something like 94 Mbytes/s. so you wanna huffman compress it to record it onto a Laptop 2.5 inch drive??? like what? a 2.5 inch 10K RPM one? So your huffman will compress like 3:1 sustained or even more? I'm not getting your point, really.not trying to be offensive... Edit:Now that I see you are Dr. and Fraunhofer guy.Why don't you just make some kind of lossy codec for it, keeping at least 10 bit bitdepth. You could even modify Xvid or simillar to accept 10 bit and compress the bayer. May be even better avoid huffman and use a range encoder!!

February 24th, 2005, 07:55 PM	#2554
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	we are using VB indeed it works well for what it is...as far as the save stuff I think that is exactly what we are doing ;) and thanks for the info! I did pass it on to our programmer just incase

February 24th, 2005, 07:59 PM	#2555
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	www.dv3productions.com/pub/dog.tif works fine for me.... Wow how gamma can help with the exposure of th image while shooting! I have been playing around with it with CineLink...looks like we will still need a way to show histogram? or maybe zebra... also i want to have a button that allows one to 'zoom in' on a live image for focus ..this will help lots... I got a chance to hook up the touch screen monitor today an d 'playshoot' with no recording(as it's not working yet) ...touch screen is VERY good and EASY to use! bad thing is the screen has a weird tint to it with the touch surface...I don't like that...anyone seen a VGA splitter so that we could have a nice clear screen to frame with?

February 24th, 2005, 08:15 PM	#2556
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	"I am using a commercial routine written in assembler to write to disk. I have tried both the asynchronous version (Overlapped) of CreateFile with WriteFile and fOpen, etc... and that are an order of magnitude slower than the routine I use. I also tried copying memory to disk and a wide variety of methods that did not work well either. Right now I am writing a multithreaded test case and I have the basic structure written. I hope to finish it tonight so that I can do extensive testing in the morning... I'll keep you posted."

February 24th, 2005, 08:26 PM	#2557
Kyle Edwards Major Player Join Date: Nov 2004 Location: LI, NY Posts: 274	<<<-- Originally posted by Obin Olson : www.dv3productions.com/pub/dog.tif works fine for me.... -->>> maybe it wasn't finished uploading when you posted, coming in now.

February 25th, 2005, 01:10 AM	#2559
Eric Gorski Regular Crew Join Date: Jun 2004 Location: Western Oregon Posts: 138	that really looks like scanned 35mm slide film. so exciting.

February 25th, 2005, 05:41 AM	#2560
Kyle Granger Regular Crew Join Date: Feb 2005 Location: . Posts: 52	>> "I am using a commercial routine written in assembler Very Cool! > If you guys can barely squeeze the data into RAIDs, Florin, my system is 3-4 years old, and relatively underpowered for such an application, so I would not consider my results as a typical data point. Jason and I have spent many emails trying to figure out the source of my bottleneck, and it is looking like the RAID controller is guilty. At 3ware's website, the docs on the 8006-2 do not mention onboard memory nor a cache, so I must assume there is none. That could explain the behaviour. It could also just be an inherent system-limit of the Precision 530. The synergistic interaction of all the components makes profiling difficult to find the exact cause. Or maybe I'm just not smart enough. ;-) BTW, CPU usage stays below 25%, even while the writing is falling behind by about 8MB/sec. For me right now, a Broadcom BC4452 is a little pricey, but the Promise SX4 has 64MB to 256MB onboard memory (user may add SIMM), and may work at 66MHz in a PCI-X slot (though the board is 32 bits). Obin: VB is Visual Basic? Audio Note: BTW, my solution for sound is an old portable Sony DAT. I can download the sound digitally as a post-process. I have also tried MiniDisk, and it also works, although at 44.1, and with some compression. I do use a clapper board. ;-) To mask the computer noise, I just keep the box far away. I have made a master cable with mouse, keyboard, VGA, and two ethernet cables to run the computer "remotely", up to 20 meters away. I use a light 17" LCD screen as a viewfinder.

February 25th, 2005, 05:58 AM	#2561
Wayne Morellini Inner Circle Join Date: May 2003 Location: Australia Posts: 2,762	<<<-- Originally posted by Florin Popescu : .. > available. tested it at about 25MB/s sustained write (that's DV speed ain't it). But say I get myself an even faster laptop with two HDDs and interleave/save. Back to that 2 number. Mini DV is 25 megabits so your far ahead of DV. > manage to squeeze 24fps1080p down to 50MBs (usb speed) and not overload cpu. At best, after lots of time spent scratching my facial stubble. You can get that on 8 bit, 10 bit is going to be more. Most of these USB cameras send a pixel over 8 bits in two bytes, and they also burst out the screen, so even 8 bit 1080 24fps will not fit. From testing the highest format to use with USB 2.0 (that is not pixel packed or compressed, or buffered) is 720p. Because USB2.0 tends to lack good data support the processor has o pickup the slack, and Windows is not the most reliable beast for keeping good timing to pickup data (it usually has to be programmed around). The Gige cameras are much better, as at least the SI ones have a buffer and do pixel packing to make effective use of the bandwidth. >In light of 3CCD 50MBs Panasonic coming out... well... 50M Bytes a second is going to be far ahead of 50M bits per second. .. >Seems easier than getting getting that extra 10% out of the drive. And if you have to NLE or whatever, what's the use of a 100MB stream anyway? People not getting the last 10% is probably what has caused so many 50%+ performance hits in PC's, the 10%'s accumulate. Best to isolate and squeeze really tight, do everything else and then attach a higher res/fps camera ;) If you want to save money the price of the camera head (and software) is going to be the biggest saving factor. Currently I am testing a sensor here, while the results aren't anywhere near what I hoped, I think it could be far better than the Micron 1300, but very difficult to test the unit I got. Theoretically, a Micron 1300, camera head might be had for $450, with buffer and Firewire. But the sensor has a few problems, that can be avoided with controlled lighting. Obin will testify that it is not the best to shoot with. But this is old technology so an even cheaper sensor of the same quality could be had for less. If you manufactured you could even come to a reasonable $100 price point. Rob Scott is attempting cheap software, Obin is doing his. The cheapest is, Cineralla for Linux, editing and capture (don't know about the capture). The problem here is that there are multiple camera projects (not including others not mentioned here), and unless your a programmer (with all that realistic knowledge that they have) you shouldn't attempt one (and if you wanted to manufacture you should be an engineer too). So the little market here will soon be flooded, and you have to consider going further abroad. But as a hobby, why not. Good luck. Wayne.

February 25th, 2005, 06:21 AM	#2562
Wayne Morellini Inner Circle Join Date: May 2003 Location: Australia Posts: 2,762	<<<-- Originally posted by Rai Orz : edit: Who would buy a camerahead with Altasens ProCamHD 3560 (1920 x 1080p, 12 Bit): 1.) with FireWire 1394b (800) max. 30fps (at 12Bit) or 2.) Additional with build in double removable HDD disk frame to record direct full 12Bit RAW data up to 30fps on 2 x 2.5" HDDs. (In this case Firewire is only for prewiev and setup) or 3.) max 60fps. Same as 2, but with 2 x build in double removable HDD disks to record direct up to 60fps on 4 x 2.5" HDDs. Who are interested ? And what would be your bid? -->>> I would buy any of these, at a cheap price. The thing is that cameras here, and in the MV market place, are standardising on Gige (and after, maybe, GigaE) , so a dual interface camera with Firewire 800 ( and after 1600/3200) would be good for standard video market too. 1. I would say less than the price that Sumix is promising for their compressed, buffered, pixel packed Altasens). 2. $200-$300 extra (not including HDD's of course). That is the base price of a Linux PC now days. 3. About $300 extra over the 1. pruce (not including HDD's of course) but you'll probably sell a lot more. As to where ever I will buy, I am still reserving my judgement until after I see the Sumix product. So I would say, go with 1, but undercut Sumix greatly, drop 2, and put number 3 out just above Sumix price. By the time your ready I would say that the Altasens price might drop even further. Rolling shutter VS Global and Superfast lenses. Now all this talk of squashing the Rolling shutter bug on the Altasens here/ If it can be done with no picture performance impact, I would say, yes, I prefer it over the present global shutter options. But then we get to the other point of no being able to take super fast lenses, how much restriction in their, and what about the 4/3 format that gets around this problem in the lens design itself, by seemingly artificially, narrowing the convergence angle of the light sent to the sensor. Can a simple adaptor segment be put between the Altasens and the lens to do the same? Thanks Rai. Wayne.

February 25th, 2005, 07:16 AM	#2563
Kyle Granger Regular Crew Join Date: Feb 2005 Location: . Posts: 52	Rolling Shutter Metric We may need some common language to talk about rolling shutter artifacts. I have one modest proposal... The artifacts are a result of two factors: the horizontal speed of an object in the frame, and the scanning time for the image. Here is an idea. SWMS: Screen Width Milliseconds. This is how fast it takes an object to move the entire width of the screen. FPS: Obvious. This is the scantime, expressed as its reciporcal, in frames-per-second, not including vertical blanking. RSM: Rolling Shutter Metric. The product of these two figures. This is applied to an image sequence. AFAICT, the artifacts should be independent of the playback rate. So, if your scantime is 60 fps, and the object moves across the screen in a half second, the RSM is 30000 (500*60). If you double the speed of your object (SWMS = 250), but also double your scanrate (120 fps), the artifacts should be the same. And the RSM is the same (30000). So, an RSM or 30000 may be acceptable. But 11000 is maybe not accpectable. Rolling shutter cannot ever be eliminated. Either it is there, or it isn't. But at what point is it visible and at what point is it acceptable?

February 25th, 2005, 07:26 AM	#2564
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	I have never done much with film but this really blows me away with the "filmic" look it has with the soft tones and all

February 25th, 2005, 07:51 AM	#2565
Jason Rodriguez Trustee Join Date: Mar 2003 Location: Virginia Beach, VA Posts: 1,095	Hey Kyle, I like the Rolling Shutter Metric guide. BTW, we do need to test and see just "how bad" rolling shutter really is, especially when we have the vertical blanking set really high, which means the clock on the chip is running at the equivalent of maybe 60fps, but we're only ouputting 48fps (and then dropping a frame for 24fps). So Kyle, when you say FPS, but ignoring the vertical blanking, are you saying the fps that you'd be running if there was no veritcal blanking, or the fps after vertical blanking. I.e., you'd be at 60fps without vertical blanking, but you're at 48fps after vertical blanking. Do you use the 60fps in the RSM calculation, or the 48fps? Overall, great idea!