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.

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.

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.

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.

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.

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.

Rollign Shutter
 

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.

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?

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).

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.

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)

16mm lenses
 

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 ??

I can not post so much sick with my teeths

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

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.

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.

shutter
 

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....

Yes.

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

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:
http://dvinfo.net/conf/showpost.php?...postcount=2071
http://dvinfo.net/conf/showpost.php?...2&postcount=68

That's the Kineta way doing it