4:4:4 10bit single CMOS HD project

[Kyle Granger]

> ...I can crank it up as far as I want and still get frames

Yes, I know what you are saying.

There is a limit for the camera, though. The noise etc. in the pixels at some point become unusable, the CMOS pixels don't reset fast enough. I think you are already close to the limit at 65 MHz

The Epix card probably maxes out at 85 MHz.

> I thought the Epix did not have a buffer,

Yeah, I think Wayne is right here. If you're on a 64/bit/64MHz PCI slot, then burstiness is not an issue (528MB/sec max bandwidth).

misc. note:
With the GigelLink, I have a maximum bandwidth of about 120MB/sec (the limit of gigabit Ethernet). But there is a 16MB buffer, so the burstiness can be smoothed out.

With the SI-1300, I also run the clock high, and add lots of vertical blanking, all with the aim of reducing rolling shutter. But often with a resolution of 1280x692.

[Wayne Morellini]

Kyle (a good chunk of this is for other people readers to read, thus some of the explanation)

Because they are trying to file so close to the limit of the drives, burstiness on the drive save canbe a problem, inducing misses and waiting to re-access the track. But as they are already getting 80MB/s out of a maximum of 140MB/s it may not be such a problem in their system.

But like traffic on a freeway, a little bit of a problem can ripple through and cause greater problems somewhere else (how many control points some of these programmers must use, must be staggering). But simply dumping the information from the control points to the display can upset everything, so best to build a log data structure in memory, oner page at a time (kept in cache). But ti shouldn't be that drastic here. Obin, just realise that even testing can effect your results, so have a version without it to compare if things look a bit strange.

I think burstiness of memory access can also have an affect. Let's assume that the driver writer isn't experienced and the driver is writing out data in dribs and drabs or some other non optimised size. That would (on a system like this with high memory traffic from competing parallel sources) stuff competing processes memory access. Memory is optimised for writing memory in chunks, and the Rambus memory, on various Intel boards, much more so. So it is best to write at least a memory page at a time, and probably bigger (the details are not in my head at the moment). If they write smaller than a page, the setup overhead for the write access goes up, writing a few words of memory at a time, can make it go through the roof (never to be seen again sort of hight) as other processes can steal memory away to access a separate page. Writing a string of pages at a time would reduce the overhead a little more. Now lets hypothetically think that the driver writer does not block other processes from stealing memory control away during page writes. So now you have odd sized writes competing with each other, with massive overheads.

Running a program from main memory instead of cache, is many times slower. Having a loop that crosses the page boundary produces overhead. This is why I say keep the code in the cache and leave main memory for the card, chipset, graphics and disk to manage among themselves (not forgetting that you need to pack and preview from it too). Because these devices should be programmed to write in optimised chunks, this will reduce overheads in main memory. You have three processes putting in and out of memory in parallel at one time. Although the data-rate might be a fraction (under 600MB/s) of the available to main memory, having memory conflicts will add significant overheads. There is enough room for many of these things to be done in parallel, in the background, and hardly effect the processor load. The trick is controlling and keeping the processor out of the way (working around each other).

Now all this can lead to burstiness in memory, that will translate to burstiness in execution and drive writes.

[Leon Nox]

hi i have been asking a lot of cmos and most of them told me that i have to use a camera link interface (it seems that there is just one cameralink interface for laptop , but anyway there are no so fast hard disk to write on...so i cannot use a laptop)...i think that the tranfer rate for 1920*1080@25 10 bit is about 192MB/s isn't it?...so i started to look for a mini-micro motherboard ...and i found some of them really interesting ...the real problem is where to record...if i use a sta sata i've got 150MB/s ,but this is just the optimal...so i should implement a raid configuration with at least 4 SATA to reach 200MB/s...but in this way i have to take with myself...thimk about the weight and the volume...any suggestion?

[Kyle Granger]

1920x1080 @ 24p, 12-bit = 72MB/sec
@25p = 75MB/sec

[Kyle Granger]

Leon,

I record 1920x1080 24p with no problems, with 2-port 3ware RAID 8006 controller, and two Maxtor SATA drives. My max bandwidth is 114MB/sec

[Konstantin Serafimov]

Leon may be I can explain this,

the mistake is coming from assumtion that from sensor 10*10
we getting 100 rgb pixels (as in uncompressed image).
but
a color sensor is an array of color pixels of one of 3 colors each, not of rgb, and this is called raw data.
so your calculation is 1920*1080*25(fps)*30(10*3bit)
kyle calculation is 1920*1080*24(fps)*12(bit)

i hope i havent made mistakes here :)

[Wayne Morellini]

Leon,

Have a look over at my Technical thread I am sure I have posted a link to latest Laptop drives, or benchmarks of drives.

You will notice that fastest is around 20MB+/s min (or was that 34MB+/S). There is (apparently) also laptops with room for two internal drives (not including external).

So you can run 720p single chip (Bayer pattern, Konstantin talked about). If laptop is very fast to compress than you can do more than 720p on single drive.

What you must also realise is that drives run faster on the outer track of the drive than the inner track. So you should look for the minimum data rate that it will record. All the recording capture product will also only work on selected target computers at first, latter may work on many different computers (very hard to get it to do).

Laptops are now available with Express card, that supports upto 250MB/s each way (250MB/S read 250MB/S write simultaneous). Problem with many capture cards, no frame memory buffer, do not even out data to frame per second, but bursty, and many chips, if you want higher shutter speed, you get higher data rate. So 132MB/s struggles, but 250MB/S much better. So ask if Camera link Express Card will be available. Other good option is get a buffered Gigabit Ethernet camera (Just enough for 1080p, but compressed better). They do not normally "pack" pixels, so any pixel above 8bits, is sent as 16bit+ (more bandwidth). If you want 720p with over 8 bits than Firewire (maybe USB2.0, but USB2.0 canbe CPU hog) might do.

Apart from capture software, and fast enough, and correct, hardware, these are the issues.

Thanks

Wayne.

[Jonathon Landell]

So Obin, what's cooking? Any progress?
Just curious. :)
-Jonathon

[Obin Olson]

sorry gang for the "away" I have been in pre-production for a project and will lens it Sunday..not been doing much camera work(but my programmer is and tells me we are making some good progress) I post more next week as I will have a bit of free time!


gota go make the cash that keeps the R/D machine going! can't blame me on that can you! :)

[Obin Olson]

I am told today that we have enough CPU and memory speed to do what needs to be done in the amount of time we have. THis, after I ran a bunch of tests for my programmer Friday...I will be out all day Sunday on a shoot and report in on Monday....

a toast to our progress!

[Wayne Morellini]

Well, Mike over at http://www.hdforindies.com/ has a lot of interesting information about digital cinema it's raw formats and JP2K compression.

Competitive analysis:
(This just turned up)

JVC has released it's new HD camera, which is good news for us (though I would keep price down):
http://www.camcorderinfo.com/content...00U-24P-HD.htm

$6K+, 1/3" 3 chip, MinDV, optional module to take uncompressed signal to HDSDI, 720/60p. Nice package (the Panasonic does not look as nice and has 1440*1080 mode) professional features, but once you go raw it is going to cost a pretty more penny than it presently does. They will sell to video people, but our product should be clearly superior for Indies. But I think this is a Milk Cow to get money in. This means that it may have the latitude to drop half in price in the future (the uncompressed recording canbe also cheaply worked out) if the competition demands it. So we might have to compete with a $5K, uncompressed to disk, name brand, pro ENG like camera system that would probably give at least the image quality of the Micron 1.3MP with none of it's faults, in the future. But video people like already worked out name brand products.

So, for the moment, good news for us.

Wayne.

[Régine Weinberg]

so as Pana and Jvc are out and Sony who ever knows
so as there a rumours that Pana will also record on a harddrive and even Juan is on the show...so
why should we spend $$ to build a single Cmos cam
a cynic one

Ronald has been for month's away sailing
on a 17m wooden gaffer from 1908 a restored
Norwagian fishing boat. That was for real
and no electronics beside radar and radio

[Wayne Morellini]

Ronald, we expected to hear from you months ago.

The JVC/PANA is expensive pieces of .., for Cine shooting, fine for videoing and Wedding market, will sell. Now the bottom line of what we are doing is less for more quality. Add an HD-SDI card, computer and software (or Linux stuff) to the JVC/Pana and watch the price go up. There is still a question as to the actual resolution of the Pana (which looks less than true 1080, and the Pana HD tape codec had even less and I am yet to here what format this camera will have). So would I bet Obin's or Sumix's Altasens ($3K) single chip camera should be able to beat this, yes? I have not seen output of this camera yet, but believe it would be better than the Sony HDV, but still not compared to the Altasens.

[Wayne Morellini]

Get this, I hear the JVC Altasens camera shown at NAB last year, will be delayed until NAB next year. So what is this, more Altasens delays (Obin has one, but this is small volume for developers, but where is mass volume)? Maybe they are waiting for cheaper/better sensor next year. They do 1/3rd inch semi pro camera (I like, but the price) not the normal low end 1/2 inch ENG camera (I love). We need Cine camera enclosure like JVC HD100 in features/style. These are latter generation HD chips so we can expect that they will have good picture for sensor size. Sensor size is not the complete picture on performance, technology and refinement increase performance closer to old bigger sensor. On cheap camera we also see dumbed down performance (look at the quality Juan's "Film Stream" compared to original DVX100 1/3). I also work on adaptor to make little sensor increase performance, SN ratio is the only thing I cannot solve. I think maybe Foveon X3 sensor camera (in extra wide cine window).

I hear Altasens from Sumix sooner, and then latter :(

Problems with sensors is, technology spread. Fillfactory have some useful features, Altasens has other useful features, Smal has others, x3 has others, but none has all. So each has own compromises affecting performance. Fill now has Smal, Altasens and X3 are the main ones I know, if only one would buy out another we would have one or two good sensors.
----------------------------------------------------------
Just announcing new Pope on TV, Joseph Ratzinger (we had better be nice to Rai and Ronald now ;) ).

[Régine Weinberg]

I do wonder what type of imager is working in the Pan wondercam. The Arri will have a custom 6M from fillfactory