If it works as expected, then it will be open.

I think we can manage that, that's what I'm also planning to do. But we have to keep in mind the processor's bandwith issues when dealing with two streams simultaneously.

Well, I'm sure we'll have 2:1 but not sure it will be enough for actual recording. I'm curious just as you are, probably, as I've never seen a raw bayer stream in my whole life...

Didn't mean to offend you. Actually I see nothing wrong in what you say but I fear that others might overestimate the things that I do.

Zsolt

Excellent. If there is any way I can help with this, I will.
Yep, I'm really hoping it has enough horsepower to do both. Do you happen to know how big of a hard drive it will support? One of those 750GB drives would be cool, or perhaps a 1TB drive when they come out in a few months :-)
From my calculations, 2:1 should be just fine, unless it overloads the CPU. Also, I can provide you with some raw bayer images, though it may take me a few days to pull it together.

Thanks!

I've uploaded a single raw frame here: https://sourceforge.net/project/show...ease_id=452036

Thanks Zolt.

I think testing the effectiveness of the JPEG compression on an grayscale of the bayer mask should be tested to see how well bayer interpolation holds together, with adjustments made to the compressors parameters. The main parameter to test is the quantisation phase (? I forget, the phase when they divide down the pixels to even them out to make them more compressible). A maximum of 3:1 compression, would probably be best. it would probably be near lossless at the most, and nowhere near as good as a bayer compressor. But ti would be better for existing camera owners. Very simple intra frame compression then could be added, as was being designed elsewhere.

Rob, a lot of those drives are power hungry and big, so select carefully.

I would like to move in different directions than doing anything camera/codec development related, but I am interested in your bayer footage. if you could post 10 second scenes and bayer format information that would be useful? A simple scene, simple shooting, an complex movement but simple scene, and a complex scene and complex movement. This would provide good test subjects for codec performance. I'm itching, but have too much else I should be doing.

Sure, I was just thinking that the 16-bit mode of JPEG compression would help to preserve the high bit depth, despite the quantization step.
Sure, but a drive is something you could easy swap depending on the particular application. For a studio camera on a tripod, a full-sized 3.5" 750GB drive is no big deal, as long as the noise could be kept down.
That would be useful for me as well; I'll see if I can fit it into my schedule.
I hear you! :-)

It has linux running on it so I don't think there's any limit.

What calculations? I had some calculations earlier (they're on this thread somewhere) but Andrey instantly proved some of them wrong so I decided not to calculate but wait for the test results instead...

Thanks. Actually I've seen single raw images before, while I was building my own camera but was unable to get a continuous stream of images.

There are some simple but good ideas here: http://www.silentpcreview.com/

...and for me and probably for Juan here as well (altough we don't know his intentions with those raws). The three types of videos Wayne mentioned would do just fine. Hope you find some time to record them.

Zsolt

I saw the figure 15 MB/sec, and calculated that a 2:1 compression ratio applied the raw frame (1280x720, 10 bit @ 24fps) would fit. Of course, if this ratio is an average, then we might have problems during particularly detailed or noisy scenes.
Thanks!
I'm sure I will. (Of course, they will probably have some nasty rolling shutter artifacts.)

Where? The theora streamer's output rate on ethernet is 70Mb/s=8.75MB/s.

Zsolt

I was referring to hard drive (IDE) performance, not Ethernet. I thought I saw the 15 MB/sec figure in this thread but I guess it was this post, which states the theoretical maximum for the ETRAX 100LX as 16.67 MB/s. I must have rounded it down to 15.

I did a bit of Googling and found this document which states that the FS supports UltraDMA mode 2 (33 MB/s).

The bandwidth required for 1280x720, 10 bits @ 24fps is 26.4 MB/second, so it may be possible for the FS to write the raw data to disk with no compression at all, or with only slight compression.

But the guy also writes that 12MB/s is the practical maximum and another guy writes that he measured 7MB/s. So I guess the reality can be between the two.

The new micron sensor has 12 bit output so it's slightly larger than that.

Andrey stated in this thread somewhere that we shouldn't expect much improvement if we write to disk instead of ethernet.

Based on all of the above, I expect something around 10MB/s and that requires 3:1 compression ratio. Anyhow, we're going to be on the edge, that's for sure.


Zsolt

True, but that's for the 100LX. The FS supports UltraDMA mode 2 (33 MB/s), so presumably the maximum would be somewhere between 14 and 24 MB/s.
I was assuming a LUT to reduce it to 10 bit. But if it turns out to be possible to handle the full 12 bits, that would be better of course.

BTW, have you looked at some of the components available on OpenCores such as xmatchpro lossless data compressor or Video compression systems?

Thanks!

And the 353 will use the FS? Anyway, Andrey knows the system better than us, so if he says "not much improvement can be expected" then I believe that. My encoder will be somewhat faster than the theora stuff, but it could well be that some bottleneck comes from the fpga itself so the processor won't be able drive the IDE interface to a maximum.

No. I don't know how easy it would be to insert a third party encoder into the Elphel design.

Zsolt

That's what I understand. You may be right about the increase in performance (or lack thereof) but I guess we'll see.

Edit -- Andrey mentions using the ETRAX FS in this post and this post and indicates that the CPU should be roughly twice as fast.

I see that Etrax FS has PCI support built in so, does it mean that you just can connect a PCI board to it or what?

Juan, I believe you'd have to design a PCI bus into your custom board; the Elphel won't have this.