High Definition with Elphel model 333 camera

Wayne Morellini · July 28th, 2006, 02:14 AM

Quote:

Originally Posted by Phil Stone

http://www.tacx-video.com/raw-demo/R...3Raw-MJpeg.avi here is something I found on this laptop. Not ideal lighting (washed out sky) & its 4:3.

Have finally got the video downloaded. Do you have anything recorded at full quality settings? This is around 23.6Mb/s, and having snapshot it in VLC and examined the stills, I can see lots of blocking and faults as you can expect in highly compressed footage. Being 1.3mp and 27fps also put further load on. Could you post something at the highest but rate at 720p and 25fps, that would be an better indication?

I take it that the color etc looks loverly, much better than some footage I have seen. I can judge the true balance between this sort of man made colours, and some grass. This Micron sensor rendition is giving it a boost, over the compression appearance, but I think that the camera has done a loverly job at compression in 23.6Mb/s.

Thanks

Wayne..

Phil Stone · July 28th, 2006, 06:33 AM

Quote:

Originally Posted by Wayne Morellini

Have finally got the video downloaded. Do you have anything recorded at full quality settings? This is around 23.6Mb/s, and having snapshot it in VLC and examined the stills, I can see lots of blocking and faults as you can expect in highly compressed footage. Being 1.3mp and 27fps also put further load on. Could you post something at the highest but rate at 720p and 25fps, that would be an better indication?

I take it that the color etc looks loverly, much better than some footage I have seen. I can judge the true balance between this sort of man made colours, and some grass. This Micron sensor rendition is giving it a boost, over the compression appearance, but I think that the camera has done a loverly job at compression in 23.6Mb/s.

Thanks

Wayne..

Not sure what you mean about artifacts, are you sure thats not the VLC player? If you zoom into a frame you can see a grid like pattern but thats not visible at full resolution. To me the video is not quite as clear as I have had with the 313 in good weather but it did the job, the auto exposure was on steroids here also, I find it better to do this by hand until I figure out all the functions of it. I think the problems with the clip are my fault & not the camera.

There is no Mpeg4 type compression thats visible as its simply a stream of 70% quality Jpegs taken at 1280x1024. The image quality of the frame will be the same as that from one of the early digital cameras set to 70% but here there are 27 of them each second for about 3hrs!

Ive never managed to film at 100%, I do have some nice 85% quality film from the Alps with a fisheye. http://www.tacx-video.com/images/HD2...assic-HD/DV-HD There are also some crap looking Canon GL2 images in the same spots for comparison.

Wayne Morellini · July 28th, 2006, 10:49 PM

100% is probably the only mode we should be looking at. The percentages are not representative of compression ratio, 100 is far off 1:1 (but how much?). 85% might be good, but I would have to see the compression ratio.

So, you would have to go better than DVCPROHD's 6:1, and 4:1 or better (like 2:1) is preferably.
If you frame for 1280*720 @25/24fps, it would be interesting to see how high you can go in quality modes.

It has to do with maximum throughputs of the compressor and data path/transmission independently. By lowering frame rate and screen size, you reduce the capacity used, possibly, allowing a higher quality mode to be used.

I was viewing a snapshots from vlc in the normal windows picture viewer, and there were no grids but inaccurate blocks of pixels. Snapshot a number of frames through out the sequence, they should turn up in pictures folder. Zoom into the road surface and you will see disjointed pattern of blocks with lines and shapes in them, look around the car lights and rides suits colored patterns as well. This video has a lot of plainish surfaces, which could have boosted compressibility of ones with details quiet a bit.

MJpeg gets artifacts as well, because it is not lossless, and maybe even not visually lossless, though that might be the 100% mode. At 23.6Mb/s, it is less than DV's 25mb/s, and much less than DVCPROHD. DVCPRO gets true SD pro quality at 50Mb/s, which is somewhere around 3.1:1 (I think) and Digital Beta got around 2.3:1 at 80+mb/s I think (long time since reading up on these).

You can understand why I dropped out of the current generation of cameras and am waiting for the future models, my heart is in close to visually lossless territory or more. If it can't produce quality better than AVCHD, then I am not bothered, if it can produce DVCPROHD quality I am mildly interested (takes substantial time and effort setting up and coping with a custom rig). If it can exceed it, then it is worth and the target is the next 100Mb/s H264 frame based Intra codec, which you will be able to match by doing an inter coding format at 100mb/s. As far as MJpeg, the advantage is really if you can run 720p at 100Mb/s, which is pretty high in quality compared to what DVCPROHD will, normally, let you run at (due to being locked into lower resolution/data rates for low screen formats etc from my understanding).

Wayne Morellini · July 28th, 2006, 11:39 PM

I had a look at those stills, did you shoot them in 640*512?

The 512 ones, which I guess you must mean are not the GL-2 ones, look substantially better (but this is a lot to do with the way the cameras render the image) but there is still attracting there present. In web graphics I think the rule is to use 100% quality (but rather use GIF's etc) I definitely found a substantial drop off below 85% in testing.

I notice that one camera has a low compression ratio than the other, reflected in the image.

But it is hard to get a comparison here, because they are shot in two different resolutions, and the canon frame is not a native straight frame, so recompression comes into it. If you shot in hi res and then down scaled the Elphel footage you automatically also get some advantage. Have you got the native un-retouched frames?

Definitely makes the GL photos look second rate.

Can you soot 85%+ at a higher resolution than this, like 720/25p?

Wayne Morellini · July 29th, 2006, 01:29 AM

http://www.theinquirer.net/default.aspx?article=29927

Surprisingly cheap, the sort of thing that could go into the 353.

Andrey Filippov · July 29th, 2006, 09:38 PM

Quote:

Originally Posted by Wayne Morellini

http://www.theinquirer.net/default.aspx?article=29927

These are CF and USB2, 353 need IDE - I meant http://www.seagate.com/docs/pdf/data...c/ds_st1_3.pdf - yes, they will fit into the small body. Other option - use much larger capacity laptop drives in a bigger housing

Andrey Filippov · July 29th, 2006, 09:40 PM

Quote:

Originally Posted by Wayne Morellini

What do you think of this 3D Wavelet, that is being used in Surveillance and other industries, is it any good?

Did not work so far with any wavelet compressors. They need somewhat more computational power - I'm waiting for 65nm Spartan 4.

Andrey Filippov · July 29th, 2006, 09:46 PM

Quote:

Originally Posted by Wayne Morellini

: Is 4:4:4/4:2:2 in this camera Andrey?

No currently it is 4:2:0 - If you need 4:4:4 (sensors are anyway Bayer) you can compress as if monochrome and then do color post-processing on PC. 4:4:4 requires up to 3 times the bandwidth to send interpolated data. 3MPix sensor is 2048x1536, not 3x2048x1536.

Andrey Filippov · July 29th, 2006, 09:48 PM

Quote:

Originally Posted by Wayne Morellini

Does this sound doable?

we'll see :-)

Wayne Morellini · July 29th, 2006, 10:17 PM

Quote:

Originally Posted by Andrey Filippov

These are CF and USB2, 353 need IDE - I meant http://www.seagate.com/docs/pdf/data...c/ds_st1_3.pdf - yes, they will fit into the small body. Other option - use much larger capacity laptop drives in a bigger housing

It is about the cheap Micro drive pricing, with CF version of the IDE Seagate drive the cheapest. This article linked from article on IDE Seagate.

Re-edit: Forgot to ask, what pixel formats does the Elphel do Mjpeg in, just 4:2:0 and monochrome?

Wayne Morellini · July 29th, 2006, 11:28 PM

Quote:

Originally Posted by Andrey Filippov

No currently it is 4:2:0 - If you need 4:4:4 (sensors are anyway Bayer) you can compress as if monochrome and then do color post-processing on PC. 4:4:4 requires up to 3 times the bandwidth to send interpolated data. 3MPix sensor is 2048x1536, not 3x2048x1536.

Thanks for answering the questions Andrey. The monochrome image conversion looks good, how well in compression does that compare in MJpeg and Ogg?

I mentioned a way to convert the bayer data into a normalised colour image before (I think through pixel by pixel conversion to make the color closer together for compression). But you can normalise the whole bayer pattern to one colour or full monochrome, at once, you then have a much smoother, more compressible image, that you can also apply more simple compression techniques to on a bit plain basis and difference compression etc, like JBIG (I think). To restore to bayer you already know the bayer pattern to reverse the process. You could do this by simply working out the normal color value from estimated difference to the pixel value itself, or through normal interpolation. (R30% and B10% Green60% etc).

There were some other schemes mentioned in the Digital Cinema Threads:
To split the bayer pattern into 3-4 separate bit-mapped images, one for each of the sub pixel RGB colors, compress separately, or do differential compression on images and compress the base image, I think cineform might have eventually did something like this (I got to read their white paper sometime). Good results were reported.

Second alternative, when 3864 wide sensor, through interpolation (to stop fly screen image problems) can extract 1280*720 bayer image, then compress and send that?

Thanks

Wayne.

Wayne Morellini · July 29th, 2006, 11:31 PM

I forgot again:

I have been meaning to ask, is there anyway to feed in a compression routine, or formulae into the Elphel, without having to learn FPGA code to do it?

Thanks

Again.

Andrey Filippov · July 30th, 2006, 12:22 AM

Quote:

Originally Posted by Wayne Morellini

I forgot again:

I have been meaning to ask, is there anyway to feed in a compression routine, or formulae into the Elphel, without having to learn FPGA code to do it?

Thanks

Again.

No, I don't see how you can do that - it is in the FPGA code.

Wayne Morellini · July 30th, 2006, 10:50 AM

What are the existing results from monochrome compression, what data rate/low compression ratio is possible?

I have been mining for gold in the webpedia, and things are a bit confusing (as you can understand). From the pedia Jpeg is 24 bits per pixel, is this so, or is it 4:2:0, or 4:2:2, in MJPEG? They also mention 12 bit color for Jpeg, is, that supported in monochrome, or colour modes?

This seems very interesting for us, because 100Mb/s is under 2:1 720p, or 4:1 1080p in monochrome bayer, well and truly in quality territory, even with 10-12bits, it is still looking good for 720p, providing compression holds up. Colour accuracy under bayer compression will suffer a fair bit unless very low compression ratios are used under Jpeg (so 720p would be the sweet spot at 100mb/s). Using the alternative techniques mentioned before would perhaps do that at higher compression.

I've got to be such an idiot to miss this.

Anybody willing to give this a burl on the existing 333, to see what the results are on it's (was that 70 or 30mb/s) datarate?

Ben Syyverson had a debayer I think, but no longer has it listed there:
http://web.archive.org/web/*/http://...gins/linbayer/

http://www.google.com/search?q=linba...ls=en&filter=0

He might still be around to contact. Here is some interesting links on debayering for people:

http://www.insflug.org/raw/software/tools/dcraw.php3
http://www.path.unimelb.edu.au/~ders...erpolator.html
http://www-ise.stanford.edu/~tingchen/

Thanks Andrey

Wayne.

John Wyatt · July 30th, 2006, 01:20 PM

Wayne -- I tried to find a contact for Ben Syverson to buy a copy of his linbayer (After Effects plug-in). Google turned up nothing new, but Ben had a plug-in called dvMatte (a keyer not a debayer) advertised on a video website (www.dvgarage.com). I emailed them (info@dvgarage.com) to ask if they could give me a contact for Ben, or forward my request about linbayer to him, but no reply after about a month now. All leads to Ben seem dead...
John.

July 29th, 2006, 01:29 AM	#215
Wayne Morellini Inner Circle Join Date: May 2003 Location: Australia Posts: 2,762	Microdrive pricing: http://www.theinquirer.net/default.aspx?article=29927 Surprisingly cheap, the sort of thing that could go into the 353.

July 30th, 2006, 01:20 PM	#225
John Wyatt Regular Crew Join Date: Jan 2006 Location: West Country, UK Posts: 141	linbayer Wayne -- I tried to find a contact for Ben Syverson to buy a copy of his linbayer (After Effects plug-in). Google turned up nothing new, but Ben had a plug-in called dvMatte (a keyer not a debayer) advertised on a video website (www.dvgarage.com). I emailed them (info@dvgarage.com) to ask if they could give me a contact for Ben, or forward my request about linbayer to him, but no reply after about a month now. All leads to Ben seem dead... John.

July 28th, 2006, 10:49 PM	#213
Wayne Morellini Inner Circle Join Date: May 2003 Location: Australia Posts: 2,762	100% is probably the only mode we should be looking at. The percentages are not representative of compression ratio, 100 is far off 1:1 (but how much?). 85% might be good, but I would have to see the compression ratio. So, you would have to go better than DVCPROHD's 6:1, and 4:1 or better (like 2:1) is preferably. If you frame for 1280*720 @25/24fps, it would be interesting to see how high you can go in quality modes. It has to do with maximum throughputs of the compressor and data path/transmission independently. By lowering frame rate and screen size, you reduce the capacity used, possibly, allowing a higher quality mode to be used. I was viewing a snapshots from vlc in the normal windows picture viewer, and there were no grids but inaccurate blocks of pixels. Snapshot a number of frames through out the sequence, they should turn up in pictures folder. Zoom into the road surface and you will see disjointed pattern of blocks with lines and shapes in them, look around the car lights and rides suits colored patterns as well. This video has a lot of plainish surfaces, which could have boosted compressibility of ones with details quiet a bit. MJpeg gets artifacts as well, because it is not lossless, and maybe even not visually lossless, though that might be the 100% mode. At 23.6Mb/s, it is less than DV's 25mb/s, and much less than DVCPROHD. DVCPRO gets true SD pro quality at 50Mb/s, which is somewhere around 3.1:1 (I think) and Digital Beta got around 2.3:1 at 80+mb/s I think (long time since reading up on these). You can understand why I dropped out of the current generation of cameras and am waiting for the future models, my heart is in close to visually lossless territory or more. If it can't produce quality better than AVCHD, then I am not bothered, if it can produce DVCPROHD quality I am mildly interested (takes substantial time and effort setting up and coping with a custom rig). If it can exceed it, then it is worth and the target is the next 100Mb/s H264 frame based Intra codec, which you will be able to match by doing an inter coding format at 100mb/s. As far as MJpeg, the advantage is really if you can run 720p at 100Mb/s, which is pretty high in quality compared to what DVCPROHD will, normally, let you run at (due to being locked into lower resolution/data rates for low screen formats etc from my understanding).

July 28th, 2006, 11:39 PM	#214
Wayne Morellini Inner Circle Join Date: May 2003 Location: Australia Posts: 2,762	I had a look at those stills, did you shoot them in 640*512? The 512 ones, which I guess you must mean are not the GL-2 ones, look substantially better (but this is a lot to do with the way the cameras render the image) but there is still attracting there present. In web graphics I think the rule is to use 100% quality (but rather use GIF's etc) I definitely found a substantial drop off below 85% in testing. I notice that one camera has a low compression ratio than the other, reflected in the image. But it is hard to get a comparison here, because they are shot in two different resolutions, and the canon frame is not a native straight frame, so recompression comes into it. If you shot in hi res and then down scaled the Elphel footage you automatically also get some advantage. Have you got the native un-retouched frames? Definitely makes the GL photos look second rate. Can you soot 85%+ at a higher resolution than this, like 720/25p?

July 29th, 2006, 11:31 PM	#222
Wayne Morellini Inner Circle Join Date: May 2003 Location: Australia Posts: 2,762	I forgot again: I have been meaning to ask, is there anyway to feed in a compression routine, or formulae into the Elphel, without having to learn FPGA code to do it? Thanks Again.

July 30th, 2006, 10:50 AM	#224
Wayne Morellini Inner Circle Join Date: May 2003 Location: Australia Posts: 2,762	What are the existing results from monochrome compression, what data rate/low compression ratio is possible? I have been mining for gold in the webpedia, and things are a bit confusing (as you can understand). From the pedia Jpeg is 24 bits per pixel, is this so, or is it 4:2:0, or 4:2:2, in MJPEG? They also mention 12 bit color for Jpeg, is, that supported in monochrome, or colour modes? This seems very interesting for us, because 100Mb/s is under 2:1 720p, or 4:1 1080p in monochrome bayer, well and truly in quality territory, even with 10-12bits, it is still looking good for 720p, providing compression holds up. Colour accuracy under bayer compression will suffer a fair bit unless very low compression ratios are used under Jpeg (so 720p would be the sweet spot at 100mb/s). Using the alternative techniques mentioned before would perhaps do that at higher compression. I've got to be such an idiot to miss this. Anybody willing to give this a burl on the existing 333, to see what the results are on it's (was that 70 or 30mb/s) datarate? Ben Syyverson had a debayer I think, but no longer has it listed there: http://web.archive.org/web/*/http://...gins/linbayer/ http://www.google.com/search?q=linba...ls=en&filter=0 He might still be around to contact. Here is some interesting links on debayering for people: http://www.insflug.org/raw/software/tools/dcraw.php3 http://www.path.unimelb.edu.au/~ders...erpolator.html http://www-ise.stanford.edu/~tingchen/ Thanks Andrey Wayne.