I *should* have 8bit 1080p captures today...I will keep everyone posted

Sorry Steve, I thought they were talking about something else. About the 1300, is there a way to get rid of the smear etc, by not adjusting the gain to high or something? Will there be a new sensor version?

Re: CineForm compressed Bayer
 

<<<-- Originally posted by Wayne Morellini : David you mentioned the cineform visually lossless codec for Bayer with 4:1 compression. I read your normal codec has a range of 6:1-10:1 for visually lossless, what is the range for the bayer codec, can we get to 10:1 reliably with multi generation on bayer? I have worked out that 4:1 bayer 720p is close to a 50Mb/s stream which is close to 10:1 4:4:4 3 chip, which is very useful.-->>>

In our tests, visually lossless Bayer is ranges between 4:1 and 6:1. For 1280x720@24p 10bit that is between 36Mb/s and 56Mb/s (data rates double for 1920x1080p24) which will allows you to record 2-3 hours on a 60MB laptop drive.

We recently put up a quality analysis for our codec here: http://www.cineform.com/technology/quality.htm

We are moving forward to productize the Bayer version of the CineForm codec. And yes we have thought about the various licensing opportunities. However, these developments have been delayed due to the boom in the HDV side of our business (the Sony FX1/Z1 is causing a lot of interest in our technology.) For HDV work our compression technology has been licensed by Adobe and by Sony (announced today). Those two companies have been keeping us very busy. :)

David: is 4:1 - 6:1 compared to the original data stream (ie, 16
bits per color sample) or the packed sample (ie, just the 10 or
12 bits)?

Rob,

4:1 to 6:1 is compared to the raw signal that we compress which is currently 10bits per Bayer element. The compression ratio would seem higher if it were compared to unpacked 16bit (350Mb/s) or slighly higher for packed 12bit (260Mb/s).

As for 12bit vs 10bit issue, which I'm sure will come up; the compression does a 12bit->10bit conversion with a user controllable gamma curve (much a like a good HD camera does from 12/14 to 8bit.) The 10bit data provides an excellent signal of downstream color correction without banding.

a bit on the wild side
 

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

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.

David,

What framegrabbers are you going to support?

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

Jason, these details are still being discussed.

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?

yes, Altasens is rolling shutter also.

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.

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

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

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

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?

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

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.

Re: Re: CineForm compressed Bayer
 

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.

1-st post
 

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

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!

Re: Re: Re: CineForm compressed Bayer
 

I haven't done a lot to try to reduce the smearing, but your idea of reducing the gain is a good one. I'll try it.

Lets thinking on differnt ways.

@Robs FPGA problem list:

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

a.) Why not? But...
b.) Take the next step. Look inside camera heads. Most CMOS Sensors have digital, par. out, so why not connect the CHIP direct to a FPGA. (Okay, if you can do this, you need only a sensor and a few parts, not a camera head form manufactor xxxx)

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

If you can build a FPGA system, it will be easy to build also firewire ports or others. There are lots of chips for this work. But, look at point 5...

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

a) optical viewfinder?
b) second FPGA or PC based system for that job

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

Write software on PC, test it out and translate the ini and control function to a MC.

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??)

Take your brain free from all PC stuffs. The A/D Unit, inside (or outside the CMOS Sensor) have 10, 12 or more output pins (each pin is one BIT). The output rate is 33-66MHz. FPGAs can handle those data speeds in realtime. Shift or translation to 16Bit words are simple works. Next part is the Harddisk. Not a controller or interface, you can write direct to disk. A HDD needs words, not bytes. There are 16Pin (one pin = one byte) and you can connect it also direct to the FPGA or MC.
Also you can split the datas to more than one hdd. (First word to first HDD, second to second...)
But some sensor chip manufactors do the work for you. Most chips (2M pixel, or more) have two, or more output ports. Your FPGA can handle this and you can write to multiple HDD, without software logic. (First chip output go to first HDD, and so on)

Okay, FPGA is a new world. But since i thinking about a 3 chip, 1920x1080 camera, i think its the only way we can do it now. Also there are a lot of people with FGPA know how in special forums.

Regarding FPGAs ... When we discussed this a few months ago, Steve Nordhauser indicated he'd be interested in embedding a FPGA solution inside of the "box" camera. In this case, the FPGA would be connected directly to the sensor and would output a compressed signal, period. Presumably the "box" camera would output Firewire, CameraLink or Gigabit Ethernet, which a separate system would them capture and stored onto hard drives. This "capture" system could be simpler than before, however; for example, a single hard would presumably be enough to store the compressed data stream. (The viewfinder would be a bit more challenging, since it would have to decompress the stream in real-time.)

Eric: Progressive scan is the sequential reading of the image from top to bottom. Interlaced is doing a frame of the odd, then even lines. All the sensors discussed in this forum are progressive. The only global shutter sensors discussed are the IBIS-5A for 720p.

Wayne:
The Altasens can read out at up to 60fps for a full frame, letting you drop every other frame at 24 or 30fps. It is still rolling shutter.

Marin:
We are shipping GigE cameras *now*. 100MB/sec of continuous video in 8 bit, 12 bit packed and 12 bit normailized formats. We haven't seen the need for direct connectivity to a hard drive since you need the camera control, the preview and other features.

Hm
thats not crazy at all, but there is a lot of money involved I do guess. It is exact the way the big ones are thinking and if it would be easy to do this as DIY, Arri or Dalsa would have done this as they are not stupid at all and Dalsa is nothing else as a Philips child, so FGPA knowhow, the chips, emulators, tools all is with Philips. A nice idea but like with all the boyz in the Audio world nice discussions lot off fun, a year or so and then, nothing.
going Pc components is not so sexy at all, but do get the Data in and out at disk is not all and not as easy as it sounds with an FGPA

Well, you know what they say ... if it was easy, everyone would be doing it :-)

What I had thought about is a FPGA camera head outputting to Gigabit Ethernet; this connects to an embedded PC capture body with a single swappable hard drive. The head and capture body could be dockable for a one-piece system. The FPGA would compress the signal to a standard open-source codec such as Dirac (wavelet-based near-lossless).

Of course, this is a pipe dream at the moment, and may never be worth it since the Kinetta camera is already doing similar things.

Re: CineForm compressed Bayer
 

<<<-- Originally posted by 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?-->>>

Yes.

<<<--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)?-->>>

The Avid DNxHD codec is a DCT based solution much like MJPEG. It will have higher bit-rate than the CineForm codec for the same quality. I have not had access to that codec for testing.

<<<-- Originally posted by Rob Lohman : Marin: most
3. we need a viewfinder/monitor out (Juan already has this since it is on the host camera), since there is no host camera
aboard DVInfo.net! -->>>

Rob,

Juan has a vga output on his mod.

The pana lcd gives a "so far from truth" picture since he bypasses the pana processing so he (we ?) need to know the picture look like.

pipe dream ???
 

huh
What Juan does
and somebody wrote here, have a disk to get the frame out of the camera, drive me totally mad.
network storage device, it's bulky but I do guess there are smaller ones, Steves cam with Gig ethernet out or Camaralink to Gig ethernet, and than something like this

GIG Ethernet storage device http://www.iomega.com/na/products/pr...=1100189941751

with the rolling shuter for god's sake take the Vance Cam idea, a mechanical shutter like good old S16 and 35mm days.
for the viewfinder maybe another crazy thing pops up
The Steve Altasens wits an Argus taht's poor mans 35mm

voila found the pipe dream!
http://www.broadcom.com/collateral/pb/91125E-PB01-R.pdf

that's a evaluation board has 2 GIG Ethernet a chip with realtime OS and Hyper transport only to tell you that's a very fast I/O and that could take the data out to a disk controler chip I do guss

http://www.amd.com/us-en/Corporate/V...1^4752,00.html

imagine a very tiny motherboard there something runs to control the cam one PCI slot such a card in from this card to
a, or an disk array sound not so crazy and no FGPA could take the full bandwith.

<<<-- Originally posted by Rai Orz : Lets thinking on differnt ways.
1. Take the next step. Look inside camera heads. Most CMOS Sensors have digital, par. out, so why not connect the CHIP direct to a FPGA.

2. optical viewfinder?

3. Take your brain free from all PC stuffs. The A/D Unit, inside (or outside the CMOS Sensor) have 10, 12 or more output pins (each pin is one BIT). The output rate is 33-66MHz. FPGAs can handle those data speeds in realtime. Shift or translation to 16Bit words are simple works. Next part is the Harddisk. Not a controller or interface, you can write direct to disk. A HDD needs words, not bytes. There are 16Pin (one pin = one byte) and you can connect it also direct to the FPGA or MC.

4. Also you can split the datas to more than one hdd. (First word to first HDD, second to second...) -->>>



All good points. But you missed mine. I (and others) KNOW this
can be done, that is not the problem. The problem is DOING it.

1. I don't know how to do this, neither do I know of someone here who does (except perhaps Juan [who is busy with is mod])

2. I don't want an optical viewfinder. I want a digital one with B&W option, zebra stripes and histograms, but I guess an optical (although I'm wondering what kind of optical engineering that would take) solution would be okay to start with

3. Are you saying hook an SATA or IDE harddisk DIRECTLY to an FPGA design? I don't think this is going to work without some sort of controller since the harddisk needs all sort of commands being send before it will read/write

4. Yes, that is a software "RAID" solution we have already implemented. I was only saying this also needed to be done in FPGA which is harder to do

I think most of us know what the possabilities are and how such
systems could be designed. We just lack the specifics for much
of the realtime embedded hardware design.


Ronald: "with the rolling shuter for god's sake take the Vance Cam idea, a mechanical shutter like good old S16 and 35mm days"

Yes, that was one of my questions as well. I've asked it multiple
times but never got a clear answer from anyone whether this
will work, will remove the artifacting and how this would be
connected to a camera head (the chip and shutter would be
needed to sync I think). So unless someone has some realworld
info on that....


Flax: hmmm, interesting. Thanks!

Hm
Vance has done this on his PAL cam
do google for Vance Cam

Yes I know. I've read all I can about the VanceCam. However,
what works for him might not work for us. Remember that his
head had an external shutter option. And it still doesn't say
whether it will actually REMOVE the effect (he wasn't using
CMOS technology I think). We need to hear about this from
the guys who make these CMOS chips and camera's. However,
Vance is also a member on this board, so I'll shoot him an e-mail.

Also on your "pipe dream solution". Do you know a price? From
what I've seen thusfar those systems are very expensive
(think $5-10K easily).

Rob L.
Thank you for the warm welcome!

Steve, Thank you for that information-it's important

Originally posted by Rob Lohman:
-----------------------------------------------------------
So unless someone has some good answers FPGA wise for these
kind of "issues" I don't see this happening for now.
-----------------------------------------------------------

This someone could be Juan! I hope! I've never seen an FPGA chip ,so I just assume it's a programable "many pins device"...

...and start dreaming:

1. You get from Juan a little metal(not plastic! :)) box with the following ports: 2xUTP - 1GigE-in(to connect to Steve's camera) ,1GigE-out for camera control (see Rem#), 1xSATA (or PATA) a HDD for Recording images, 1xVGA - Originally posted by Flax Johnson: "Rob,Juan has a vga output on his mod.", 1xPower connector -Battery

Rem#: (a part? of the FPGA should act as GigabitNetWork Switch)

2. You get from Steve a Camera with GigE out

3. You get 2 very very fast HDD's - WD Raptor (10000RPM, 16MB cache ...or similar) when the disk is full a "Camera Reloading" is occurred and the assistent swap the drives and the full one is attached to host computer (near the video village) and then copy files to host- then delete them :) from the Raptor.

Some clarifications:

The "1xVGA" is for a view finder(LCD) and this device (a wireless PC->TV convertor): http://www.grand.com.tw/en/product_f...-090&lwk_page=

To the "1GigE-out" is connected a small WireLess Access Point(BRIDGE) with a 100Mb UTP connector-
this is for camera control from the host computer

Best Regards

Marin

It's always good to dream (mechanical shutter, optical viewfinder etc.)

But at the same some of us need to keep both feet on the ground, and make it work. That's what Rai and Markus apparently achieved, and that's what Obin and the Rob's are working so hard at.

Of course there are many ways to skin this cat (no harm intended...), but with all these ideas about FPGA's and other solutions, there's nobody around here that can actually build a camera that way.

On the other hand, the solution of working with a small PC connected with a cable to the camera seems to be very feasible, although difficult enough. But if the two Robs would get a reliable application that can write lossless RAW 24p1080 sequences to a PC with 2 disks, I'd be willing to put up with the limitations of having a cord connected to the camera. Probably a dual cord: one for the cameralink/ethernet from the camera to the PC (in the video-assist cart), and one back with a VGA signal so the cameraoperator can see what he's doing. I tend to have cables running to the camera anyway, video-assist etc. Not a big deal. And 9 times out of 10, I'll have power on set - so that's not a big deal either.

If this results in a clean 10 - or 12 bit uncompressed HD image, I'd personally be happy as a clam :-)

On another note: an optical viewfinder needs a prism to split the beam of light in two beams. Thus only half the amount of light hits the CMOS. Not good. Same goes for groundglasses etc. A 1-chip bayer image is not ideal, but if we get it to disk without compression, or other image polution it should be more than sufficient.

Just my way of supporting the efforts here - since I'm no good at programming or any other useful skills.

Bar3nd

Bolex did it 80% to 20% 20 to the viewfinder

<<<-- Originally posted by Barend Onneweer : It's always good to dream (mechanical shutter, optical viewfinder etc.)
...
............. but with all these ideas about FPGA's and other solutions, there's nobody around here that can actually build a camera that way.-->>>

Those things i love so... ... Noboy? Will see...

<<<--On another note: an optical viewfinder needs a prism to split the beam of light in two beams. Thus only half the amount of light hits the CMOS.-->>>

Not at all. Think on mirrow-shutters. No light loss.
And you will also need some kind of (external) shutter for the altasens. Thats true.

Dont think i love optical viewfinder over all. No, i only say, its one thing that work.

Last thing for today (no more spam :)) !

This document could be very interesting-there is a chapter inside "ATA Interface Dissection":source: http://www.timothyjordan.com/portfol...sis/netapp.pdf

...and is this chip similar to "FPGA"? http://www.st.com/stonline/books/ascii/docs/10350.htm

Best Regards

Marin

<<<-- Originally posted by Ronald Biese : Hm
Vance has done this on his PAL cam
do google for Vance Cam -->>>

Vance has used an LCD shutter with a light loss of ~2+ stops. You can see the diagrams to sync the shutter with camera. It would be nice to drag him back into this forum.

HUGE BREAKTHROUGH TODAY!

we can now capture 8bit 24fps with no dropped frames AND it looks like 10bit 24fps with NO dropped frames on pci 32!

FULL 1080p!!!!!

more to come later!

@Marin: Yes, indeed, its what i said: The pdf show a simple example for "direct to disc" solutions. You need nothings between HDD and CPU. No controller, no extra parts, nothing.
But for HD Camera the MC RCM3200 in this shematics is to slow. It runs only at 44,2MHz. But you are on the way.