Jose I just sent you two more emails from two different address, I hope you at least get one of them.

Steven we can never have enough minds working on a single problem, do you happen to have any experience with FPGA's?

I am thinking of starting a new thread and maybe a website/blog about this project just to keep everything in order. What do you guys think?

I think you are replying to me, no ?
If you consider as fpga experience programming four years ago a 4-bits multiplier that do 3x3 = 12, then yes. I'm a little more high level software guy (and we need that kind of software ;)) but i'm trying to learn vhdl, it has always interested me... (and MIT has some nice online courses). I'll do it alone if needed, but if i can get help for the fpga part while helping on the software side, it will speed up things.

Jose, can you send me your contact info?

I have some people in Madrid quite interested about helping ( and believe me, they know the stuff)

Sorry Stephen I got the names mixed up while replying, I was talking to you. My experience with FPGA's is limited to a class I took 5 years ago where we made an LED Blink:-(

Anyway the other developer (Bootstrap) and I have been doing some research on FPGA's and I think we are about to settle on this dev board as a base: http://www.altera.com/products/devkits/altera/kit-cyc2-2C20N.html From there we are going to build a daughter card and integrate some of the IPcore from OpenCores.org to make everything work.

There is a lot more to it then this, but that is the gist of it. Let me know what you think.

So you're going for the concurrent, i chose Xilinx and this board (http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25726%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526SRT%253D1%2 526LID%253D32232%2526PRT%253D0%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html), which is reasonably priced, powerfull (almost overkill, but that leave room for experiment) and, very important for me, very small... You can actually directly use the board once the development is finished.

edit : aww, your board is nice also, sound and SD Card socket (and IDE ?) ... but no ethernet ?? but optional micron sensor !!
The choice is hard...

That is a nice board but I think that the Altera board will be able to handle what we need.

For information:
Xilinx Spartan-3E FPGAs enable JVC's GY-HD250 (http://digitalcontentproducer.com/hdhdv/prods/xilinx_hdv_11212006/)

Ok, there've been lots of different posts.

First, Jamie and Steven, I want to be part of everything involving this project. I'm no programmer, but if you three need help with anything, just ask. And of course, keep me updated please.

Juan, you didn't enable your PM option. Please, PM me about those people in Madrid.

I'll create the blog for the project. I'll post an url soon.

Jose, My PM has been disabled by an Administrator and....mmm.. I don't really know why....
May be you can send it to Steven and he will give it to me
Or better, my email is fiebelk at hotmail dot com

Something simillar happened to me at REDuser forum.
I get a legal account but never recieved an email for confirming it, so I have an account but I cannot post. Nice isn't it?

Yes, the Foveon is one of the best sensors out there but, is it affordable?

I don't know if you've seen the development kit for that sensor but it includes a P4 computer, a screen and a big box full of different boards including the camera head, the cameralink output and a Nikon F mount. I don't think we can afford it.

Have you asked for a quotation?

Maybe upscaling a Foveon 720p image we can get to the quality we get with a 2K bayer sensor but, is it really the best solution?

About your email problems, check your ISP's spam filter settings, and your spam folders. There seems to be some PDF exploit lately, an lot of hacked emails are turning up with PDF attachments. I've even had normal dvinfo forwarded messages filtered. However, I also seem to have had some normal emails not coming through, for some reason (maybe some type of server hack?).


Foveon price, probably depends on their manufacturing quantity. Han-vision used to make industrial cameras with Foveon chips, ask if they are doing one for this chip, or an better one. You could ask them how much the cameras would be quantity. They usually use firewire, and even though there is firewire recording stiff out there, you could also ask about recording software. Additionally you could ask them if it is possible to record directly from the camera to hard drive, using the external display port for viewing and external controls. Would make an complete head solution, just add computer.

Lupa should have global shutter as well as Rolling. But 24fps, means 1/24th/s shutter, usually, when film used 1/48th/s. I think for the digital cinema age, 50fps at 1/50th/s looks better and is more universally adjustable. In the original project, 3 years ago, it was too early, because of processing requirements, and screen penetration, but now it is much closer and upcoming in future years.

FPGA, what about doing it on the Elphel, isn't it open, with existing Open core FPGA to work on?

Interesting, if you look at the latitude demonstration advantage on omnivisions home page. I suggest sensors should be checked for these problems, especially the ones with small pixel pads.

From another thread:

http://www.dvinfo.net/conf/showpost.php?p=721556&postcount=24

There are an number of people on the DIY cinema camera thread combining to do an FPGA solution, and GigE. join forces (if you haven't already) make it also attachable to camera hack of HV20 and other cameras etc.

What I am going to say is in future, but if you create such an circuit what about build on it to make it configurable to most major low end camera and sensor interfaces (GigE, Industrial etc)? This way, anybody in future can extend the circuit and use in many cameras, but being open also be available to commercial companies to extend and use.

If there is enough expertise here, and desire, it is worth working towards, as it would stop us being hamstrung by manufacturers. Making the sensor interface extension part of the design, also makes it Open, and is also desirable.

I feel a little down...

I ran out of things to do for this project.

That's it. We have our solution. Sensor + FPGA connected to a computer or directly to a HDD. Jamie and Steven haven't finished yet (or even started), but the rest of us just have to sit down and wait.

Having started this project myself, I really liked the idea of being the main active part till the end, but I guess this has become a project for everyone in the past two months. And I'm glad for it, but I just can't help feeling a bit down since I cannot be an active part anymore.

Well, anyway, we'll have our own open source 2K camera!

Ok, i just ordered the board Jamie suggested (well, too bad for the lack of ethernet, but let's have a recording solution first) and see what we can do with that. A proper raw 640x480 camera would be a good start ;)

Jose, there is things you can do, as a film maker, and not a tech guy. Like designing what would be a good interface, what kind of workflow would be acceptable, etc.
Or find a suitable manufacturer that can provide in very small number PCBs for some more integrated prototypes than dev board, once the FPGA software is done.

You're right Seven. There're lots of things to do yet.

I've got a new quote for a 3.5" board with a Core2Duo 1,8Ghz and 512Mb of RAM already installed. It's $786,43 each.

I'm asking for another two with 1Gb and 2Gb of RAM.

The board is the one we found after the LS-371, the 3301880.

http://www.globalamericaninc.com/new_spec/spec2.php?id=845

The workflow is simple. If we can get to full 2K, perfect. I know the Micron sensor can and gives more than 24fps, but for me 2048x858 is ok. Then possibility to choose 1080p and 720p in 16:9 and 2.39:1. Variable framerate but fixed at 24fps by default. Programmable gain, white balance, contrast, gamma... All those controls were already supported with the demo board, but some must be translated to filmmaking formulaes. I mean, using the Micron sensor you must set the shutter time in miliseconds, while in filmmaking you set it in fractions of a second.

Now, recording workflow:

In-board compression must deliver already debayered lossless 2:1 or more (visually lossless may also be an option), so we can use standard parts for the computer. Otherwise we'd have to use 10000rpm disks which are a waste of budget if we consider that a simple SATA 320Gb 7200rpm HDD is quite cheap.

There can be many ways to record the clips from the camera to the editing computer. One could be just a simple firewire/usb connection. Other could be using an external usb HDD. You plug it to the camera and we put a simple button in the interface to dump all selected clips to the external HDD.

Anyway, all people reading this can suggest different options for the interface. Please, keep it simple. Have in mind that this interface will probably be controlled by hand using a touchscreen, so I'm thinking of big buttons to control all common options and maybe a "menu" button to open a new window with all the rest. If we use a widescreen LCD and we shoot in 2.39:1, we have enough space up or down to include a simple menu.

By the way Steven. Why did you choose a dev board without GigE?

Well, this altera board is cheap (280$ with the sensor board and shipping) and you have to do one step at time. So, for the moment, i'll play with the sensor, learn how to interface it and controlling it, record to sd card and try to write come compression algorithm. With the xilinx board i would need to solder pins and solve some purely mechanical problem, which i can't do it right now as i'm working abroad and don't have anything but a computer to work with. So for the moment, i'll focus on the software, and once everything will be working, we'll see for using another interface.
The real world struck me somehow ;)
(and as the dev board is using a 1.3Mpixels Micron sensor, i'll ask the company for an eventual sensor upgrade, the pinout should be quite similar)

Ok, anyway you know you have a full Micron 5mp head for about $300. It could be useful for the final design.

May be these documents from TI will be usefull for developers:
Interfacing a CMOS Sensor to the TMS320DM642 Using Raw Capture Mode (http://focus.ti.com/lit/an/spraa52/spraa52.pdf)

HD Video Encoding with DSP and FPGA Partitioning White Paper (http://focus.ti.com/lit/ml/spry103/spry103.pdf)

Hi to all I’m Matteo from the Elphel thread and I've finished reading this big thread only now. I think you're doing a great job! I'm doing an hd camera also but because I’m not an electronic or software engeneer,(I'm a civil engeneer) I do not know how to design hardware and software so, I stay in the elphel side ...is small is not so expansive and it can make amazing things, is open, supported by a factory that develop camera and last Andrey is very kind with us (he take an eye every day ) so the camera will increase in function every day
I’m designing all the other part of the camera…matte box , rail system, follow focus and a medium format spinning adapter! ….all those things will be made in DIY mode so it will be heavy at the end and use a in camera pc will increase more….but there is always a but….for a movie what is more important , yes more important than the image, is how you have shoot the film…or better you have to look at lights setup ,sound and an anti shake system for fluid pan! The last one is, I think, the most important thing, yes fluidity! Take a look at 28 days later …thay shooted it with the first XL1 an SD camera!
So in the end, to stay cheap, we have to take a look at the final weight …I’ve taken a fluid head tripod by vinten (one of the best factory ) and I think that all our project have to stay under 6 Kg with that weight you could take a good tripod for less than 500 dollar….double the weight and you have to invest 2000$ for a very good one …That’s why I think that the best way we can follow is a camera like the SI mini2k camera and the pc , battery and so on… to put on the ground 

I’ve seen that you’re looking for quality c-mount lens …take a look at this: Computar H2Z0414C-MP spec is here http://www.rmassa.com/specsheets/H2Z0414C-MP.pdf and here is the link http://www.rmassa.com/manu/computar.htm or this one http://www.rmassa.com/specsheets/HF125SA16SA-1.pdf but is more expansive! http://www.rmassa.com/manu/fujinon.htm

And if you need an Idea on the design of the graphic user interface for the camera I’ve developed some ago these for the elphel in flashMX
http://www.webalice.it/teo.poz/elphel_GUI/
http://www.webalice.it/teo.poz/elphel_GUI2/
but cause is very difficult to get access to the camera for now are in stand-by …until Andrey will implement php access to every single aspect of the 353 

have a good luck from Italy! Matteo

I'm still waiting to get an email from you Jose

(Todavia te estoy esperando Jose. Que pasa? No te interesa en Absoluto?

Esta persona es un investigador Uruguayo que vive en Madrid y trabaja para varias instituciones españolas, muchas sin fines de lucro.Es el inventor de muchos algoritmos de tratamientos de imagenes que se usan el lugares de postproduccion High End. )

Why are you all going with an FPGA solution and not with Software compression? If this camera records directly to a harddisk then why not let the processors on the board do the compression etc.?

The first thing would be to compress the Bayer raw and add Metadata so that the Debayering and all the other stuff can be done in postpro.

Other features like a modus where debayering takes place before compression could be added afterwards if we stay with software. It just leaves so much more options than the FPGA solution.

Man, I wish I had some spare time right now to write a simple entropy coder for the Bayer raw in Windows :/

What make you say that we are not doing any compression ?
It's planned from the start, and i've already wrote some VFW codec for raw bayer lossless compression and a good quality debayer avisynth filter (which also used in the decompressor) but you need a FPGA to interface any sensor with a PC anyway.
The problem with software compression is that you need huge bandwidth to transfer data from the camera to the pc. Which is not really available with cheap hardware, not to mention that some people here (me) doesn't want a computer and that FPGA can perfectly do the job with way less power consumption.
I think you've read this thread a bit too quickly...

Of course I'm interested Juan. I just sent you an email. Sorry I didn't do it before. I was a bit busy these days.

Steven's right Gottfried, with any solution we ever choose, a FPGA is needed to interface the sensor with the computer. In fact, the Micron demo board has the sensor head and a FPGA with USB output, which leads me to the next question:

If we have the Micron board, we already have a FPGA. Ok, it doesn't have GigE out, but if we add the lossless compression codec to the FPGA internal code and we compress the stream to get a data rate that's easy to handle by USB 2.0, why would we need anything else? I mean, the camera would still output raw bayer, but with a much lower bandwidth.

I know I'm making this question a bit late, since you already ordered the other FPGA, but do you think it would be possible?

Ok, I tested it and I can't write 2K frames at 24fps to a 7200 rpm sata disk. It only gets to 18-19fps.

I can get to 24fps with a 10000 rpm HDD.

So we need to find another solution. Recording to RAM allows about 40 seconds per gigabyte in RAW. We can only add 2Gb of RAM to the board, so we'd be limited to about 1:20 min for every take. RAM's not cheap though.

Well... First BIG problem. This is basically where all previous camera projects have failed and where successful cameras have gone from low cost to really expensive.


Well, actually I thought the current problem was to record full 2K with a 7.200 rpm HDD. This can be done in software, Steven already wrote a VFW Codec so you can actually have the 2K camera you wanted to build by using it...

Yes, but the Micron tools don't allow the use of a codec so...

If we're going for the software solution, we need someone to write a tool to control the whole camera and compress the stream in real time. If it can debayer and compress in real time, even better. I can design an interface, but I can't program anything else than action script so we need a windows programmer who has enough time to do it.

If we find one, then I'll buy the Micron board and the 3.5" computer.

If not, then we have to wait for Steven and Jamie to finish.

Here is some new Microsoft picture compressing codec that they are trying to get ratified with Jpeg, said to be twice as good and comparable to Jpeg2000, and some sort of open source offer.

http://www.pcworld.com/article/id,135302-pg,1/article.html

I wonder if PNG can be made any good, and if anybody has done Open core for it?

I've 100% agree with Gottfried Hofmann.

CMOS->RAW BAYER->FPGA->COMPRESSED 5:1 RAW (alike CineformRAW)->HDD(SSD)

ELPHEL camera is sensor agnostic and only need a good codec to encode bayer raw at 5:1. Best codec for this task today is CineformRAW - NOT FREEWARE.
But David Newman (CTO of Cineform) also have interest in new cameras based on Cineform RAW.
http://dvinfo.net/conf/showpost.php?p=574531&postcount=4
http://dvinfo.net/conf/showthread.php?t=71873

Yes, the Elphel is still a good solution and it does everything we want, but can you choose any codec you want with it? I thought you were limited to MJPEG.

Of course, Cineform is the best raw lossless codec out there, or at least that's what I always read, and of course David Newman is interested in cineform based cameras. Mainly because the camera manufacturer has to pay a lincense to use their codecs. Just ask at Silicon Imaging. I supose that's why Red developed their own codec and that's why we should develope our own or use an opensource one. We just need 2:1 in real time. Anything more than that will be even better cause it'll be much easier and faster to record.

And Serge, Gottfried was saying exactly the oposite: CMOS>FPGA>RAW>COMPUTER ENCODING LOSSLESS>COMPUTER HDD. Steven and Jamie are working on the solution you said.

Jose, sorry, my mistake. I want to say "100% NOT agree" :)
Capital letters and logic of chain an image processing said also "NOT AGREE"

Now two big questions is "free wavelet codec for bayer raw" and "implementation this codec into fpga of Elphel cam".
Cineform as payware alternative good too. I'll pay $500 to have best codec than use average codec for free. A lot of people happy to use Cineform for ingest through HDMI and fast editing.

Just a question: is Cineform Quicktime compatible already? Because I'd like to have full compatibility with Final Cut.

Yes. You can easy change container avi<->mov without recompression.

P.S. Jose, do you like music (http://youtube.com/watch?v=a_4EQprT7L0) of 80's ?;)

I've 100% agree with Gottfried Hofmann.

CMOS->RAW BAYER->FPGA->COMPRESSED 5:1 RAW (alike CineformRAW)->HDD(SSD)

ELPHEL camera is sensor agnostic and only need a good codec to encode bayer raw at 5:1. Best codec for this task today is CineformRAW - NOT FREEWARE.
But David Newman (CTO of Cineform) also have interest in new cameras based on Cineform RAW.
http://dvinfo.net/conf/showpost.php?p=574531&postcount=4
http://dvinfo.net/conf/showthread.php?t=71873

From what I understand, yes you can upgrade, and people over at Elphel thread are doing that. I think I remember Andrey dropping hints of wavelet. The Dirac codec is freeware and for professional TV work streams, FPGA version is being done. I think they have been in contact with each other. What they are attempting is probably going to be relatively simple, but still aimed at 2:1.

I have been in contact with David about licensing Cineform RAW before. it is available relatively cheap in quantity on certain terms, on the camera side (but of course you also need it on the editor side).

H264 professional is interesting, but that Jpeg standard that Microsoft is trying to make, comparable to Jpeg2000 wavelet, might be easier. Likely somebody will want to make Open-source or Open core on these, and I wonder if anybody has already started. The advantage of these codecs is probably 2:1-3:1+ lossless, 4:1-6:1+ visually lossless (rough guess). In visually lossless you can start dropping contrast in the detail for entropy, lossless will look more impressive in that way.

I wonder if PNG can be made any good, and if anybody has done Open core for it?

Judging from the documentation Micron offers an option to compress RAW Bayer still images using PNG.

Thanks. Can you link me to the documentation? What style is it, hardware, fpga, software?

I wonder what the compression performance is compared to normal, should be just as good as many.

Thanks. Can you link me to the documentation? What style is it, hardware, fpga, software?


I found it in the docs of the Micro CD Jose posted on page 10 of this thread:

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

Here it is.

The GetRawImage() function can return a PGN image, but it seems to be not Bayer Raw in this case. Also, it does read wether they do the compression on FPGA or in Software.

Thanks for that, would probably take too much to download an full CD image. Be worth looking into, PNG has sophisticated lossless compression techniques, and if it comes free..

Well some smart guys didn't wait you for testing it out, CorePNG codec has been out for years now. It's slow and doesn't compress that well (well it depends on the content.. iirc it performs really welll animated content)

A good lossless video codecs comparaison :
http://www.compression.ru/video/codec_comparison/lossless_codecs_2007_en.html

(not to mention a tremendous number of doom9 topics on the subject, like this one (http://forum.doom9.org/showthread.php?t=90031&highlight=Lossless+comparison))

Nothing new under the sun, HuffYUV and some ffdshow VLC variant are the ones who provide the best trade off between speed and compression ratio.

Thanks Steven,

But do they have open cores, or any? The problem is that like, h264, compression can vary an lot from the best because of implementation, so I wonder how good the CorePNG is, and if it is oriented towards picture and video scenes (video=blur). But if it's been done, obviously it doesn't mean they are going to improve it's performance. I am also, always curious on how an product goes on low noise footage, as it is tempting to test it on noisy images which is an disaster to some of the techniques used in PNG.

Just looked at the summary, and appears to get acceptable performance at slow rate, but still interesting at the fast end. You are implying this is FPGA, can it get much of an speedup from and better FPGA.

Hmm, intre, and not FPGA?

Thanks Steve for the Link to this excellent study.
As expected HuffYUV is the fasted method and has a ratio sufficient for this project.

@Wayne : i'm not really following you. I'm talking about lossless codecs, so the quality can't be impacted by the implementation, only the speed and the compression ratio. And this is not FPGA core or anything hardware, just software codecs, which is good anyway to choose the right one. We need the simplest one (because it's already damn hard to just write a huffman coding block in a fpga) and the fastest one (because of the video resolution and because FPGA aren't that fast, yes). The compression performance is clearly my last worry, any good algorithm will do 2:1 anyway.
That's why you can forget about PNG as you can see it's a very bad contender.
So before thinking of and ultra-sexy-but-complex codec, get real, we have to write it in a fpga and that's a very long and time consuming process.

Now if FedEx could deliver that package, it would be nice...

only the speed and the compression ratio.

That is what I am talking about, except I was talking about the possibility for an existing FPGA/Hardware PNG implementation (simpler than writing an new one) as people are looking at FPGA.

Just reading the rest of your post, politely, I think you are completely misunderstanding where I came from, which is much more realistic than writing an new FPGA. I don't mind if talented people want to do FPGA, I appreciate few can, even in the computer world, last time we had people wildly wanting to write FPGA but no real experience/talent (except for the guy that did one, that I was in step with, then that was only an straight raw recording, and he started with an non FPGA solution from what I know). Being totally real. If PNG existed in FPGA I would say go for it, not the easiest solution (going for Elphel lossless codec project, or software, is easier). PNG is not the most sophisticated codec in reference to video compression, if I can remember properly, I think they base it on an simpler codec, but it incorporates an number of different techniques. I think I came across PNG in relation to Jbig2/Fax compression, but have to look that up. Which is not the best for noisy images, but simple.

This all came out of mention that Micron supported some sort of PNG solution, if it's free then why not check it out. But as far as free FPGA compression cores, there is Dirac. And regular lossy wavelet hardware chips there is the JPEG2000 chips from Analogue devices. If I were programming FPGA, any of these things I would investigate before doing such an project.

Spent most of the night looking at compression stuff, and I didn't see an reference of PNG using JBig stuff (though I think there is some crossover from earlier fax stuff) so I assume I was wrong in saying that.

Guys, look at this GIGe camera head: http://mikrotron.de/index.php?en_cams_mikrotron_mc1325

1" CMOS, Global Shutter...

Wow! Nice to be here again!

I'm sorry I didn't post here in the last few days. I was moving from my flat and (of course) my ISP's not giving me internet untill next month. You know... They have to cancel my account, set up another one...

I'm glad to see people here's looking for other solutions besides FPGA. I'd like to know if anyone's researching on real time computer based lossless compression for the Micron board. If that's possible, it would be a great solution for people like me who can't program a FPGA.

Hello Jose, nice to see you again. I am back from holidays. I have seen that this thread goes in a direction that is not your favorite (mine too). I have also move on with my mechanics for HV20, and other 35mm adapter.
There on aaoen site I have found that you have representative for their stuff in Spain so you can ask them for this aaeon board that I have mention earlier. I am still intrested in this board because it has PCIe and PCI expansion port. So it can be used for other stuff too.
GigE cameras has always been my favorite but good ones with big sensor are always over 4000$
http://www.jai.com/EN/CameraSolutions/Products/Pages/TMC-2030GE.aspx
http://www.imperx.com/machine_vision/megapixel_digital_cameras/2meg_high_definition/index.html
Both are HD resolution but they come with software for capture and playback. They are using Kodak CMOS sensors so no rolling shutter but there are other problems like multi tap.
Here is 2K one:
http://www.imperx.com/machine_vision/megapixel_digital_cameras/4_meg/index.html

Jose, send me those numbers I have ask you...

Hi everyone,

I've been playing a bit with that posteriori debayer algortithm.

I have found that the implementation would be much heaver than AHD. Although it does less mathematical operations, it does have more memory accesses. Plus there is a lot of overhead as most operations are only done on one specific kind of pixel at a time, which can be not be done in parallel.

But there are some really interesting parts of the posteriori, so I have been mixing AHD and posteriori together.

I've replaced red/blue in blue/red pixel interpolator, as the AHD does simple bilinear interpolation on the red/green or blue/green difference. The posteriori version uses the horizontal or vertical direction. This can be done in AHD as well you just do it for both horizontal and vertical directions.

I also replaced the artefact reduction which in AHD is running three times a median filter on the colour differences. The posteriori version uses knowledge about the real pixels in the bayer array.

I also found both version are doing colour difference interpolation. Which actually looks like a high frequency replacement like is shown in the pdf of the posteriori. However I found the math to be wrong, they do not scale the high frequency component before replacing it, which looked really ugly. By scaling the high frequency component by the division of both low frequency components it seem to work correctly.

I have also tried replacing the green interpolator, using scaled high frequency replacement. It seems to work, but I see no difference between the normal AHD version and my own replacement. Mathematically it seems the AHD interpolator is incorrect.

Cheers,
Take

http://www.engadget.com/2007/08/16/accells-ultraav-hdmi-1-3-high-speed-switch-support-1440p/

I've got a background in embedded systems and I read this thread till Pg 19. Then got confused and sleepy. I'm trying to do something similar - but with GigE or IIDC (Firewire)
Would someone mind summarizing all the projects going on ? Also, how can I help - I'm just about to get my equipment.