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?

Juan,

The new compression for bayer images is new (although it is an extension of our 10bit codec.) No images to release yet from the new stuff.

Obin,

I don't know what "CineLink" is. If this is your tool then we have discussed this possibility.

Jason,

"Is it RGB 4:4:4 or YUV 4:2:2?" Neither. It is a direct Bayer compressor. Bayer images go in and Bayer images can come out -- however, under normal operations, the decompressor demosaicing filter will be used to output either RGB 4:4:4, YUV 4:4:4 or 4:2:2. The compression is not involved with this decoding option. All intended to be very flexible.

Starting from the begining
 

Just wanted to throw in a quick hello...
All the work you guys have put in is absolutely incredible.
I am trying to keep up with all the tech stuff, and certainly learning alot as I go. I got in late in this discussion, so I am reading from the begining.
I was up till 3 last night and made some good progress.
I just wanted to start off tonight be saying thanks for laying all this incredible groundwork.
I am eventially looking to undertake a similar project with similar goals. I will truely be standing upon the shoulders of giants...
Keep up the good work.

Thanks,
Erik

So it's decompressing a Bayer stream in RT? For a good bayer demosaic filter at 1080/24p, that seems like a lot of horsepower will be needed, or is there a seperate converter app that we're talking about here that's non-RT, and I'm just really misunderstanding things? Or is it simply an AVI file that can't play back RT, but at least we don't have file sequences flying around everywhere? BTW, I'm not expecting RT bayer conversion, for a good CFA demosaic filter, I really don't believe that's possible. Sure linear is fast, but it also seems to have a lot of problems that have to be circumvented by an anti-aliasing filter somewhere in the conversion process.

In other words, with your capture/convert applications, are you capturing a stream to an AVI file that has bayer information in a monochrome format (on the disk), but when you open up the AVI it shows color information because it's decompressing the bayer info?

Also, how much compression are you applying if you're able to get this on single hard-drive without an array? Can you compress Bayer information?

And are you only supporting one brand of frame-grabber (I'm assuming EPIX)?

This all sounds very interesting, and would definitely change the hard-drive specs that I have for my current camera design.

Juan I posted the raw files for you to play with....did you get a chance yet? I would like feed back from anyone that has converted the .raw files ....Rob ? Juan?

<<<-- Originally posted by Jason Rodriguez :--->>>

Some bayer filter yes, others no. By delaying this discussion until you need it will save a huge amount of work-flow time. Fast de-bayer previews are perfect through-out a lot of the editing time. We can dynamically switch de-bayer filters on decode, based on your needs. Rendering out an effect will use the best (and slowest) de-bayer filter, but as most previews are real-time in the CineForm products, rendering can be mostly keeped until output.We compressed gamma corrected bayer data to around 4:1. That means around 15MByes/s for a 12bit stream.That is what we are working with now. I'm get lots of excellent help from the guys at Silicon Imaging, so we have discussed other frame capture opportunities. But we are still in the research and development stage.

Obin,
I'm working on it.
Don't expect me to give you results now, cause my converter is very alpha and I'm a lazy coder :).
I need to correct some problems I got with 1280x720 mode.
If you have 1920x1080 I can give you results now! :)

BTW your test3 image have its blue channel messed up (at least on my Combustion)

lossless 4:1 bayer compression
 

> original post by David Newman
> We compressed gamma corrected bayer data to around 4:1.
> That means around 15MByes/s for a 12bit stream.

David,
Am I reading this right?
12-bit bayer -> gamma remapping (log, I assume) -> 10-bit, then a mathematically lossless 4:1 compression on a single frame of bayer data? From my own experiments, I don't see that there is that much redundancy in an image frame, unless it is exposed wrong or the lens is crap. Even the most compute-intensive algorithms stop at around 2..3:1. If you can prove your claim, then I have to congratulate you on this breakthrough !

... some time later ...

Well, I found the technology backgrounder on your website, which states that it is visually lossless, not math lossless. 4:1 lossless would have been nice :-)

Where did you read "mathematically lossless" ??

David, I know we have had differences in the past, but thanks for the effort with the bayer compressor/editor I asked for this project (and also the capture, I didn't expect). I hope you do very well out of it.

<<<-- Originally posted by David Newman : 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. -->>>

How fast was the cpu?

Thanks.

Yes, CineForm's codecs are visually lossless not mathematically lossless (ML). The quality difference in all partical workflows is insignificant, yet we do base the codec on a ML transform, then we mindly quantize for bit-rate control. A ML version is possible yet at 2:1 compression the data rate and entropy encoding times start to become as inconvient as uncompressed. We find the work-flow is best using visual lossless compression.

For performance testing I'm using a 2.8GHz latest series P4 (800MHz memory system). I have only preliminary figures from this system, in a couple weeks I should be able to gave exact encoding rates straight from CameraLink.

Thanks I say again, extemely good news. ;} This gives the project new vigor and direction, as with such a quality profesional NLE/capture system, now everybody has a good suitable workflow chioce.

Juan how is it going with the .raw files?

Obin,
I told you, I need to check everything again for 1280x720, and I'm a bit busy with two films I'm transferring to 35mm these days.
Also I'm a bit lazy at coding (I prefer to make things slow but right at first shot :) ).
If you could give me raw images from the 3300 at 1920x1080 I can give you results right now.

Also I'm on line here fiebelk a t hot-mail d o t com (obfuscated email link to avoid spam)

Ok what would be a good chip with lots of range for shooting 1080P black and white? I have been working with a Director that wants to shoot a feature in Black and White..any ideas crew?

Just so you know we are still hard at work coding the bayer converter tiff saver and color bayer preview side of things for CineLink

Very cool,

can't wait to see the end results that you get.

BTW, what algorithm are you going to use for the final bayer conversion to TIFF?

Well, I guess that using the SI 3300 or the SI 1920 would be a very good choice.
Remember the Monochrome versions are a lot more sensitive and usually have less noise...

Juan:

Did you send me an email? if so please read my reply

Jason:
We had a site floating about on this list for a while that had 3 or 4 algorithms on it...we will use that for a offline conversion

Steve:

Do you have the 3300 in black and white? if so is it the same as the rgb so we could use it without any more code writing?

Obin:
The SI-3300 is color only - a Micron decision. The SI-1300 and SI-1920HD are both mono and color. It would be as simple as leaving off the color mask step but they chose not to offer this option.

Juan:
I completely agree that monochrome is more sensitive (you aren't putting color filters in the way that are removing 2/3 of the spectrum at each pixel site. Other than needing more gain (which amplifies noise), I'm not sure how color is noiser. Related to this, a three sensor prism-based camera is more efficient that other methods like color wheel because it splits the spectum up and sends the RGB to the appropriate sensors without filter losses. The prisms are only 60-70% efficient, but that is better than the filter loses.

thx Steve

We now have color bayer preview coded and are working on Sheer/Quicktime export

Awesome Obin!

I've split off the "lights" discussion to a new thread:

http://www.dvinfo.net/conf/showthrea...threadid=32334

Hey,

Just curious, are any of you here proficient in Python?

If so, I'm wondering what the feasability of using PIL to process these RAW images (like .IHD) and do bayer conversions, etc. is? I'm assuming that using the "point" attribute you could theoretically make an bayer image processor, and then you'd have to write your own file importer using the raw importer, and maybe even the bit converter (for the packed bits).

BTW, to process 16-bit images, do you actually use floating point numbers or still use integers for the values of the pixels? In PIL there does not seem to be any provision for 16-value integers, just 8-value integers, the rest are floating point values, so I'm wondering if that's a typical approach taken in software design.

Not proficient, but I've done a little bit. I'm not sure how feasible your suggestion is, but I suspect it will be quite slow, since Python (IIRC) is interpreted.
I'm using floating-point in order to preserve as much information as possible. With 16 bits, you lose some information through "quantization" errors each time you process the data. Of course, floating-point slows things down too.

I may get a demo of CineLink today to play wiht..if so I will keep everyone posted how it's working..we are still working on QUicktime/Sheer VIdeo save ;)

Yah, I was just thinking that depending on what the options for bayer conversion are out there, I may or may not want to write something. I don't know C++, but I'm decent at TCL/TK, and Python seems to be similar to those scripting languages. With PIL I'm thinking I may be able to write my own bayer de-mosaicing app. It's not to over-ride anybody here on this list, or to say that what they're doing isn't good enough, just simple curiousity, and maybe the ability to get myself out of tougher programming situations where I don't really have the programming experience.