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.

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.

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.

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.

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.

practicalities...
 

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

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.

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

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.

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)


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.

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

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.

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

The complete camera...
 

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

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.

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.

it is possible to add eos control to some universal extension board for the 10353, but CS-to-Canon adapter does not have electrical contacts so there is no easy solution for that.

I also believe it is very important to be able to use as many off-the-shelf components (like cell phone you suggested) as possible instead of building everything in-house. This will provide much more flexible, easily upgradeable solutions. And those solutions require less development resources


You are welcome

EOS control...
 

Thanks for all the info Andrey! Some of it I knew...other things, I sure didnt :)

The main reason I'm interested in EF lenses despite the obvious problems with them being electronically controlled, is that I have several of them already with my canon 20D...another reason is that I hope to electronically control them in the future. (only focus can be manually controlled when they aren't powered...and some of the older ones not even that... as you most probably already know)

..also I saw the article on the wiki about your board after you first mentioned it and it sounds very exciting!

http://www.birger.com/Merchant2/merc...een=ef232_home

This company makes an adapter that can control and power EF lenses and adapts them to c mount...although it costs something like 1000USD. That totally brings it out of reach for me.

However...they sell a version without the controller part for something like 150 usd and that might still have the connector on it. This made me think I really should get an EF lens extension ring and see how hard it would be to modify it. (maybe this is what they do)

So the way I see it there are two possible solutions:

- try to add a lens connector to the EF CS mount adapter I found on Ebay...like you say it is without connector. (Probably too hard...and strays too far from the off-the-shelf thinking in my opinion.)

- look at modifying a canon EF extension ring.

I will order one of these and see what I can come up with.

A few questions:

1. When a lens is connected to your extension board and then connected to the 10353...can you send commands from a html browser to the lens? ..also - can you read values from it?

2. how much would that extension board be? and if/when will it be available for purchase?

please let me know! :)

//O.

I have one.

That was what I initially did myself.

So far I do not have such board - lens control was implemented in our model 323C camera (just 323 used Nikon lenses with no control) and now it is part of the 10347 that I'm working with.

As the protocol is not published it requires some guesswork and experimentation to control particular lenses and our in-camera web page definitely allows this control (and reading back too). Here is the web page code (the application source is in the same directory) - it is not too helpful w/o the actual hardware.

http://elphel.cvs.sourceforge.net/el...ml?view=markup

I can not promise such board as there is no solution so far for production use of it (I explained the reasons in previous post). So I'll add such circuitry (similar to that of 10347 board) only if there will be some extra room on the board and if it will have 5V power (preferably - 6V, 5V is not enough for some lenses) - i.e. for USB port.

I'm also planning to make some universal extension board with fine-pitch connectors included for experimentation. The electrical part of the lens interface is rather simple so you could add it yourself if we'll not have the board you need (at least in near future).

Maybe the FPGA inside the 333 was not enough, but then there is the 353. I can tell you, that the BBC would probably prefer an sensor with an SN ratio of 48db+ for 8bit, and 60db+ for 10bit, and similar latitude to an professional camera. These days, the SN and latitude of older cameras has been surpassed, the next generation should be great, but those old characteristics are important. The BBC had managed to do many great productions in Digital Betacam, and had problems with DVCPRO HD, so they probably expect smoothing that is like an HD version of Digital Betacam. If you wanted to talk to them, asking about an better sensor might spark their interest. I am sure there is an suitable cheap option without having to resort to an Altasens.

I suppose that we will see the MJpeg Bayer solution first?


Thanks

Wayne.

EOS control...
 

hehe I thought you did :)

Thanks! - still good to have a look at the code - gives me an idea of what I can do and not.


Just so I get this right...IF there is room for the circuitry on the 353, there will be a connector on the board where I can solder wires for the lens connector in my EF extension ring? (Im thinking of using an EF extension ring - attach it to the EF <> CS adapter and then solder wires to the connector inside the extension ring - not the cheapest solution but it means no mechanical work, just some soldering...Ill just have to check so the gglass doesent come too far away from the lens when doing this)

If there is no room for the circuitry on the 353...I could then buy the 10347 board (timing control for KAI sensors right?) and that board will have the connector needed?

..the lens control isn't crucial to me - if we have WiFi support and direct to harddrive write of bayer "raw to grayscale" jpegs I will be happy as happy can be ;) ..but it would be really really cool if we could get the lens control to work as well!!

I read some info about the lens interface on the Birger site and it seems it would not be too hard to create an USB or serial interface...but I would very much prefer to build something that avoids circuitry and is integrated with your solution...that way the work I do can easily be copied and used by others! (not only hardware wise but gui, software etc)

thanks

//O.

In the spirit of the phone thing.

http://www.engadget.com/2007/02/13/m...on-litigation/
http://www.meizume.com/showthread.php?t=888

Yes, that is 720*480 LCD resolution. I don't know how linux goes on these things.

Here are a few others, I view them as potential micro-controllers with displays and buttons, but an network to USB adapter is needed for most.
http://www.gp2x.com/

http://en.wikipedia.org/wiki/XGP

Others:

http://www.linuxdevices.com/news/NS2986976174.html
http://www.slashgear.com/fic-linux-c...ity-072392.php
http://72.14.253.104/search?q=cache:...1&client=opera

www.neonode.com

Cute, interesting features, also other FIC ones interesting:
http://www.linuxdevices.com/news/NS5201088922.html

http://forum2.mobile-review.com//showthread.php?t=56240

http://www.vr-zone.com/?i=4548

And the list of choices goes on, as long as they are cheaper then an UMPC.

Odd,

There is no room on the 10353 itself - it is stuffed as dense as I could. It does have connectors to the extension board but those connectors are really difficult to solder wires too ( http://www.hirose.co.jp/cataloge_hp/e53700036.pdf ). So we will probably make some universal boards for simple extensions that will have these connectors soldered.
10347 will not really work - it is a part of the CCD control and connects as other sensor boards (so instead of 5MPix CMOS board)

Extension board...
 

Ah - I see - that PDF made it all clear.

Well...I'm just happy to hear about the extension board!

This is what I really like about this open solution - the _luxury_ of being able to ask you things and to be able to add-on to the design later on - even after buying the base design. Add to that the ability to design my own gui...in such a simple way as editing flash & html. Brilliant!

Please correct me if I'm wrong - this connector will be on the 353...and once there is an extension board available, I can open my camera, add the board, solder some wires to the extension ring in my adapter...and then add the features in my GUI.

Voila! EF lens control!

I know there is a lot of pitfalls and things that might not work...but in theory? :)

To be quite honest - when I saw birger.com's 1.000USD pricetag on their EF lens control...I thought controlling EF lenses would be totally out of reach. Glad to be wrong!

Thanks

//O.

We did start working on such simple board that would allow fast prototyping.

Thanks for the nice words. And - there will be php too.


Yes, that is correct.

Electrically interface is simple. I believe the problem is that original manufacturer did not publish it - so even other lens manufacturers had to reverse-engineer it. Then - the first ones were modifying their cameras (probably by reverse-engineering those ones that were built by revers-engineering theirs...) to make those built by others lenses useless with the new cameras, etc. I believe it is rather stupid game and a waste of human creative work.

If you decide to complete it - please let me know!
I would very much like to betatest and be apart of the development.

I agree totally.
On that note - I even believe that the patent system that was created to support inventors and engineers...is now obsolete in many ways. These days it's pretty much just a big idea stealing engine for big corporations with cross licencing schemes and entire departments with patent lawyers. This is something that really kills innovation. (its proven that most innovation happen in small companies...so no surprise the patent system has been hijacked by big corporations) ..but all that is another long discussion ;)

Long live open source! :)

..regarding EOS lens spec - did you try to just email Canon and ask for the communication spec's? Sometimes what was impossible before - can change. An example of that is the Nikon consumer camera communication specs.

Everybody reverse engineered it because it wasn't available. A few years ago I decided to have a go at it (I was developing a control software for timelapse photography) I asked Nikon for the specs. Well surprise surprise - they asked me to sign a simple NDA regarding the specs and then handed me the complete dev info on CD's - at no cost. So things can change.

I look forward to more news about the 353 - until then - Ill be as patient as can be! :)

//O.

A lot of interesting links Wayne!

ooh I really like the Meizu M8! :) - looks the way my fat little windows mobile SHOULD have looked...(my screen 20% smaller and the device 100% fatter ;)

However - the concept of using an "existing" device like a wifi phone as a camera gui makes a lot of sense I think. First off I get it cheap when I sign up for a contract with my phone company...and secondly its got loads of battery time. Beats any laptop. Plus - portable as portable can be.

That means instead of getting a laptop - we can spend more cash on the important part - the camera.

//O.

I just put an bid on an neonode N1 today (they show N1m, so it is a bit confusing) but I want micro phone until I can get smoothing more suitable to replace this Palm TungstenW (Beautiful, but keeps turning itself on and even making calls :( ).

I have found lots of really interesting, cheap, Korean phones QVGA and pen based) including the one that looks like an PSP). The neonode N2 (77 x 47 x 14.7 mm, 70 g) the M8, and the Apple Iphone are some of my favorites at the moment (the Iphone might drop drastically before it is released). Nokia is coming out with game compatible phones, including a more game oriented model rumor. They also have an update of their keyboard phones (9500, 9300/1 series) and tablet phones but they are likely to be way over the top in price.

I forgot to mention, the cheapest Palm is also a possible target (USB network adaptor providing). Palm is said to be releasing a third category device next week.

Most of these functions could be done in camera by an button interface, and an display output from the preprocessing section.

N1...
 

I would stay away from the N1 if I where you...
..it looks really good - but the screen is very small and from what I hear it is very buggy. (a friend of a friend has it)

just thought I would give you the heads up ;)

//O.

No, I just googled the matter

That is not an option for us - we would not be able to keep our circuit diagrams and code open

Andrey, check out the attached JPG of the chart I made.

I have researched most of micron, cypress, kodak, zoran, and other sensors. I am also a filmmaker and Visual Effects artist. This sensor is perfect for cinema quality.

Kai 4021 Highlights:
- Large 21.5mm imager size (filmmakers will love this, great DOF)
- 60 DB Dynamic Range
- No Rolling Shutter (important!)
- 24 FPS using FULL sensor width (16:9 Aspect Ratio)

the KAI-2093, KAI-2020, and KAI-1010 are also fairly large sensors with good image quality.

I don't know which of these sensors is cheapest, but I'm guessing they are a bit more than the Microns.

Solomon,

It is probably possible to build a sensor front end for this sensor to work with 10347 board (instead of 10342 or 10344), but the ADC is slower - we can run only 25Mpix/sec for each channel (there are 2 channels/CCD outputs), not 40

At 25Mpix/sec per channel, that would reduce the framerate to 15fps.

In that case, you can drop some more vertical lines and get Cinema Aspect Ratio of 2.35:1. You could also do 16:9 at 1280 x 720 resolution.

The KAI-1011 has 20Mhz channel output at 30 FPS. That could work with your ADC hardware at full speed. The chip is also fairly large (9.1mm x 9.1mm) so DOF would be good with 2/3 lenses. (it's also probably cheaper than the KAI-2093)

just some thoughts.

nda...
 

ah...well..too bad.
sorry for wasting your time.

But of course!
..the reason I could accept it at the time was that I was only putting together a quick hack for an animation I did. obviously wouldn't work in an open source situation.

I was more thinking along the lines of it being so old and reverse engineered that they might had finally released it in the wild.

Obviously not. :(

Lets hope there is info enough out there to make it work anyways. time, effort and experimenting can do wonders.

//O.

Solomon,

It will be possible to increase the frequency in some next generation sensor board (that will still work in 353 camera) - just in 10347 we targeted lower frequency.

I do not know the price of those sensors, but large CCDs are (naturally) expensive. 11MPix ones we use are about 100x compared to Micron CMOS ones.

Andrey

I hope that with our hardware and (even rather basic) software more people will be able to play with different lenses and post results.

Spoiled by FOSS I feel really bad when I have to reverse-engineer (stupid waste of time) but it can be a fun game that I enjoyed myself many years ago - I was behind the Iron Curtain at the time :-)

Thanks for the heads up. Yeah, but I cannot get N1m model in this country, but at the price they are going at, it looks like an good buy. Besides I want the very small pocket feel (my previous monster Nokia phone is not good for tropical pockets because of weight ;)). The N2 is smaller again, screen around the same, would be fun if I could film HD with it, but doubt it. The mob selling it shows the N1m, but says it is N1, that is why I am not putting more money into it, an N1m is definitely worth more to me. I have found an smaller PDA phone again then the N1, it is around $76US. Definitely in the cute play thing category, but I wonder if they are using the same chipset as the N1, but different software, hardware setup.

If the right phone came along with HD video, I would be interested in seeing how my alternative 9Mb/s codec theories on it.

and why not use a nintendo ds with opera!?
now you can install linux on this device! it have wifi and a touch-screen, a microphone ....and it is cheaper than any other wifi device :-)