High Definition with Elphel model 333 camera

[Andrey Filippov]

Originally Posted by Wayne Morellini

I found nothing but trouble trying to run camera4.elphel.com . I get one photo with box and one web page that says loading.

Wayne, there might be problems connecting to these cameras - interface is all open and visitors sometimes leave it with some weird settings - I need to make some simple script to periodically reset it to some known state.

What browser did you use when you've seen only "loading"? Interface is designed now only for Mozilla Firefox, but I've heard that with Opera it also works.

[Andrey Filippov]

Originally Posted by Noah Yuan-Vogel

I'm impressed with the color and ease of use of this camera, and I know it can create sharp images using a nicer lens since i am using the same sensor. what kind of IR filter is being used? is it all built in?

It is dielectric filter (t=0.3mm) and it is glued in. We can machine a version of the front-end piece (a little shorter to compensate for the optical length difference) - it should be rather easy to replace.

Originally Posted by Noah Yuan-Vogel

Otherwise what im really interested in is the quality of the mjpeg compression, what is the least compression it can apply?

any standard JPEG up to 100% quality - virtually lossless (all quantization coefficients equal to 1.0), but in most cases it will not work because of the limit in the network bandwidth. Maximum what we've got with the ETRAX100LX is about 70 mbps - that will increase with the new processor.

Originally Posted by Noah Yuan-Vogel

all the way up to the ~7MBps that 100BT can handle? that was a little unclear. Another really important thing is how is the framerate control? accurate? you really need an accurate and consistent framerate for sound sync. Also does it give you control over vertical blanking to keep rolling shutter artifacts under control?.

Yes, it is possible. When you set up fps limit, it adds vertical blanking to match the frame period. Frame rate is not very precisely set - up to integer number of lines, but we now have a project where we need much better - so it will be done. Currently I added precise timestamping of the frames (to one microsecond), but we still need to make some software interface to it.

Originally Posted by Noah Yuan-Vogel

significant rolling shutter artifacts in fast horizontal pans.

This I strongly beliebe can be solved with the software post-processing, especially if distortion is related to the camera pan, not the object moving. It can use similar algorithms as used when the frames are interpolated when changing from 24 to 30fps (or opposite). Each line is exposed at exactly known time, so it is possible to interpolate between the two frames.

[Wayne Morellini]

Originally Posted by Andrey Filippov

Wayne, there might be problems connecting to these cameras - interface is all open and visitors sometimes leave it with some weird settings - I need to make some simple script to periodically reset it to some known state.

What browser did you use when you've seen only "loading"? Interface is designed now only for Mozilla Firefox, but I've heard that with Opera it also works.

Opera, I didn't even know anything about controls, just saw a picture in the pop-up, and some sort of bordered region in that.

[Wayne Morellini]

Obin adjusted more then frame rate to reduce rolling shutter. He shot double frame rate and had to adjust the other parameters of the frame timing to reduce the rolling shutter further (big tip). I doubt the Elphel is set up for any of this normally (like overclocking the sensor, compressing every second frame, and dropping the others to get the 180 degree reduced rolling shutter). It is all mentioned in the first part of Obin's thread, I asked some questions to clarify it, and is worth reading to find out what to change.


Thanks

Wayne.

[Noah Yuan-Vogel]

Yes I recall that, but when it all comes down to it, isnt it all just keeping the frequency as high as possible while capturing a certain number of pixels? I mean in terms of reducing rolling shutter, isnt capturing a 1000x500 frame with 500 vertical blanking essentially the same as capturing twice as many 1000x500 frames and throwing every other one out? either way, the frame time for the active sensor area is the same, right?

Andrey, so you are saying that the camera does at least use vertical blanking (and only vertical blanking) to control frame rate? That is a good thing at least in terms of rolling shutter, although maybe not as useful for accurate framerates.

Also, could you tell me why it is that if the camera runs at 48mhz, the max framerates listed for 1600x896 etc correspond with a pixel rate more like ~35MHz? I have had this same issue in my camera running the same sensor, is the camera clock not reliable? Or is it some bottleneck?

[Andrey Filippov]

QUOTE=Noah Yuan-Vogel]Yes I recall that, but when it all comes down to it, isnt it all just keeping the frequency as high as possible while capturing a certain number of pixels? I mean in terms of reducing rolling shutter, isnt capturing a 1000x500 frame with 500 vertical blanking essentially the same as capturing twice as many 1000x500 frames and throwing every other one out? either way, the frame time for the active sensor area is the same, right?[/QUOTE]

Approximately - yes (there is a fixed minimal blanking of 4 lines or so fro MT9T001 sensor). And current FPGA (or software) does not support throwing each other frame (not so difficult to implement).

Originally Posted by Noah Yuan-Vogel

Andrey, so you are saying that the camera does at least use vertical blanking (and only vertical blanking) to control frame rate? That is a good thing at least in terms of rolling shutter, although maybe not as useful for accurate framerates.

Driver uses the vertical blanking, not the horizontal - exactly because of the rolling shutter issues, but it is still possible to use the horizontal blanking by specifying "virtual frame" width and height directly (available in cgi interface, but not in the javascript code - easy to add). As for precise frame rate - we will implement it by skipping/adjusting pixel clock during vertical blanking. That will be done on ythe FPGA level and precision will be limited only by the thermal drift of the quartz master clock. For timestamping we already have a real time clock (it counts microseconds - 20 bits and seconds - 32 bits) and is digitally adjusted with the step of +/-0.125ppm.

Originally Posted by Noah Yuan-Vogel

Also, could you tell me why it is that if the camera runs at 48mhz, the max framerates listed for 1600x896 etc correspond with a pixel rate more like ~35MHz? I have had this same issue in my camera running the same sensor, is the camera clock not reliable? Or is it some bottleneck?

Sensors need extra horizontal blanking - you may find formulae in the Micron datasheet - PDF on their web site. And horizontal is much bigger than vertical (only 4 lines but some 200-300 pixels)

[Régine Weinberg]

Dear Wayne that's quite true
but as you are at the center there is the least distorsion.

One of my silly stupid ideas,
Why not use a mechanical shutter somebodie did it with a Dvcam once.
There are no rolling shutter artifacts, Kreins (??) I guess does it this way.

a viewfinder from a Bolex would be fine as you see what the picture will be.

otherwise is on the board any RGB out to have a small CRT connect ??

[Régine Weinberg]

I can not post so much sick with my teeths

[Andrey Filippov]

Originally Posted by Ronald Biese

otherwise is on the board any RGB out to have a small CRT connect ??

No there is none - there is no "videosignal" (and no RGB - Bayer data is directly converted to YCbCr 4:2:0 - this happens in the macroblock order in front of the compressor, not in the scan-line sequence) inside the camera so making such an output will require something similar to computer videocard.

But there is a solution - just use a separate hand-held computer with WiFi and use it as an external monitor (with reduced resolution/frame rate). I.e. Nokia 770

[Forrest Schultz]

I have thought about the external 180 degree mirror shutter. So you can also have a viewfinder image, but then i wouldnt think it would be easy to sync the movement of the shutter with the 24 fps to make sure it happens exactly how it should. And for the syncing part, i wouldnt know at all how to do that. I could easily build a 180 degree spinning shutter though.

[Wayne Morellini]

Originally Posted by Ronald Biese

One of my silly stupid ideas,
Why not use a mechanical shutter somebody did it with a Dvcam once.
There are no rolling shutter artifacts, Kreins (??) I guess does it this way.

I have seen electric shutter out there, if anybody is worried about noise power consumption or reliability.


Maybe B&H is where I saw it.


With new cameras, like the Silicon Imagine Altasens one coming out, it is easy to get distracted about the possibilities. But, even if they could reduce the price of it to less than $5K, which size would you prefer to be using, as the Elphel could be combined with a small Origami tablet unit (or PDA or linux micro-controller board) looking like an Sharp view-cam)?:

http://photos1.blogger.com/blogger/3...0/DSC_3238.jpg

The smaller JVCHD10 one is closer to the size volume that an Elphel unit can be made into ;)


Thanks

Wayne.

[Régine Weinberg]

electric shutter have been used for decades,
no problem with reliability.
Noise either.
I only do mean,
if the immage comes out with no artifacts,
you dont have to hassle in post, each step in post will alter the image a bit. It takes time, a lot of and will be boring to do the dammed work
on each rush again, again and again.
I do know what I speek from.
Was working with Inferno, Maya, Quantel way to long,
stopped just before going totally mad.
Mad anyway Madhatter you can name me.

Wayne it was a long time ago we, you and me we found ephel at linuxdevices.com, do you remeber ??? Linux bahhh nobody was
talking friendly about it....

[Wayne Morellini]

Yes.

(10 character post limit, don't they believe in short posts around here ;))

[Serge Victorovich]

Question to Andrey Filippov
It is possible record compressed RAW (similar to CineformRAW) from smos direct-to-hdd with small modification of existing architecture of Elphel333 ?
I mean solution like mentioned by Rai Orz:

Take your brain free from all PC stuffs. The A/D Unit, inside (or outside the CMOS Sensor) have 10, 12 or more output pins (each pin is one BIT). The output rate is 33-66MHz. FPGAs can handle those data speeds in realtime. Shift or translation to 16Bit words are simple works. Next part is the Harddisk. Not a controller or interface, you can write direct to disk. A HDD needs words, not bytes. There are 16Pin (one pin = one byte) and you can connect it also direct to the FPGA or MC.
Also you can split the datas to more than one hdd. (First word to first HDD, second to second...)
But some sensor chip manufactors do the work for you. Most chips (2M pixel, or more) have two, or more output ports. Your FPGA can handle this and you can write to multiple HDD, without software logic. (First chip output go to first HDD, and so on)

http://dvinfo.net/conf/showpost.php?...postcount=2071
http://dvinfo.net/conf/showpost.php?...2&postcount=68

[Régine Weinberg]

That's the Kineta way doing it