Here's another clip. 2k(2.39:1)@24fps.

I know this can make little or no sense to you so I'll explain.

The clip is actually a message for a friend of mine. He's a film student and knows about this project. He's looking forward to shooting one of his short films with this camera once it's finished or at least ready to film.

He's so excited about this that every time we start talking about the camera he says "Come on... Make me cry" (of happiness, of course). He always says he can't believe he'll be able to shoot 2K Digital without having to spend thousands.

So in the clip, the message I write on the piece of paper means "Now you can start crying".

You can download two versions:

http://www.cus-cus.net/dani/Test02-2k.wmv
http://www.cus-cus.net/dani/Test02-2k.mov

Very nice footage footage Jose! I keep getting more and more excited about the possibilities!

Anyway, is it possible to tell which FPGA the Micron demo board uses? I am just looking for a part number to get a rough idea what kinda processing power is required.

I can't upload the demo board manual where you can find all hardware descriptions. You can find it at www.framos.co.uk clicking on "Products", "CMOS sensors", "Demo Boards" and "Demo Camera System".

Polling is how often it checks per second, which is done by software in USB I understand, and is one of it's problems that slows down performance, but would yield some better consistency in data-rate. Or, it could be an master timing clock, that regulates the actually speed.

Things are set lower speed, but also made to tolerances. Overclocking can reduce life of the part, and there was something else I can't remember. I'm not saying not to do it, just that things are not as simple as they might seem sometimes.

Well, anything that could cause problem, lot of color, edges. For the resolution, 1080p, 720p and the ones you're planning to use (but for performances issues, you should _really_ use mod16 resolution).
If you don't have any server space, uploading will be an issue tough... can you access http://dl.free.fr ? It's not overloaded with ads... ("file to send" > "fichier à envoyer")

Thank you very much !
(btw do you have the full datasheet for the micron sensor ?)

Jose,

Are you using gamma correction on your footage?

No. I wanted to know what the sensor could do by itself. The software does have controls for gamma, contrast, gain, white balance... But that clip's not corrected in any way. I must say I really like the results.

Could you please make one with gamma correction, in low light conditions. Keep gain and bias, etc on 0.

I want to know if what the Pike is doing is the same, I am already doing gamma correction and the company says that that is the problem. Which is completely weird, as everything should be gamma corrected.

Cheers,
Take

Wayne, I'm thinking about adding a big computer fan to the final design to avoid very high temperatures but if anyone knows of a better procedure, please say it. I wouldn't like to loose 900euro and the possibility to shoot 2k because of that.

Take and Steven... I'll shoot something for you asap.

Well you are not "overclocking" any hardware device, you are just forcing windows to look more often at the USB port if something's happening... By decreasing the time you react to usb activity you gained a bit of fluidity but nothing will burn because of that. The hardware is still running at the same frequency...

[edit] err, in facts that's totally wrong. The usb master is polling the bus every 1ms (1000Hz)(that's why it sux btw ;)) so that's why they overclock their usb mouses : to get the refresh rate of the mouse at something better than 125Hz, but you are not concerned by this kind of hack, you're not using a mouse . I wonder why you gained something by doing so...

Great then. I was worried about that.

I've been talking with an Omnivision representative. Appart from the sensor and the demo board they offer me different solutions to make the camera portable.

We've been talking about different options but two of them sound very interesting.

One of them includes the board, a minipc fanless embedded system and a small touchscreen lcd. The minipc is really small and it has 1Gb of ram and up to 1,8Ghz processor. It also includes 4 usb ports and a compact flash slot or a 40Gb HDD.

The other option exchanges the minipc for a panelpc, so it includes the touchscreen lcd as part of the whole computer.

The conversation made me think, and I've been looking for mini-itx computers and carputers (computers for cars). I found many different options at very good prices that could be perfectly used to build a standalone camera. Many of those computers boot in just a few seconds and if they just have Windows and the camera software, I think they can handle the capture without any problem.

What do you think?

Is this small enough?
 

Wow! Do you know the price?

If it is polling, then it maybe that synchronisation with the PC is better, and more close to the data issue on the camera. This would result in an little increase in efficiency, and less wastage of bandwidth (in case anybody is wondering what this means, frames are rolled out after shutter and other processes, this means that the data has to come out in an peak, for 180 degree shutter, it will likely double the bandwidth requirement, then 10bit words often take up 16bits, and is not packed fro transmission, you can start kissing 720p goodbye if this is the case as well). Cameras without memory buffer and packing are the problem.

To be honest, Wayne, I didn't understand a thing of what you just said. I increased the frequency, now it goes faster (it reads more times per second) and my biggest concern was if that process could damage the camera in time, at least faster than normal use.

Also I have bad news. I just received an email from Micron. They say they apologize for the mistake but framerate cannot be fixed. I just can't believe it. That basically means the board can't be used to shoot movies. The only way to decrease framerate if it goes faster than 24fps is by decreasing electronic shutter frequency, and that means a more noticeable rolling shutter.

In a few weeks I'll have here the Omnivision board for testing but I seriously doubt it's better than the Micron.

I think it would be better for you to start experimenting with an Elphel camera instead of trying any propietary solution out there.
Maybe at first the learning curve may be harder, but seeing how much progress you have obtained up to now I believe it would be the best path.

Sorry Juan but I think that this is kinda a dim view. Jose is showing some serious progress, and If we don't keep experimenting how will we evar know what is going to work best for us?

Hi Juan,

If you read through the post, you'll see the Elphel has always been one of my options. In fact, the new 353 uses exactly the same 5mp micron sensor I have and you can set the fps you want.

There're 3 points I don't really like about the Elphel:

- First, it's a complete already made product.

- Second, it compresses the image. It does it very well, but even the RAW Jpeg is compressed. You cannot choose to extract a RAW Bayer sequence from it.

- Third, and I know this sounds bad, Linux. I've got Windows and OSX Tiger installed in my computer and, if possible, I don't want to need to boot Linux everytime I want to shoot something. In fact, if I have to choose between both systems, I'd choose OSX, cause I'll end up compositing in Shake and editing in Final Cut.

Now, I decided I want to stay with the demo board if possible. I really like the image, motion and ease of use so,

Take and Steven, if you really want to help this project, what do you need to develop:

- A very simple recording tool that can control gain, resolution, shutter, binning, gamma, contrast, clock, white balance... and VERY important, FPS.

- A converter from RAW bayer to any usable lossless codec.

I'll try to find everything you need. Datasheets, manuals, actual software... I'll record RAW sequences for you. I can test Windows and OSX software here. Anything to get this project done. Just ask.

Here is the first RAW sequence. 159 frames captured in Micron RAW format. It was debayering in real time when capturing (Laroche-Prescott) so I think it will just need RAW decoding. It also has a txt file with all sensor info and settings during the capture. If you need another one in Bayer format, just ask.

I'm also adding another file with all the PDFs that came with the board. All schematics, manuals, datasheets...

http://www.cus-cus.net/dvinfo/capture.rar

http://www.cus-cus.net/dvinfo/doc.rar (Not active)

It's uploading right now. It'll finish in about 10-15 min.

Hey! I also found many C++ code samples! They explain how to program simple capture tools and things like that.

I think I'll just compress the whole Micron CD so you can have everything you need.

I'll post a link when it's ready.

http://www.cus-cus.net/dvinfo/microncd.rar

Here it is.

Take,

I am not getting how this is possible...
1920 x 800 x (4 x 14 / 8) x 24 = 258048000 Bytes/sec or about 246MB/s.
The "(4 x 14 / 8)" in the calculation is two Green, one Red and one Blue channel per pixel at 14 bits converted to Bytes.
The best sata drives (15K rpm) can sustain about 130MB/s. For regular 7200rpm, about 60-70 is all you can count on.

Ivan

Hello Ivan,

Your calculation is off by 4; on a bayer sensor the green 1, green 2, blue and red, each occupy a separate pixel, with some fancy interpolation algorithm you can reconstruct all the three color components per pixel. Effectively there is a 1:3 compression ratio.

Also, as my own camera has firewire 800 connections my limitations are different. 1800 x 750 x 14bit @ 24fps or 1920 x 800 x 12bit @ 24fps. Actually I could do a little more height in 12 bit or wider with an larger sensor.

Oh, this is good news for me, then. My plan was to put a sensor and an FPGA on a mini PCI board which would go into a Via's nano ITX with RAID support. I figured it would only be possible by doing at least a 2x compression in the FPGA, but now I am thinking that it might be doable with no compression.

Please, i want to test my debayer algorithm ;)
(in fact, the best would be to have the same sequence in bayer and debayered by micron so i can compare... it might be difficult but there is no point to continue to work on my algorithm if it's bad :))

And for the elphel compressing video, well you could by-pass almost everything but the huffman compression in the FPGA and get lossless bayer compressed video. That's why it's a good start : you got the right hardware and the source of the camera, you just need the skills to modify it a bit.

http://www.cus-cus.net/dvinfo/captureRawBayer.rar

Here it is. RAW and Bayer. Uploading now. May take 10 min or so.

But Steve, wouldn't it be even better if we develop specific software for the demo board? We already have working hardware and the results look better than I thought. We just need to control fps and develop a simple tool to read and convert raw sequences (and even debayer them using the best possible algorithms) and we've got our camera! I mean, there're few cameras out there that can deliver 2k and the image and motion feeling on this one's just great.

We're almost there!

Going back to the optical part of the camera, I'd like to know where to buy very sharp c-mount lenses. Don't get me wrong, I like the soft movielike look the camera has now but when the adaptor is added, the image will pass through 3 lenses (c-mount, achromat and 35mm lens) and the ground glass so if final image is a bit soft I want the 35mm lens to be responsible for that. The rest must be as sharp as possible.

I don't care if the c-mount lens I choose is a second hand one as long as it's very sharp. In fact, it will be much cheaper if it's used.

Where can I look for it?

Check out this thread, it may have some good information for you: http://www.dvinfo.net/conf/showthrea...hlight=c-mount

What kind of debayering algorithm are you using? (spline, bicubic, etc.)Also I would love to see the results if possible.

Datasheet
 

Has anyone managed to obtain the Micron sensor datasheet? I created an account on their site and asked for the NDA, but no one has contacted me yet.

Jose, have you seen this page regarding the lens: http://www.micron.com/innovations/imaging/lens ? They have some useful info there as well as few suppliers listed.

Hi Ivan,

Thanks for the link. Yesterday I uploaded all datasheets, manuals and sample codes that came with the board. Page 10 of this thread.

Jose, I looked at the file you uploaded, but it seems sensor datasheet is not there. I looked at all the pdf documents. The datasheet should be something like the document at http://download.micron.com/pdf/produ...31_5100_PB.pdf but with a lot more information (registers, timing, etc).

Ok, I'll send an email to Micron asking for the sensor complete datasheet.

Jose -- what is the reason fixed fps speed cannot be set (or if set, cannot be maintained)? With the Sumix, setting say 25 fps would produce a clip whose properties showed an actual frame rate of say 24.96 fps or some other fractions different from the ideal. Because the RAM-recording clips were quite short, the discrepancy was not great enough for an accumulation to effect sound sync. What sort of discrepancy are you getting from the ideal?
John.

Well, the main problem is that I don't have an option to set fps. Framerate depends on the resolution, system clock, gain, shutter... But nothing more. You cannot program framerate.

I mailed Micron asking if it would be possible to upgrade their program by adding an option to set framerate. They didn't answer yet but I don't think they'll do it. That's why I need someone to help me out with this. I need a tool to control all aspects including fps. If you read the sensor datasheet it says framerate is in fact programmable. I just don't know why they haven't included that option.

As I said, I want to stay with this board. I really like it. So now I'm just waiting for someone who can write an application to control the sensor and record the clips.

As for what you said about RAM recording, I can record 2K AVI Debayered to RAM and RAW debayered to disk in realtime with an almost continuous framerate (between 25 and 26fps) with Micron software.

That sounds the same as with an IIDC camera. The framerate is depended on the amount of firewire bandwidth you want to be used.

But it is possible to trigger the start of a frame externally. I want to use a 1:2000 frequency divider (maybe a simple PIC processor), clocked to a 48000 Hz digital audio word clock.

Maybe that would work with your board as well?

Take, I must admit I'm a bit lost in terms of pure hardware and coding. Anyway if you want me to test options to get those fixed 24fps, just tell me what to do and I'll do it. From what I know about the sensor, I think it's possible to fix framerate via software though. I read it in the datasheet.

I guess it's not so easy but, would it be possible to develop a tool to control the board and record bayer clips? Or maybe adapt you Boom Recorder? It would be perfect if you could do it.

Thanks.

Same here, I have not received a single email or phone call from Micron. Also Digikey sells the sensor so I emailed them and asked for the datasheet, the response I got just told me to check the part number... I was not sure what they meant by this so I emailed them back verifying the part number, but I have received no response. However; I did manage to get the full datasheet for the MT9T001 sensor from the digikey site, and I assume that a lot of the information is the same.

According to this data sheet the only way to adjust your frame rate is by changing the vertical and horizontal blanking times.

Don’t take this as gospel but according to my math (which very well my be faulty) to get 24fps at 2048x856 with a 96Mhz pixel clock you would want a Horizontal blanking of 21 and a Vertical blanking of 1093. I chose the minimum number allowed for the horizontal blanking to make my math simpler, so many other combinations are possible.

So Jose if you can use the Micron software to write directly to the registers (assuming the registers are the same as on the MT9T001) you will want to do the following:

Write:
0x0015 to address 0x0005
0x0445 to address 0x0006

Be sure to record the values that are all ready there are first so you can change them back later!

One more disclaimer: I am not positive that this is correct; this would be a lot easier with the proper datasheet! :-(

Edit: Here is the equation as I understand it from the datasheet (Trust me, the datasheet is not this straight forward.)

(((HRes*(VRes+Hblank))+(Vblank*(VRes+Hblank)))*(1/Pixel Clock) = Frame Period
So to get the above numbers I use:
(((856*(2048+21))+(1093*(2048+21)))*(1/96000000)) = 1/24

Also, does anyone out there know if there would be a point to using a lager Hblank and a smaller Vblank? It seems to me that by keeping the Hblank as low as possible it would help to reduce the rolling shutter, but I am not positive about that.