Can we gamma correct the bayer pattern itself, I mean before "converting" it to full colour?
I guess it would be more or less the same, but need some more info...

In theory that should not be too much of a problem Juan. However,
the problem might be in clipping and such. If your not very carefull
you might loose information that you can never recover.

I know it.
Linear to log table would have exactly the same effect on the Bayer mosaic or the color image.
I was asking if it makes a difference to demosaick the linear bayer or the log bayer.This is the exact question.
I know for example that it is not the same to saturate color on a linear image or a logarithmic one.Results look quite different.
So that's why I'm asking...

I know that's what Jeff Kreines is doing for the Kinetta-10 bit Log monochrome bayer. So it can't be that bad.

Of course what I'm suggesting isn't a Log bayer pattern, but for Obin to first convert the bayer, and then log encode that to 10-bit SheerVideo Quicktime. I'm really not sure what 10-bit log bayer might do to the image conversion-wise, but I can find out.

But at kinetta.com it says it records full color images,or not??
I'm getting confused.....

On the magazine itself, Jeff is recording a 10-bit Log file to increase frame-rates and recording time; basically maximizing throughput like we are trying. There is another Xilinix FPGA in the magazine that then reads out those files and does the bayer conversion to color in real-time. From there you record out via HD-SDI or there's also a SDI downconverter. But the RAW files themselves are 10-bit files ecoded to a logarithmic file in order to preserve space (also SDI is only 10-bit, and he wanted to get as much of the 12-bits that the Altasens records into the 10-bits of SDI and HD-SDI). He also has some nice things like view LUT's, etc., but basically it's recording 12-bits off the camera head and then encoding that to a logarithmic 10-bit file for storage and playback across HD-SDI.

That's why I'm thinking if Obin did the bayer conversion and then encoded that to 10-bits RGB using SheerVideo, he should be fine.

Okay, not sure if this makes a big difference, but I took on of the linear files that I had on-hand, and converted it to a logarithmic file, with the whitepoints at the extremes of the bit range (0 is black and 65536 is white), and a gamma of 1.7. I then applied Ben's LinBayer plug-in, and did color-correction after that. Everything seemed fine to me, and I have a nice-looking image. Not sure if I did this "right", but I did take it from a washed-out image and now have it as a nice, colorful image.

OK, thank you for your testing :)

It is mathematically the same to apply the gamma correction to the raw bayer first rather than after the demosaicing filter. We are taking the 12bit data and gamma correcting it to 10bit raw before compression. As compression in our approach had to be real-time, it was important to delay the computationally demosiacing filter for later. The gamma correction before compression allows the visually significant image to be preserved in 10bit data. The demosiacing is done under user control during decompression (playback.)

David, have you come up with another capture device? What are you describing here when you say "our"?

BTW, if everything is getting converted to Cineform's codec, is there way that it can then be ported over to the Mac and edited in FCP?

Also if you've been designing a capture app, can it capture to a variety of frame-rates?

Just curious since it seems like you're talking about another capture app.

Yes, CineForm has been quietly working on our capture and high bit-depth bayer-based editing solution. One day we do intend to support the Mac, yet today we can get better performance out of a PC (for our architecture -- not a PC vs Mac thing.)

We intend to support compressed capture up to 30Hz for 1080p and 70+Hz for 720p. This will be on a single CPU system over standard PCI, to a single drive (or any type.) Higher frame rates will be obtainable on multi-CPU systems.

Jason,

One more more thing to add. Our capture solution is intended to be an engine that sits under alternative (third party) capture interfaces. We hope this technology will be licensed to work with a range of imaging solutions (including camera based direct to disk compression.) We will also be building our own GUI for capture for standalone applications.

David,
Could you show us a couple of frames (after being compressed with your codec) to see its quality?
I've never been able to see anything compressed with a Cineform product...

David could this be an option for CIneLInk later on when you get it done?

www.dv3productions.com/uploads/test3.zip

it's a file that has been captured with cinelink and output to a 16bit tiff file..nothing fancy just to show we are making progress ;)

www.dv3productions.com/uploads/raw/Rec00012.raw
www.dv3productions.com/uploads/raw/Rec00013.raw
www.dv3productions.com/uploads/raw/Rec00014.raw
www.dv3productions.com/uploads/raw/Rec00015.raw

raw output from CineLink datacapture

Global gain: 10db

Shutter: 1/60

fps: 24

Camera MHZ: 60

Camera: SI 1300RGB

Just curious,

Is the cineform product going to be RGB 4:4:4 or YUV 4:2:2?