High Definition with Elphel model 333 camera

[Wayne Morellini]

Originally Posted by Andrey Filippov

As for more bits per pixel - I do not see any need for it with current sensors. Micron 5MPix has about 8ke- of pixel FWC, so even with it's 12 bit output the number of the levels that can be distinguished is far less than 4096. So I believe "gamma" table (actually - optimized for noise performance table) can compress the 12bit range into 256 without sacrificing sensor data.

Yes, the current sensors won't even do 8 bits of S/N db. 10 bits in only really needed for professional colourisation etc, and pushing images in other ways. Higher S/N than this is useful for low light when you have to increase the gain. It is not completely wasted. Another factor is, that there is, mathematically, more bits there to work with, as long as they can register real differences between adjacent pixels.


Need for better picture versus straight Mjpeg

To answer the other questions, it is about an higher quality image, the more something is blown up the more obvious the defects, and it simply looks more stunning. If we can't get an higher quality image from any given camera then an tape based HDV camera, then why use it. I see the possibility for the Elphel to match the XDCAM Eng cameras, but beating them is what we should look at. 50-70mb/s 8-10bit 4:2:0 (100Mb/s 4:2:2 or 4:4:4) Mpeg2 performance is what to look at beating. At this level (with sensor to match, even binned) we can hold our heads high and take our cameras out their, and never blame our equipment again ;). With simple compressed RAW Bayer, we could get in this range, with advanced bayer compression we could achieve it. But, most of these figures look meaningless, but Visually lossless like with Cineform Bayer on the SI camera, is definitely the target we should aim for.

Another important reason is component and HDMI recording. Yes, you can do it, but you also have to hike a mini computer with you, and when I say mini, it is probably more akin to an shoe box in value, and also as significant expense on the camera. This restricts the type of work you can do with it conveniently, mainly inconveniently tripod work. Being able to do something the size of an HDV camera itself, with disk and screen at just the price of the HDV camera, is an amazing advantage over an HDMI recording system. With this, you can go portable, and do regular small production work, versus having an computer box in an backpack or on the ground.

But this is an project of the people, an couple of years ago Andrey could have profited enough from it to justifying doing it all himself, but those days I think are gone. Modern cameras, and HDMI recording being the distraction that will limit sales, but still substantial potential.

Re-edit:

Mateo,

I forgot to mention, there is not enough bandwidth to do really good Jpeg on the camera. We are limited to around DVCPROHD quality levels, not quiet as much as we need fro pro stuff. With bayer we should hopefully, be able to double, even triple performance.

[Wayne Morellini]

Andrey,

About your grey scale Bayer Jpeg, what form of grey scale scheme was it, can you describe it, and the quality of the results achieved.

Is there any sample pictures?


Thanks

Wayne.

[Andrey Filippov]

Originally Posted by Rob Scott

Thanks for putting that together, Andrey, it's very instructive.

Question: How does pixel binning affect this? For example, you can configure the Micron 5MP sensor for 2x2 binning, resulting in a 1.25 MP image with less noise. How many effective bits of resolution would this image have?

We did not try this mode with the 5MPix yet and I expect it would help only to lower relative pixel readout noise. In the ideal case (like it is in the CCD) if you join charges of 4 pixel into one _before_ output amplifier tract (that adds noise) your gain 2 in S/N compared to just adding the pixel values in the picture (in that case signal will be the same - 4x of individual pixel value, but noise will also increase as square root of 4 that is two).

I'm not sure about FWC in this sensor (BTW we measured it to be about 8500). Theoretically it is possible to make the output path capable of handling 4x the maximal value of individual pixels (how it is pretty common with CCDs that have 3 values fro FWC - pixel, output register pixel and output capacitor - each larger than the previous) - I just don't think it is implemented. I believe the binning is suplemental mode there and targeted to low-light conditions, not to increasing S/N for large signal. But, as I wrote above - we haven't tested this mode yet.

[Andrey Filippov]

Originally Posted by Wayne Morellini

Andrey,

About your grey scale Bayer Jpeg, what form of grey scale scheme was it, can you describe it, and the quality of the results achieved.

Is there any sample pictures?


Thanks

Wayne.

Wayne, I just started to put together some design ideas for http://code.google.com/soc/ that we plan to ally for next week. It is in our wiki - http://wiki.elphel.com/index.php?title=SoC. It includes demosaic project
Current implementation is in
http://elphel.cvs.sourceforge.net/el....v?view=markup
(Unfortunately tabs length mismatch, so formatting falls apart)
If you scroll down the code you'll see the comments with description of the calculations.

[Andrey Filippov]

Originally Posted by Wayne Morellini

About your grey scale Bayer Jpeg, what form of grey scale scheme was it, can you describe it, and the quality of the results achieved.
Is there any sample pictures?

Wayne, in each group of 16x16 Bayer pixels:
R001 G002 R003 G004 ... R015 G016
G017 B018 G019 B020 ... G031 B032
...
G241 B242 G243 B244 ... G254 B256

they are rearranged:

R001 R003 ... R015 G002 ... G016
R033 R035 ... R047 G034 ... G048
...
G017 G019 ... G031 B018 ... B032
...
G241 G243 ... G254 B242 ... B256

So each of the 4 8x8 blocks consists of the same color component. Then the data is compressed with the regular monochrome JPEG encoding.

[Odd Nydren]

..very interesting discussion about colours and raw bayer!

I am very inclined to buy the new camera whenever it is released - hopefully april...but I have a few issues that I need to know how to solve or have an idea if they will be solved by Andrey or the team.

I do not mind being without a viewfinder and I even wouldn't mind controlling the camera via wifi from my mobile phone using a custom gui. The phone has 320x240pixel touchscreen + wifi.

..however I would very much like to avoid having a laptop wth me when shooting.

I know this is early days still and that I probably ask for way too much...but I need to ask:

1. Harddisk adapter: is this something that you need to design specifically or can it be bought somewhere else?

2. will somekind of bayer raw or bayer compressed stream written to the camera disk be developed this year? if not...what would be the next best thing available?

I do not mind extensive post processing once out of camera...and I do not mind using flashcards instead of harddrive.

If there where a solution to these issues...I would not hesitate to buy. I can live with all the other limitations..as there is really no other camera for that price that can do the resolutions and framerates. ...plus have an open architecture...wich to me is really the way to go.

Am I wishing for too much too early? :) I hope not.

please let me know

thanks!!

//O.

[Wayne Morellini]

Thanks for that Andrey, I can see that, pooling similar pixels to get compression advantage. How much advantage does it get out of that scheme, does it have the ability to get an 8*8 green block and do difference compression against the other 8*8 green block, and the red and blue? In this case, you may well be achieving close to the best from Jpeg.

An good question would be, if there is exactly the same image data repeated four times in an image, does Jpeg pick it out and use one image as the basis to do difference compression against the remaining four images? If that is the case, we would not need to do the 4 bayer pixels as four separate frames and do an difference between them, we could just make an extended frame with the four images one after the other, or an row of red, green, then an row of green blue images ;).

But, with four separate images, an more intelligent prediction can be built in for difference compression (even arranged in three separate images in an image, or as in 8*8 blocks as you have done). The first image from the first green bayer pixels can be compressed by normal Jpeg, and the next green could be stored as an difference from that, then compressed, and so forth for the other colours. But a way to reduce the difference further, raising compression ratio, and increase compression, might be to store the remaining colour images as the difference to an predicted value made from the interpolation of adjoining surrounding pixels (by averaging) that is then compressed. This prediction could go further by examining the image for details that move in direction, rise and fall in an certain way, areas, and edges, to decide which pixels to interpolate and use for the difference, but this is too elaborate and complex for what we need. Trying to get rid of the first green by storing it as the difference from the interpolation of the other pixels, is where my brain starts to melt down, but I do believe there is an actual mathematical method somewhere that can store all four bayer images as an difference from each other, and still be able to restore all four.

It is amazing the digital still camera industry never concentrated on doing Bayer related codec performance, as most of them are purely single chip.

[Wayne Morellini]

Odd, that gives me a thought. I have been looking at doing an third world computer system based on media player, or mobile phone architectures. Phone and media players offer an cheap way to view and control the camera (except for the general lack of network interfaces on them) with the disk being on the camera itself. The Sony PSP has wireless network interface. there is some Linux based gaming media handhelds (Game Park related, both those companies).

[Andrey Filippov]

Wayne, yes - it is possible to do something like that - it may turn out to be a wavelet variation for Bayer data. In any case it makes sense to simulate everything in software on the model images before trying to implement it in FPGA - in software it is much easier.

[Andrey Filippov]

Originally Posted by Odd Nydren

.1. Harddisk adapter: is this something that you need to design specifically or can it be bought somewhere else?

We will make something to start experimenting with HD. Microdrives could even fit in the same camera body, but with new 16GB flash - will they survive at all? Using laptop disks (more practical) will need a larger camera body.

Other concern - I haven't tested IDE port on the 10353 board yet and we will get to 10357 probably in April - first 353 camera are designed to have IDE port but it is not tested so there is some probability that a new board revision may be needed (if I did something wrong in that simple part)

Originally Posted by Odd Nydren

2. will somekind of bayer raw or bayer compressed stream written to the camera disk be developed this year? if not...what would be the next best thing available?

The algorithm described above with reordering of Bayer components and treating the result as monochrome will be available very early - it will be the main mode for larger sensors.

Originally Posted by Odd Nydren

I do not mind extensive post processing once out of camera...and I do not mind using flashcards instead of harddrive.
If there where a solution to these issues...I would not hesitate to buy. I can live with all the other limitations..as there is really no other camera for that price that can do the resolutions and framerates. ...plus have an open architecture...wich to me is really the way to go.
Am I wishing for too much too early? :) I hope not.
please let me know
thanks!!//O.

Your requirements overlap with those I'm already working on. So I believe it is "too much" - maybe only somewhat "too early" :-)

[Wayne Morellini]

Originally Posted by Andrey Filippov

Wayne, yes - it is possible to do something like that - it may turn out to be a wavelet variation for Bayer data. In any case it makes sense to simulate everything in software on the model images before trying to implement it in FPGA - in software it is much easier.

Do you mean that you are working on wavelet compression ? I have talked to the Open source BBC Dirac, about their open FPGA and your camera, are you working with that?

The cineform RAW technology is worth looking at to see their version, and how they did difference compression and wavelet (not that I have read it yet, but heard this was the case). The interesting thing is that the licensing for their version is quiet low, don't know about FPGA licensing:

http://www.cineform.com/technology/Cineform_RAW.htm
http://www.cineform.com/technology/C...RAW_060413.pdf

I myself, am curious about 2d and 3d Wavelet compression as an alternative way of doing intre compression.

Congratulations, wish you the best Andrey.

[Wayne Morellini]

Hmm, doesn't look like that link has the actual raw tech mechanism, I thought David Newman over at Cineform posted a link, I think he might have even sent me an copy (I still think I didn't get to read it more than skim through it).

[Odd Nydren]

Andrey: Excellent! I really look forward to what is coming! I'll be patient. laptop harddrive I think would be optimal!

Wayne: I'm glad you find the mobile phone solution interesting...

..designing my own control gui that works on a 320x240 pixel touch screen will be a breeze. Its a small screen...but extremely portable + has a slip out keyboard. (I read & post on this forum using it & 3G)

None of the other solutions we have seen here on dvinfo can boast having a in-camera harddisk solution...and controlling the camera like this makes for a very portable solution.

Regarding lenses:
I plan to make a gglass solution for the camera using off the shelf thorlabs adjustable tubing, a moving Canon Ee-S/Ee-A focusing screen like the one from http://www.jetsetmodels.info/news.htm
and a canon lens to CS mount adapter (found on ebay for around 40usd) - this means no custom parts...just screw the parts together & a bit work to adjust focus etc - I still need a macro solution between the gglass and the elphel...ill post more when I have found something.

If then on a later stage Andrey add canon lens control to the elphel board - this lens adapter would be easy to modify to add lens control via the gui!! (basically a wired connection between the canon cs adapter & the 353 board + update the gui)

No other camera solution i've found out there is this promising! :)

Yes...initially I would have no viewfinder (maybe I can stream a small preview to the phone though) and would have to measure distance to adjust focus...but that's a small trade off for having a camera that is open, adaptable, portable and can truly grow feature wise. Cool bonus to have the control gui on a wireless device.

Andrey: I know we are not a large group of customers at the moment...but I'm sure that can change very quickly once there is a few working setups that show people what can be done! (especially if they are built with off the shelf standard parts wich is what I intend to do)

Thanks for posting your camera developments so regularly!

//O

[Andrey Filippov]

Originally Posted by Wayne Morellini

Do you mean that you are working on wavelet compression ? I have talked to the Open source BBC Dirac, about their open FPGA and your camera, are you working with that?

Wayne, I'm not yet working on wavelet compression - just having it in mind.I also count that somebody else could implement it with the help of our hardware. Dirac people had one of the first 333 cameras but it does not seem it was useful for them.

[Andrey Filippov]

Odd,

you probably know that there are many motorized C/CS lenses (just iris, iris+focus, iris+focus+zoom) but there is no single standard for those - different iris control, different voltages, no standard connectors for anything but a 4-pin iris. It is complicated by the fact that C/CS is a thread, not bayonet so most lenses come to camera manufacturers with no connector at all and each manufacturer uses proprietary solution.

I was thinking on developing a bayonet mount that is closer to the sensor than CS-mount, so it would be possible to make this_proposed_bayonet-to-CS adapter. Then - mount a small (5mm wide) PCB with programmable micro-controller inside this adapter, solder the wires from the motorized lens directly to the PCB and have a motorized lens with bayonet mount. We designed such board http://wiki.elphel.com/index.php?title=10331 - it has just 2 contact pads that provide both power and data, different programs might be used to accommodate different lens controls.

But we got stuck with mechanical design for the bayonet - it would be nice to have it really strong (motorized lenses are heavy) and it could also be nice to be able to seal such mount (and adapter converted to a hermetic lens enclosure). 333/353 boards themselves are designed to use a sealed network connector ( http://www.rjfield.com/ethernet_connectors_rjf_en.htm )

Maybe such bayonet mount should have additional bolts that could be used if the lens is heavy and/or sealed connection is needed.