4:4:4 10bit single CMOS HD project

[Obin Olson]

yes Steve N. has told me that you must have RGB set before you shoot for the most range from the chip

[Wayne Morellini]

Kyle: Please list your metric on a post when you are finished, all the discussion of new short forms of terms is a bit confusing.

.net:
Yes, I believe they licensed parts of the core of the real-time embedded OS "Tron" for his, so it should be a lot better.


For all developers:
I don't know the way your development systems are set up, but apart from the GPU programming, there are real-time embedded extensions/development systems for Windows. Also MS has released a cross platform game development system called XNA (I think) that should get very efficient handling of graphics etc.

Jason:
I am testing a dual slope sort of scheme here at the moment. I am not fully happy with it (I am only using a small fully auto camera, with one of the smallest lens I have seen) but it is impressive on outside shoots. The example in the Fillfactory site could do with a bit more adjustment to bring the external colors up.

http://www.fillfactory.com/htm/techn...dual-slope.htm

Barend:
So how many bits should we devote to overbrights in adjustments?

[Jason Rodriguez]

Wayne, just look at the Cineon spec for the overbright stuff.

Or again, just look at what I said for the linear 12-bit space. You need to place 100% white around the 700 mark out of 4095. You can calculate how many bits that is.

Now white clip is 2.5 stops above middle grey, and we're adding another 2.7 stops in over-exposure dynamic range or "super-white, thus giving you around 5.2 stops of dynamic range above middle grey. Which is quite a bit, considering that there's another 5 stops below middle grey at this point (typically). So that's a little over 10-stops total, which again, is a very nice dynamic range to work with, very close to film's 12-stops (but you can preview the dynamic range on the screen, so you can get spot-on, you don't need to "guess" in any way, or need those extra two-stops for movement. A good DP doesn't "guess", but he only has around 10-stops of effectivive lattitude typically because he does need some wiggle room on either side, hence those extra two stops. But in digital, you really don't need the wiggle room as much since you can see exactly what you're doing).

[Wayne Morellini]

Thanks.

[Kyle Granger]

We can define the RSM (Roling Shutter Metric) for a particular shot, or image sequence within a shot, or object within a shot, as the ratio of the image width to the pixel skew.

E.g., if you are panning acrocss a vertical door, and the difference between the horizontal position of the bottom and top of the door is 24 pixels, then the RSM for the door (or entire shot) is 1920/24 or 80. You also need to measure the delta in a still shot, since the vertical may not be exact. As Steve pointed out, this is the image skew.

[ We can also define the horizontal speed of an object as Screen Width Milliseconds (SWMS -- how many seconds it takes for an object to move the full screen width), and the Rolling Shutter Scantime (RSST -- number of active lines divided by total lines per second, times 1000 (scantime in ms)). SWMS/RSST is then equivalent to RSM above. I believe all we only need the one metric. We can safely ignore these two. Less is more. ]

Wayne: is your camera global shutter IBIS-5? 40Mhz clock? I looked at something like that last summer.

Log color space: I, too, am coming up to speed with the deep knowledge Jason et al. is sharing about non-clipping of highlights, etc. In the meantime I have been writing 16-bit files. I chose the SGI RGB file format, as opposed to TIFF, just because for me, it was much simpler. The specification and PS plug-in are easy to find., for thems that want it.

GPU efficiency, XNA: I have never found graphics to be problem. For grabbing and preview (on my system), CPU usage is never above 8% for 40MHz clock (3300 and 1300); faster clocks it is a little more. Using very basic OpenGL calls. ( I have written 3D games with DirectX 9, but I prefer OpenGL. )

[Wayne Morellini]

No, older camera with smalcamera sensor in it (also owned by Cypress now) that I found on clearance locally.

Faults:
I have seen blooming only sometimes, and not very severe) it is irregular and might be the auto function messing up the autobrite (there per pixel dual-slope type mode). I have seen strobing only in shoots in the most extreme contrast conditions (again maybe the auto functions pushing too far).

Low Light:
Low light is a mess because of the extremely small lens requiring too much gain and slow shutter (that lens is only a mm or two across). I think that a normal lens aperture would make low light a non issue, but this will require an iris for daylight work (ie: normal lens).

Improvements:
A normal lens, manual control of gain and autobrite, and 12bit raw images should get rid of the few blowout situations I have seen (the thing only downloads compressed Jpeg versions at the moment, that stuffs up what I'm seeing, I am not used to reading Jpeg codec artifacts). I don't know if it is the ex-small lens, Jpeg or the sensor producing some things I'm seeing. At the moment I think the blowout is equivalent to the 1300 or 3300 with camera as is. My guess this is because of the autobrite and that it is tuned to daylight use.

Perforamnce:
Outside the range should be able to match the human eye (going on the marketing of the autobrite) but I can tell it is down a bit (I don't know how to read how much) my guess is that with a proper lens it will still be a couple of stops less+ than human vision which is good enough). So I would say it can match the range of the Micron cameras (with less problems that the 1300). But this is a stretch, I would like to find out more before confirming this. Having said all this, the shoots outside appear very close to what I see, when exposed for the lit image. Highlights look natural, and close to reality. Contrasty situations, with subjects in the shade and under the trees look a couple of stops darker in the shade, or brighter on the outside (guessing from memory on that one) and have seen blowout is such scene. This sensor is a few years old.

Dualslope/Autobrite:
The situation with the autobrite is closer to the IBIS5a example pictures above (more noise in the shadows). We have not consider it's usefulness in outside shooting, just those desaturated windows pictures. I am convinced that our eyes see washout in contrasty scenes, but our minds edit it out, and the pupils adjust for centre of attention. But is camera work everything has to be saturated and not washed out to the viewer (IE this is excellent for doco). How have you found this on the Drake, Rai.

Comparison:
Otherwise I would say that the picture is down a bit, but this is probably because of the small lens and maybe bayer filter quality. The sensor does work like a larger sensor (except, a guess, in noise floor).

Downside:
The bad news, this is a still camera sensor (there are video ones). It has only 27MB/s bandwidth and rolling shutter. So I don't know if that canbe eliminated. But there are newer 3MP versions. This company wants to only deal with larger buyers (hundreds of thousands) so you would have to go through somebody like SI or Sumix to get them to do it. Might be good for cheap camera (this one costs around $74 retail).


I suspect Logitech might use sensors like these in their web cameras, does anybody have logitech web cameras from the last few years, do they have dual-slope type modes?

Again, I don't know enough to say this is good sensor for cheap cinema/doco camera, but there is room for two to three levels of cameras.

[Wayne Morellini]

<<<-- Originally posted by Kyle Granger :
GPU efficiency, XNA: I have never found graphics to be problem. For grabbing and preview (on my system), CPU usage is never above 8% for 40MHz clock (3300 and 1300); faster clocks it is a little more. Using very basic OpenGL calls. ( I have written 3D games with DirectX 9, but I prefer OpenGL. ) -->>>

That seems very low. What processor and hardware are you running?

-----------------------------------------------------------------

FAQ

To all:

A lot of questions get re-asked a lot, maybe we need a FAQ file, or at least a linked list to answers to peoples questions on other sites. There 's Rob's Obsura Cam Wiki, but I am reluctant to put everybody else's projects on his Wiki. I have suggested before about a start page for these threads, that could contain a FAQ link. But maybe we need a FAQ link at the bottom of the view pages that takes us to a list of FAQs, or the FAQ for that thread/forum.

Rob, what do you think, easier than re-writing the forum code to have an adjustable first page?

Thanks

Wayne.

[Kyle Granger]

To all: I am still trying to catch up on most of the older posts, so I apologize in advance if I ask a newbie question.

Wayne: Thanks for the information!

> What processor and hardware are you running?

Dell Precision 530, 1.7 GHz Xeon
NVidia Quadro2 MXR/EX with 32MB, AGP 4x
1 GB RIMM

> 40MHz 3300 clock

15.6 fps at 1920x1080. Only grabbing and preview. But without bilinear interp of Bayer (GPU can do that better): a quick and dirty sum of the 2x2 square. C++, no assembly. The GigeLink packet filtering works well for me: no measurable CPU usage.

1300 smearing: I am only using the monochrome version of the camera, and have so far not found that to be a problem. An artefact of Bayer filter chip?

[ I will go through the posts that mention this. Maybe because I'm an art-film buff, I also tend to like the mono 1300 slightly more than the color 3300. But only *my* opinion. Mono CMOS also has a sensitivity advantage vis a vis Bayer. ]

[Wayne Morellini]

> Dell Precision 530, 1.7 GHz Xeon

That's a single processor board, the performance appears good, but how come only 15.6fps at 8% instead of 30fps at 16%?

>1300 smearing: I am only using the monochrome version of the camera, and have so far not found that to be a problem. An artefact of Bayer filter chip?

I thought it was sensor level? Do you mean you think the Bayer filter is interfering with wide angle light?

Thanks

Wayne.

[Kyle Granger]

> but how come only 15.6fps
15.6 fps is what you get with 40 MHz clock (for testing).
40MP = (1920+390) * (1080+28)*15.6
You'd get, e.g., 24 fps with something like 61 MHz. The VB of 28 lines can also be reduced to 4. HB is 390 clocks on 3300.

> I thought it was sensor level? Do you mean you think the Bayer filter is interfering with wide angle light?

I have no idea. I will read the older posts, and then ask again.

Thanks, sir!

[Obin Olson]

what type of CPU %% are you getting at 65mhz 1080x1920 12bit?

[Kyle Granger]

Obin,

CPU usage with 65 MHz clock on SI-3300 bounces between 18 and 25%, but seems to average around 21%. I get 24.79 fps. The data from the camera is 12-bit packed.

40MHz was bouncing between 4% and 7%. I can't readily explain the big jump in CPU usage, when the framerate increases just by 60%. (AGP 4x, 400MHz FSB, screen at 1280x1024).

When profiling the graphics, you want to make sure that you are not sending unnecessary PAINT events. I have seen my CPU usage double, just by having the Task Manager window partly overlapping the video.

Hope this helps!

[Wayne Morellini]

PC's, unreal.

Anyway, sorry, I got the clock speed confused with the 1.3 mp clock speed. Performance still looks reasonable, what I expected when we started out last year. Do you think we could eventually use VIA processor for the same job?

That lost performance sounds suspect, maybe write to Nvidia, maybe they eventually will patch it.

[Wayne Morellini]

http://www.dvinfo.net/conf/showthrea...333#post280333

[Obin Olson]

Kyle please tell me how you display? what size? what framerate? have you captured frames and displayed video at the same time? if so what cpu% did that take?