4:4:4 10bit single CMOS HD project

[Régine Weinberg]

G\day as everybody know, Kreins is using 16 Toshiba disks like to be found in the I-Pod. It is an IDE array. please go there:
http://www.acnc.com/pdf/JS_IDE_308_316S.pdf

reading allmost at the bottom of the page they are using 16 IDE controller the host are two fibre channels well it's bulky but thats's the way to have the bandwith with IDE disks as the 2.5" from Toshiba is an IDE |Ultra Ata 133. Voila

[Rob Scott]

Obin Olson wrote:
supporting the 1300 I really think it is a waste of your time

I realize the smear is ugly, but I thought it might be acceptable for a low-budget, not-quite-professional project. But then again, since the the smearing affects image quality significantly, the 10-bit depth and lack of compression artifacts don't matter as much. Perhaps an HDV camera would be a better choice at around the same price range. So ... you're probably right.

[Jason Rodriguez]

David,

What framegrabbers are you going to support?

Are there any plans for gigabit ethernet support (Pleora's framegrabber)?

[David Newman]

Jason, these details are still being discussed.

[Rob Lohman]

Thank you for your information David.

Rob: have you seen this smearing in person on your camera? I'm
still a bit surprised by it since it looked so great earlier on (with
Obin's footage).

I forgot, but does the new altasens have a rolling shutter or not?

[Jason Rodriguez]

yes, Altasens is rolling shutter also.

[Rob Scott]

Rob Lohman have you seen this smearing in person on your camera?

Yes, it usually occurs when there is a "hotspot" in the image. You can see an example in my blog -- look to the left of the blue blob and to the left and right of the bottom of the picture frame.

[Aaron Shaw]

Altasens is rolling shutter? That's too bad really.

[Obin Olson]

Ok so it looks to me that 67mhz is enough to keep the rolling shutter problem at bay:

www.dv3productions.com/pub/1080p.mov

[Jason Rodriguez]

Just curious Obin,

How come your footage is so "jumpy"? Is this a result of the high-speed pixel clock, or are you dropping frames. It always seems as though everything is moving so fast and there's no motion blur, which contributes even more to the "jumpy" perception. So just curious what might be cause that, and is this the way it's suppose to look?

[Obin Olson]

It's trying to record at 24fps and can't so it's jumpy and weird...that is the problem we are having at the moment...cpu load sits at 100% all the time when we record. I think this is causing dropped frames. The weird thing is CPU load is 10% with black and white preview @ 24fps 1080x1920 1/4 quad pixel readout!!! our frame size is 2megs a frame @ 8bit that would be about 48MB/sec for twin disk save @24fps it can't be the disk backing up both disk drives run 30MB/sec transfer allday....arrgggg

the above test is to show rolling shutter at 67mhz...not bad i say..I would shoot with that

[Eric Gorski]

are there any cameras that are global shutter? and, er.. isn't progressive scan ideal? or is progressive scan possible on a cmos?? and.. i guess you still have a shutter with progressive scan.. ?? ack.

[Wayne Morellini]

Very good, as long as it is a good alternative to Mpeg2 50Mb/s stream (or was that 36Mb/s) I think this will give everybody some excitment.

From what you said the comrpession for Bayer is ^-4:1 and 3chip 4:4:4 6-10:1, is that right?

How does your codec compare to the Avid codec used in the Ikegema camera, it is something like 145-220Mb/s. Is it true lossless or just megp2 like with about the same editable quality as your cinform codec (but at much bigger daya rates)?

Rob,
The hotspot, can you get rid of it by reducing it just below max pixel value, by reducing the gain or putting it in reverse, or just using ND or iris, or is it a contrast thing with surrounding pixels? My reasoning is that iof it is the top 5% then you can adjust the camera to shoot within the acceptable range to aviod the problem, then stretch out in colourisation proceadure.

Aaron,
The Alasens solves the rolling shutter problem by increasing read out time to around 480th a second, or something like that, that deals with it very well.

Eric,
What we get is progressive images, but the rolling shutter reads out at the same time as it is capturing, so slowly that the top of the image is older than the bottom, producing a slant. The Altaszens speeds this up (as Obin is also trying to do) to reduce the slant, and at 480th or a second if something moves fast enough to produce a descent slant people shopuld have a hard time noticing/tracking ti anyway. So they won't think the camera is drunk ;)

Obin,
I am taking it that adding together the CPU consumption, of the sepearte programs ruinning seperately, adds up to much less than when they are run together. To take a guess, it looks like what you are suffering from might be the two programs competing with each other, maybe or maybe not for the same rewsources, but they somehow interfere with each other enough to stall things (or cause the other program to wait) and drive up CPU loads.

[Marin Tchergarov]

<<<-- Originally posted by Wayne Morellini : Yes that is the SD Indie camera, in these threads we are concentrating on the HD indie camera -->>>

Hi Wayne!

Me think the tread of Juan P. Pertierra is a "must read and copy ideas" tread for everyone here!
I can't call Juan's tread a SD only since the next camera on "surgeon's table" is Canon XL2.
More - his method is applicable to any similar device (ADC pin-outs visible).
More2- "the direct to disk" recording is much beter solution than any mini-micro computers
since you'll miss to deal with OS,drivers,bug**ry chipsets(SIS ;)-my own experience),slow CPU's or fast,
but energy unefficient CPU's...and so on.

The major problem with USB2(his device is USB2) is bandwidth.However I believe Juan will find
a faster solution when needed(for Canon XL2).


Steve Nordhauser,

I was very pleased with your announce of a GigaBit-out cameras in SI future production.
I'm not sure in a existence of a GigaBit-equiped removable HDD's .If they exists - food for thought (Yoda mode :))
If they exists not -may be you can create a small GigaE->SATA (or PATA) adapter? Well...may be I'm totally wrong
about GigaE and HDD's compatibility - the main idea (from Juan's tread) is to use very fast
interface to write directly to removable HDD's...

Just my 2 cents...

There is 2 things more - Camera control and viewfinder ...I don't know...

Marin

[Rob Lohman]

Marin: most people here are following Juan's efforts. I've spoken
to Juan about the way he does direct to disk recording and he
has some FPGA appliance in there. The datarates of the camera's
he is modifying do not come close to the datarates we are
getting, and we also have a more complex interfacing system
I believe. Next to that we don't have any people here thusfar
with a good enough FPGA knowledge to guide us if we go that
way, so for now we are going this way.

Let me make a list of problems with FPGA:

1. it would need cameralink or gigabit ethernet in (Juan gets other kind of signals)

2. it would need firewire 800 out (which Juan's FPGA solution seem to have)

3. we need a viewfinder/monitor out (Juan already has this since it is on the host camera), since there is no host camera

4. we need controls to choose settings (Juan already has this since it is on the host camera), since there is no host camera

5. we would need some form of RAID support either in the FPGA (either make it ourselve or have it builtin) or in the harddisks attached (ie, the Lacie RAID 0 drives??)

So unless someone has some good answers FPGA wise for these
kind of "issues" I don't see this happening for now.

Marin: thanks for your thoughts though and welcome aboard DVInfo.net!