I have seen a news article about it. Somebody is preparing a Fedora based distribution. I suspect we will see a number. But before it is goign to be of use to us, they really are gong to have to have a method for normal Linux programs and codecs to automatically take advantage of the extra parallel processing power, or the developers are going to have to customise their codecs and other software. Which means somebody will have to ask them, or write it themselves.

http://news.spong.com/article/10969?cb=94


Ronald, I tried to email you a little while ago, to ask for some advice. Have you upgraded your mail redirection in your profile.

The new Micron sensor is only 1/2.5" of size. I think without a ground glass we won't have an adequate DOF. The 2/3" size is around the minimum that we could use. Their previous sensor with 1/2" size might have been worth a try (with different resolution and fps of course) but this has just became too small. Moreover, we lose 25% of the vertical resolution if we need 16:9 aspect ratio so in the end we get the size of a 1/3" sensor or even worse.

Any suggestions for a good GG? I've seen there are a lot of them on this forum - I just can't choose... All I know that I don't want any DIY stuff, I'll have more than enough work with the camera itself.

It is also a good question the maximum aperture we can use with the C-mount lens without causing problems with the sensor's microlenses. The GG and this aperture will add together to give the total losses of f-stops we'll have (that's probably around f1.5-2 if the glass loses f0.5 and we have a lens with f1.2). I suspect we'll have to use almost always the maximum shutter width the sensor is capable of, ie. something around 1/24 (this includes the readout time). This will cause motion blur as a side-effect.

Luckily, the readout time can be really short with the new sensor. On 96Mhz it runs with 12fps on maximum resolution (as opposed to the previous sensor with a 48MHz max). We'll use it in 2x2 binning mode so 60fps can be reached in the planned 1280x720 resolution - this is especially good for overcranking. I suppose this readout speed doesn't cause rolling shutter artifacts anymore so that's good news.

Andrey, what are your experiences with the new sensor? Could we do it as described above or you see some problems? Also, ony of my earlier questions left unanswered: can we create two simultaneous video streams in the fpga (one of them for the disk recording and the other for the network preview)?

Thank you,
Zsolt

I don't have experience with any of them, but I've noticed that none of them have explicit support for a C-mount camera; they all assume a camcorder with lens built in. I e-mailed one of the guys about this and they said to use a C-to-Nikon adapter, then use a macro lens and a 10-inch (!) extension in front of the GG adapter. I know, 10" is awfully long -- I don't know if that can be shortened.
That was my thinking too. Sounds good!

I was thinking putting a c-mount lens on the camera and the GG after that. I don't know which solution is better, perhaps it depends on the quality of lenses.

It isn't a problem if we need those classic 15mm metal bars anyway to mount the whole thing.

Zsolt

Most of the static projects struggle to get HD resolution, so looking carefully through the threads for HD capable adaptors. Even moving ones, I don't know what the quality will be.


Thanks

Wayne.

I've been browsing through the m-audio/e-mu catalogs and it seems like they don't write linux drivers. So we won't be able to connect them to the camera. I think the audio will have to be recorded with the pc instead (we need one anyway for the camera control/viewfinder functions).

Zsolt

Eliminating the need for a PC would be quiet good.

EMU and maudio are not the only ones, Terratac??, and a number of others exist. Try looking on www.via.com.at website under there Envy 24 audio processors for manufacturing partners and products based on them. these manufacturers also produce items like those. www.digit-life.com , may also still have reviews of such products (their reviews tend to be quiet good) but the companies mentioned are worth a look at.

If you look through the linux stuff you might also find drivers and API's for the USB sound cards, even for specific models like the Audigy series (now much improved). I think I remember something about Audigy and Linux.


You don't really need a computer, most of the work is now in camera. You could use PDA, Micro-controller board, Sony PSP, or something like http://www.gamepark.com/ pocket game machines (some are Linux). The PSP is the best, but not strictly open, it has re-programmable processing line they use for sound and 3D, sort of like FPGA a bit and has good processing abilities. It can provide controls through their own controls, and display, but the camera could give live video feed port if made that way.

Update on 353
 

Extra work was needed to make the board boot from the NAND flash - that software is not yet available from Axis. But that seem to be done and camera now boots Linux from its flash memory. Next week I'll be working on trying the FPGA,

good luck
 

That sounds great and maybe a dream comes true.
A stupid question anyway.. for 10 minutes , the estimated disk space and sustained rate should be what about

Wavelet-Based RAW Compression
 

The usage of KWEII Wavelet-based Compressed RAW format for the purpose of camera inner storage has following advantages over JPEG:

1. Wavelet compression takes less time than JPEG compression does. RAW data compression leads to speeding up of the capturing process.
2. If two same-size compressed images are compared, the RAW compressed file has better quality than JPEG does. (Or, for the same quality, RAW compressed file is smaller).
3. Preparation of a small version of an image for its displaying on a phone screen for a quick check or sending it via radio channel becomes easier and does not require an extra storage space. A Wavelet compressed file has a special structure: it contains smaller versions of the image as its part. For example, if camera provides a 1,2 Mpix image, to get a VGA-size image only a part of a compressed file should be used for decompression and processing. Even smaller parts will be used for 1/4 VGA-size and 1/16 VGA-size images.
Two processes should be clearly distinguished:
* Image processing for data storing;
* Image processing for displaying on a cell phone screen.
These processes are independent and second process does not assume that the first process should be previously completed.
4. Because of Wavelet specifics, the noise level is automatically reduced upon resizing.
5. For data storing purposes, an image might be processed with phone CPU in a background (with lower priority) during a longer period of time and, as a result, a better quality of an image is provided.

Text above is about phones :) But same type of compression is used in RED, SI2K...
All correction of recorded RAW in post! If you really wanna cheap, but good HD cam choose right compression - Wavelet Based RAW!

That certainly would be cool. Aside from Andrey's work on Theora, the only similar free/open FPGA project I found was dwt2d -- no files were released though. Anyone else know of something similar?

Rob, google: raw to wavelet+open source ;)
Some useful links also:
http://www.compression-links.info/Wavelets
www.openraw.org
www.openfpga.org
www.doom9.org

Very interesting "geometric wavelets"

http://www.cs.tau.ac.il/~amir1/PS/gwcoding.pdf

A good post Serge. From my understanding, at lower compression ratio the quality difference narrows for standard Jpeg pixel format. The present differential compression should be a lot simpler and faster. But using wavelet for the differential over a number of frames should compress more. Cineform does this, and their Raw codec get around 6:1, but I do not know wherever that is just visual lossless or true lossless, as David's answers were a bit obscure. I imagine at least 3:1+ on average.

Their are many wavelet codec projects, their are an number listed on wikipedia, I posted a number of links here a few months ago. 2D and 3D inter frame Wavelet (used for security cameras and webcams) gets more, but I do not know if they are any good for visually lossless or true lossless. I had also been in contact with a guy from the BBC Dirac open wavelet codec (and FPGA design) they are good to contact (though they are normal codec so far).

353 update
 

I finished the tests I wanted to perform with the 353 prototype - upgraded FPGA software to version Xilinx WebPack 8.2i (it was not so easy to make it produce the same timing), updated some of our drivers to work with Kernel 2.6 (it was 2.4) and with new ETRAX FS processor. FPGA configuration works, attached 64MB DDR SDRAM - also OK. So now the corrected Gerber files are released in production.

Andrey, I still get people enquiring about projects like this. What is the new time line you expect for camera arrival, and any new additions and sensors that you might be considering?

It is hard to answer people about cameras when I'm not in the project and information is incomplete. If there was basic information on the performance, capabilities, limitations, and pricings of the camera, and the Digital Cinema projects surrounding it, I could simply point people there?

Wayne,

I'm trying to update development/production status here, and I do (usually) answer direct emails. At the moment I do not know the exact price (just hope it to keep about the same as it was for 333). I hope to have a first batch of the camera boards in about a month - it is now our highest priority.

The first sensor available with the camera will be Micron 5 MPix, older boards will need some modifications as the 353 board uses 2.5 V for the interface signals - not 3.3V as earlier models did. I am planning to use slower CCD (11 and 16 MPix) - similar to our model 323 camera, 8MPix - when it will be available from Micron, and have some work on dedicated hardware/firmware for compensating of the ERS effect of the moving camera.

We'll have info on the camera when it will actually be available posted on the web site, preliminary one - it is only here, in this thread.

Andrey

Thank you Andrey, but it might be more efficient to house a summary of the broad/preliminary information in one place (because it is very scattered and forgotten in this long thread) then repeatedly answering the same questions by email.

I have suggested to dvinfo in times past, for a modifiable sticky post, or link, at the head of threads like this, for the same reason. So, thread starters/moderators can post summary of where projects are, and save people reading through project threads. I think this can cut down traffic by 50% on these long threads too (or more).

Info about 353
 

Wayne, we can start something on our wiki.elphel.com about that. Now I'm pretty busy with new hardware development - several new boards will be released soon.

Cool!
,,,,,,

2 new additions to 353
 

I finished Gerber files for 2 new boards - one with 8 Compact Flash slots and the other has FPGA+DDR SDRAM (64MB) - exactly like on 353 board and 4 flex cable connectors (one - to 353, 3 - to sensor boards). It allows to attach up to 3 sensor boards to a single 353, making it possible perform some image processing there (i.e. stereo).

Nice, now I just need a PCI interface to connect the camera to a PC and get higher bandwidth than 100 Mbit and have greater flexibility.
That way I can really make a camera system. :)

Hi all,

What do you think about this one: using a small camcorder for viewfinder (as close to the Elphel as possible, its lens set to the same distance) and a usb numeric keypad plugged into the Elphel to control the recording? We won't be able to record sound tough.

Zsolt

How about the Nostromo SpeedPad N52?

Sounds good but we need linux drivers - the article doesn't mention it. If we can use it as a regular keyboard then it's ok.

Zsolt

Without a driver it generates keystrokes and mouse wheel events. It looks affordable, too, at around $20.

so, you are indeed talking seriously about using a parallel viewfinder and that keyboard?? Oh, my God......

Very interesting! Andrey, when we can see more information on your website?

If we think of the two types of video streams (recorded and displayed), changes in the software (switching between streams, because I'm not sure we'll be able to run both of them at the same time), additional mini-pc (or some other device) requirements, plus the need of simultaneous sound recording (I still haven't found an external usb1 device with linux drivers) then we're talking about some big changes.

First I want to reach the simplest solution and that might be a separate viewfinder+sound recorder, no matter how weird it sounds... However, what's good in the Elphel is that a lot of people can make their contributions to it so we might end up with a perfect camcorder sometime. I do my part (the raw video encoder), others can do other parts; but for the simplest solution the encoder will be enough in itself.

Zsolt

So its almost like two cpu's (camera bodys) but with just one sensor. One camera doing a low compression & pumping the images direct to a hard drive. The other doing a very heavy Mjpeg compression & pumping these small images out to anything with a lan port & Linux on it?

I was able to get usable video over a wireless lan in my house to XP from the 333. Perhaps if its just for preview a wireless server would work best? Imagine using a pocket PC to watch a low bandwidth streaming video direct from the camera, being able to adjust it etc without any cables remotely? You could put the camera anywhere & get great video. Sound is not such an issue, There could be a marker button that will create a point in the video (clapper board?) that you can use to line up the recorded sound with the video images.

That's a good idea but I have my concerns as usual...

Andrey, can we do such a thing? Use just one sensor board, divide its output in two and sync the two cameras?

That's what I was thinking too. The Elphel pushes out the stream onto a wireless network and you can have as many receivers as you want. Controlling the camera is a bit more tricky, one has to write some interface sw for that, but that's not very hard.

Zsolt

The 333 does have a html control screen . It takes a bit of getting used too but its all there from white balance & auto exposure to a histogram & colour correction. It does not look all that different to the one thats on the Silicon Imaging camera. Just a tad more complex as you really can adjust everything. With a laptop its a bit fiddly so I use a trackball thats taped to the laptop when filming on the move with it. But for real film making with actors etc then you will be wanting something much more simple with all the options hidden away. Perhaps a way to save the settings for different filming conditions?

Perhaps a Nokia 770 would be suitable for the viewfinder. It's based (almost?) entirely on an open-source stack and appears to be fully customizable.

Hi Phil,

I've been away from the board and the camera for too long...
I remember you talking about using the camera on the windows OS. How did you get that working?

I'm slowly picking things up, so I'll post things again when I have the time. My 35mm adapter is working fairly good with the 333 and I have ordered a wide angle lens.

lens
 

I gave up the thought of using 35mm lenses with converters because of their low resolution. Therefore I won't have control over depth of field, but what the heck. Image quality is more important to me.

So I began thinking about c-mount lenses: Fujinon has some new 5mpixel models with 2/3" areas. The bad news is that they've got no smaller lens than 12.5mm (except the 1.8mm fisheye). With 1/3" sensor size, this matches up with a 95mm tele-lens (in the normal 35mm film world) which is unusable in most recording situations. These lenses are expensive as well.

If we go down to the normal "megapixel" range, we can find lenses from several manufacturers down to 4mm of focal distance but usually no more than 1.5mpixel resolution. Because with 2x2 binning we'll get 1.25mpixels out of the sensor this might be enough, however, these four pixel groups won't have as great dynamic range as they could with a better lens.


Zsolt

Zsolt -- you might consider taking a chance with secondhand lenses. If you get one of the better C-mount lenses (Angenieux, Schnieder, etc), but the image looks softer than you would have expected, it probably means the lens needs collimating. This can happen with the older lenses; many of the popular secondhand ones are from 16mm cameras dating from the 60's and 70's (elements can get a little loose over time). With these lenses it might be considered as part of the cost to get the lens professionally serviced (set once again to the factory ideal). This adds to the cost but might still be good value compared to some of the new HD resolution lenses...

These 16mm lenses project to 16mm image size so they would behave as telephoto lenses when applied to a 1/3" sensor. So image quality comes as second only in importance to the focus distance.

Zsolt

Sorry for saying this, but I've got the feeling that you are all going the way we follow 2-3 years ago.
Anyway you all have my support.

Juan, could you please be more specific? I think we all have followed a lot of threads here on dvinfo for quite a while so if you write a few things about your way then we'll understand.

But anyway I think it's clear for all of us that this Elphel-based camera of ours won't change the world as, for example, the SiliconImaging or the Red cameras do. We're thinking in smaller things than those guys and even the guys on the DIY-HD threads here. Our ambitions are modest. Personally, however, I think the price/performance ratio of this stuff -if we can make it- will beat those other cameras'.

Thanks,
Zsolt

Ok, I will try again.First try I wrote a lot of things, but don't know how they all got lost.

I will try being more "specific" :)

In case nobody knows it,I was quite involved outside of this forum at the early stages of planning/development of SI's camera.
Together with a partner we manufactured a mechanical shutter test-bed and PL mounts that we sent to Ari Presler.
Our resources were quite limited at that time so maybe our stuff wasn't the best out there but, hey, at least we did it!!
Now we have a Hass CNC machine center, much better...

Ari Presler is a really smart guy and he has a sharp sense for business.
At the beggining I was heading for FPGA compression at the camera head level.Ari decided to go for the X86 software, so he can get technical and commercial support from Intel and Cineform and even having the option of Adobe Premiere installed on camera so you can use the camera for editing, Ikegami style.
The rest of things are a really long story, and I'm not in the mood right now for writing them down here.
End of story is that after several delays because of hardware limitations because of Cineform processing requirements and waiting till the arrival of Pentium-M/ Core DUO and PCI Express the camera got ready.

Right now the most simillar thing to what I firstly envisioned despite not liking its external design is the RED camera. (if you don't believe me just search for my posts all through almost 3 years).

Now my own opinion:

USB may sound nice at first, but it is an asynchronous crappy connection and with too limited a bandwidth.So we are forced to compress heavily using Theora.(8 bit limited BTW)
If we just had a way of connecting elphel 353 through PCI to a mobo and get a driver for it, we would have a whole system ready.
Instead of needing Theora compression, we could use a much easier compression scheme.I've tested myself an integer transform lossy compression based on expired patents mostly from the 70's, which is not computationally intensive and which doesn't produce blocky artifacts if compressing a bayer pattern.If I can do it, anyone out there can.That is why I was always asking for 10 bit raw bayer stuff with no success.
Need a little bit more compression with unnoticeable losses? You could also apply some ideas I posted here when discussing a codec with D. Newman long ago.
If Theora works on the elphel camera, this one will also.
Of course the codec SHOULD be open source so anybody out there can implement it on anything from VFW, DShow,Quicktime.So no worry about NLE support.
The old and hated PCI bus gives us at least 100 MB per second to play with so, we can send from the camera head two streams (if necessary) one is the full resolution compressed bayer and the other one could be a quarter resolution 8 bit per color channel image which wouldn't need debayering and could also be lightly compressed so to be sent to viewfinder.
Let's say Elphel 353 costs 1800 dollars, and a NanoITX which is 12cmx12cm ( 4.5 inch) goes for 400.
For 400 dollars you get everything you could need.Two VGA outputs one for Viewfinder, 3D glasses or whatever and the other maybe an external Monitor, TV encoded output (PAL or NTSC), HDTV output.Several audio inputs and outputs and the option of compressing them on many different codecs.
You don't need the biggest CPU for this tasks.
Want to use NTFS, HFS+,EXT3 ? you have it. You can install a full LINUX.
Want to use RAID X, so to avoid any posible data loss? You have it.
Want to output a DV stream through Firewire at the same time? You probably can.
Any thing you can do with a PC is at your hand.
Want to customize your camera because you know C programming? Go Ahead!!! If anything goes wrong just reinstall the software and you are ready.

As final words: This configuration isn't in fact a lot different from what SI camera is.It is just much more flexible and powerful

I hope my thinking is clearly expressed.Because I'm not a native english speaker I'm sure I made a lot of mistakes.

Thanks for the detailed answer Juan. Our projects have much in common (Elphel, fpga lossless encoder) but they're still fundamentally different at the same time.

As for PCI, the gerber files will be available so if someone has the intention it's fairly easy to design a PCI interface, make some boards and then plug one into the ITX, write a driver and a recording software for it, maybe a Premiere plugin for the proprietary format and go.

What I'm planning is much more simple: write an fpga encoder, disable the camera's streamer and replace it with a hard disk recording sw which can be controlled through USB by a numeric keypad and put a minidv camera beside the Elphel to function as a viewfinder. And I need a Premiere plugin to process the recorded data but I've already written that.

I don't think that one of the projects should stop. Neither of them are futile. I think that the more people, the more projects are involved in modifying the Elphel the better the chance that someone will come up with a usable result, so I'm glad that you too are working on it. Moreover, if we have two types of encoders for the fpga then we can test both of them and choose the better of the two.

The planned price won't be much different than the 333 which is around $800.

I'm not sure about that. The ITX boards have a fairly limited CPU performace compared to the desktop ones and if you push huge data in through the PCI bus although you have the chance to record it without involving the CPU but if you want a real-time viewfinder image then you must do a lot of computations on the fly. If you're going HD then you might find the ITX boards too weak. Have you got any test results so far?


Zsolt