I'm still interested to know how that video phil posted was so lacking in rolling shutter artifacts. On a similar note, ive been playing around with my sumix camera again (same micron sensor as the 333) and rolling shutter artifacting is hugely reduced by turning the camera 90degrees. I imagine this has been discussed before but its an interesting option for those interested in avoiding rolling shutter issues. rolling shutter is reduced in two ways by this: normal orientation causes artifacting on horizontal pans and rotated orientation replaces this with vertical pan artifacts which in my opinion are less common and less likely to be quick pans, and because the shorter lines are being exposed, the actual time difference between the exposures of adjacent lines is reduced because vertical resolution is (1.33, 1.77, 1.82, 2.4 or 2.66 times) lower than horizontal on normal video, so the artifacting is that many times less. of course this leaves you with a sensor with a width equivalent to a 1/3" sensor instead of 1/2".
anyway, i figure it might be worth throwing in the ability to record rotated images for people interested in minimizing the effects of rolling shutter. there are also plans to support kodak ccd's right? for which rolling shutter wouldnt be an issue, right?

So, it does not maintain a constant data rate like most video formats? This is an problem because frame timing is the most important thing, not maintaining max data rate at the expense of timing.

Yeah, I bought this up on the digital cinema camera threads a few years ago, but the problem you should get is line flashing, as details move while lines are being scanned horizontally.

Whats the Q10, Q4 again, late can't remember back far enough?

An good attempt on the images. Had a close up of the pictures, and there is some color shift, a lot is slight and it looks natural. Some is like the debayered spectral highlights, and probably can be fixed up with the same software, but few of them. The resolution looks blurred, like on an cinema screen, but it does look similar to 4 times less resolution. Even in codecs like cineform, you still notice some of this, probably not as much, but still noticeable. I noticed some blocks in the lower right of the house, but did not notice much. This is probably not far off what an high end compressed ENG camera could achieve. Forgot to mention, the blur has virtually totally nuked the noise in the frame.

I would be curious how an grey-scaled bayer image debayers after going through an high 100% grey scale Jpeg compression.

It is possible to have the fps constant but it could be somewhat confusing in the current interface so we will make it easier to use.
Currently you can:
1 - limit fps to certain value (even if camera can run faster)
2 - limit maximal exposure (that autoexposure can set) to a certain value - if it is set equal or lower than the frame period - fps will not change.
We'll make that (with default settings -possible to disable) if a streamer is running autoexposure will be limited to a frame period.

Q10 and Q4 is the quality of jpeg, photoshop 6 range from 0 to 12, so 4 is pretty bad (a lot of blocks) and Q10 is very nice (almost no artefacts). I included the after-compression raw files in the same directory, just browse it.

I'll take a look, but for me, it looks very worthy to separate each plane for compression, because when debayering you'll do some interpolation which will filter some noise. So it' should be better to introduce noise before filtering than after :)

It would definitely make sense to organize information in a wiki - this thread seems to be too big :-)
On page 33 I described how we dealt with compression of raw (before de-bayer) images in our model 323 cameras. In 333 this code might be broken but we'll have it again in 353/363

I think the ogg Mpeg4 version could be made to be a constant bit rate but most Mpeg4 streams like Xvid & DivX are variable between limits. With the mjpeg version it is what it says on the can, Jpegs! early versions of the camera would output jpeg frames into a folder via Mencoder. You then just imported these into Vegas or Vdub to convert into a avi that you could watch & edit. Every frame has a different size depending on your settings. You can adjust the settings so the quality level is low & that the camera holds a set frame rate. I pick a frame rate a little lower then max to give the camera some leeway if the scene becomes too complex.

Maybe the reason for the lack of rolling shutter effect is the frame rate is just 12fps. Its got time to take a full photo image like a normal digital camera. I think if you go a little faster to about 15-20fps you may see the effect. Then again Ive not noticed it with the 333 in any of the films Ive made. The 313 did when it was 1280x1024 & 15fps it was like a fluid effect. When the frame rate was increased to 22fps it was almost gone.

http://www.tacx-video.com/Elphel/Elp...r-Belgium3.avi Another clip (right click & 'save destination') Its 43mb & has a little bit of the medieval cloth hall in my town & some cars.

Yep, remember now, the Q4 is probably responsible for the detail loss on all the wood against blue sky. I think that an average even max Q for all colors will keep better image. Sacrificing on one or two colors means less precise interpolation for green in that position and vice a versa. I know we can't get 100mb/s at the moment, but 720p = around 192mb/s, which would be around 2:1 compression, if it was available, good to retain an lot of accuracy. But, around 3:1-4:1 is probably a satisfactory target. Maybe it could be systematically tested at 2:1, 3:1, 4:1, and 5:1, to see how it downgrades (with even Q across colors).

Odd, I have just received my Neonode, looks like it is an N1m, but still checking.

Hello!

I was disappeared in recent weeks because I've been busy shooting my first film - unfortunately with a rental camera. It was a Sony F350, not a bad one but I'm still waiting for the Elphel because in the summer we'll start our next project and I wouldn't like to shoot it with a rental camera again.

Lots of good ideas have popped up on this thread in the meantime. I'm glad that more and more people are involved in this project so I don't have to do all of it myself... As for my parts, I'm still sticking to the fpga implementation of the BloodSimple(TM) codec I described months ago. I'll soon test its performance with the raw (?) material (video?) someone posted here if that's still available, and then report the results.

Andrey, you're probably already testing the 353. Our original plans were using 1270x720 and that setup needed 13MB/s output data rate with 10bits (without LUT) and 2:1 compression. Can the camera transport this amount of data to the hard disk?

I'm thinking in 2:1 because that's the worst case scenario for this codec. In most cases the ratio will be around 2.5:1, but if we want to design with that we need to have some memory buffering for the harder-to-compress parts. The encoder itself will be lightning-fast because I plan to use multiple instances of it working in paralell so I'm more concerned about the other parts of the system. Andrey, how this part of the memory architecture works?


Zsolt

I'm still confused as to how phil's videos have no rolling shutter artifacts, especially at 12fps. My understanding of the rolling shutter is that the cmos sensor takes the entire frame length to begin integration, so the last line doesnt begin integrating (exposing) pretty much until the first line is already done integrating for that frame. The only way to avoid this is through vertical blanking or framerate decimation, which are not options when you are running at the highest pixelrate and largest frame size of the sensor. So whats going on here? When I take 12fps videos at full frame with that micron sensor, the whole image is skewed even with the slightest movement.

Noah, I've just watched the Elphel-Test-Ieper-Belgium3.avi video and it is definitely skewed. In the first half there's not much to see because there's no horizontal movement (altough there's some unreal distortion of the buildings running out on the right) but look at the cathedral when the car turns. Hopefully we won't have any of those with 1/60 readout speed instead of 1/12.

Zsolt

Maybe it's just that I'm used to playing with my camera tethered to my computer in a small room where things are very close and I am using a longer lenses so movement is much greater so the skew seems much worse.

Noah, the rolling shutter is very bad, as bad as can be... but at some frame rates, it is almost gone. I have to right down what setting are best.

-

I've just ordered my new laptop. The 333 is doing fine on my Intel Celeron 1.GHz with 1 gig ram, so it can only get much much better. I'll have a core-2 dual processor, 2 gig ram and a fast NVIDIA graphics card.
I hope I can record with a higher Jpeg compression and no frame drops. I have successfully recorded at 90% Jpeg quality, but most of times it'll result in frame drops.

I'd still like to install Linux to the hard drive next to Windows, but I found lots of discussions on the internet with people having trouble with the Knoppix liveCDs installed to disk. So... should I install a Linux version dedicated to hard drive installation? Would it be difficult to get all the software right to use the Elphel on something else than Knoppix?

HI,

I've been following this thread for a couple of weeks and it looks really interesting. Anyway, I downloaded the Elphel-Test-Ieper-Belgium3.avi video last night and it won't play on my WMP 10. I tried downloading several codecs including theora and 264 but still won't work. What am I missing? MJPEG? Is there a free one?

By the way, am I the only one that thinks ethernet would be a greater standard for camcorder output in the future than HD-SDI and many of those others? Imagine a field recorder with an ethernet input for instance. Seems like wireless video transmission between a camera and recorder would also be easier to setup too.

Also, I wonder what would be the problem with creating live switching using ethernet? Have a switcher with 4 to 8 inputs bringing in some of these cameras like the Elphel 353 and switching them live and recording the output on the ethernet field recorder (or whatever).

Would ethernet be realtime enough to keep up with the demand for completely smooth, uninterrupted video with no glitches? A recorder wouldn't be much problem because you can smooth things out with buffers, etc. But a realtime switcher demands uninterrupted video streams to mix together, add titles and key and put the mixed result out for recording or broadcasting so any holdup in the packets coming across wouldn't give good results.

Thanks

I did some tests this evening with a vanilla letus35 on the 333. The results are too soft and a bit disappointing as far as what i would expect from HD. I closed the iris a bit to try to get more sharpness out of it, but i don't think any of the optics I have are designed for high definition imaging.

333
-exposure 40
-saturation 2
-sensitivity 2
-2000x800@85
-24 fps

Minolta 50mm f1.8 slr between f2.8-f5.6
letus35
333 zoom lens f1.8 @ f2.8

http://www.buysmartpc.com/333/letus/qt.jpg
http://www.buysmartpc.com/333/letus/tyl.jpg
http://www.buysmartpc.com/333/letus/v8.jpg

(bumped up saturation to 3 for test)
http://www.buysmartpc.com/333/letus/s3.jpg

I don't think im getting the full potential of the camera. I would really like to see some tests with a high quality c/cs lens, and a SGpro for conclusive results.

rolling shutter
 

I think someone owning a 333 should experiment with the shutter speed: setting a smaller image size and going 24fps with 1/60 shutter and do extreme horizontal pans or filming cars running across the viewport. It would be interesting to see (or not see) the skewing.

Zsolt

Daniel ...why are you disappointed by the result of the letus?!? ...I think that are far better from the one of every sd camera and you haven't used a good lens! let's show us some more pics and movie if you can

yes, i agree its far better then SD. I overstated by saying im disappointed, the images are satisfactory.

I neglected to show the worst of the batch.

http://www.buysmartpc.com/333/letus/txt.jpg

I think the text should have resolved better. Its easier to read once you sharpen them in post but this is something im trying to avoid.

This runs from CD? There are programs that reproduce the Disks on hard drive, so it can be run from hard drive instead of from disk.

Richard, I am sure Andrey can answer these questions better than I, and has security multiple feeds planned. Compressed is not to bad, except the compression delay, but for uncompressed even GigE maxes out an long way before 4:4:4 108025p feed. What would be needed is 10Gbe for an limited number uncompressed packed HD 60p feeds, or 100Gbe (for future backbone of many SHD and UHD feeds).

I like the sound of that. Unfortunately, 1Gbe hasn't even rolled out en masse yet.

He, He, it is just that people get by with 100/10, so it hasn't been so widely adopted on the consumer end. 10 GigE is out, and preliminary 100 GigE might be defined. Here is some main boards with ten * GigE ports you might like.

http://www.win-ent.com/fullcatalog.htm
http://www.win-ent.com/IP-06049.htm
http://www.win-ent.com/PL-01033.htm
http://www.win-ent.com/MB-09015.htm

Wayne,
You mean a virtual drive? But could you boot from a virtual drive? Do I need a boot manager or something? It's really something I'd like to do, because an OS from CD or DVD is very very slow.

I don't know if they called it an virtual drive (can't even remember the precise definition of an virtual drive these days). It gives me an idea, if an program like that can put the image into an ram drive instead, and run it from there, would that increase performance again, or would that get in the road of Windows virtual memory paging scheme?

As far as i know, running OSes from disk images mounted in virtual disks or ram disks only works if you are talking about booting virtual machines which involves running a guest OS inside of a host OS, each of which take plenty of RAM and in which the performance of the guest OS is usually diminished. There are versions of live CD linux that copy themselves into RAM first (requires 1GB+ of RAM), however, but boot times are pretty long from copying all that stuff from the liveCD. the elphel application doesnt require knoppix does it? Knoppix that boots from USB flash memory does exist, which could be a lot faster and lower profile/lower power than CD. There has got to be a way to run knoppix from a hdd installation, and a way to run the elphel software on something other than knoppix. Right? I guess I'm not familiar with how the software is packaged.

Hi Daniel can you tell me what type of cs/c mount lens did you use and the distance from the adapter!? did you use an achromat!? many thanks and amazing result!

Here is a picture of my setup. I believe the spacer (pvc) is about 6" long

http://www.buysmartpc.com/333/333.jpg

Do you think they really handle the full bandwidth of 10 separate 1gb ethernet channels like that? That would be amazing if they really could and still carry on a decent amount of other processing tasks including disk i/o, signal processing, etc. Or maybe one of those boards would just be the front end and another board would do actual processing of the signals.

Sorry for the delay, my system toast last weeek, and drive and backup this week. So, I might not be around much, using internet place at moment.

I don't know, it depends on hwo the hardware and software is setup. Functions canbe very automated in hardware with GBE and good drivers. But on averaging, maybe they expect most of the tiem the load to be 50% or even less. But when you think of the possibilities for networked security cameras with tehse things, with all the secutity streams combined into GigE streams coming in, poretty impressive. I imaging that server applications is there main focus, here an really big cachem and ram caching on disk, can help things.

is there any OS X solution?
 

I'd like to build a simple quicktime capture compatible solution for this camera. Is this possible?

We had a problem with Quicktime player for the other OS - we could not get rid of 3 second latency. It is perfectly OK for viewing Internet streams, but is not good for live video. I believe there are versions of MPlayer that run on OSX. Some patches may be needed (same as on Linux) to increase the maximal window size

Andrey, is it possible to install a Linux version that is dedicated to hard disk installation (I read knoppix is really not suited for that) and install all the necessary files for the Elphel 333?
I don't know Linux very much (only from the Elphel LiveCD) so I don't know if it's easy to get the Elphel to work on another Linux distribution...

Oscar,

Spectr (at our company dot com) is working on it. There are several issues to be resolved.

First - you need a customized version of MPlayer and live555 library - they do not support the big frames we need. And there is also a fundamental problem with RTP for MJPEG - RTP header information limits frame width to 2047 pixels (with our hack 0 is treated as 2048). RTSP allows virtually any frame width (while frame data itself is still sent over RTP.

Second - we need Genres Mozilla plugin for MPlayer and we plan to simplify it installation (it now uses compiled code, Perl and Python - too many dependencies). Without that plugin it is still possible to view the video, but not inside a web interface window.

That's good news. Is Spectr too busy to discuss it here on the forum? I wish I had more knowledge on these issues...

Hi to all I've one question about the new 353...
is it possible with the model with the hd to save a video file without a pc running the live cd? if so what kind of hd is needed a 7200rpn or a 5400 is enough
and last, 353 run with 3.3V power is there a limit for the ampere? so if i plug the camera directly to an external battery are there a limit for V and mAh of the battery?
many thanks Matteo Pozzi
ahh and happy Easter

Matteo,

The 353 camera consumes around 3W (same as 333), the internal 48V->3.3V DC-DC converter is 8W so at least 4W (to be safe) should be available for HD. And as it has USB port(s) it should be possible to attach some hand-held directly through USB to control the camera functions and build a complete DIY video camera - no computer will be needed for operation.

On the firmware side - as I wrote before, while porting the 333 code we also update drivers to simplify sensor and compressor control from the PHP scripts - that seems to work nicely and will simplify custom interface software development.

Right now I'm working on an article for LinuxDevices that will have more info on the 353 camera. I plan to finish it in several days so it should be online soon.

Ok to use an image?
 

I have a question for Daniel - is it OK to use his cool image

http://www.buysmartpc.com/333/333.jpg

in the LinuxDevices article? I'm going to write about this forum and that picture is a very nice demonstration of DIY camera development.