|
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? |
Quote:
|
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,13...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?...31&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 of 80's ?;) |
Quote:
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. |
Quote:
|
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. |
Quote:
Quote:
|
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/code...s_2007_en.html (not to mention a tremendous number of doom9 topics on the subject, like this one) 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... |
Quote:
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/CameraSolution...MC-2030GE.aspx http://www.imperx.com/machine_vision...ion/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...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 |
Will this help any?
|
Embedded Dev waiting to join in on the fun
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. |
Actually this thread has been kinda silent for about one or two weeks. Two usual posters are working on a FPGA solution but I don't know anything else about it. We were also discussing about a software solution for the Micron board. Some kind of realtime compression so the stream can be easily recorded, but we still have the bandwidth problem. I mean, we don't compress the stream before sending it to the computer, so needed bandwidth is still too large for usb to handle. There's also another option. If we modify the Micron board's FPGA code to lossless compress the stream, the usb interface will be able to handle it without any problem, but again we need a FPGA programmer.
As for me, I'm not a programmer, nor a hardware engineer, so I'm looking for easy to build and cheap enough solutions. So far the Elphel 353, a 3.5" mini computer and a 7" touchscreen lcd all toghether as a whole camera sound like the best option to have a full 2k (2.39:1) 24fps progresive camera. That and an adaptor can, IMHO, get us very close to Digital Cinema. |
By the way... What's exactly the link David posted? Is that a solution to record 1440p through HDMI?
|
This is a switch for two 1440p capable HDMI devices for playing on one HDMI display(you have remote for switching between them).
|
Also, smaller computers :
http://www.stealthcomputer.com/littlepc_350_pcislot.htm |
Jose: You mentioned earlier that you where successfull when recording to 10.000 rmp HDDs - so the USB can handle the data rate for full 2k. Which means that a software solution should be possible...
|
It can handle the data rate overclocked and with a 10000rpm HDD, but it's possible.
|
Wayne's 200$ HDMI recorder
There was a post about a 200$ HDMI recorder solution - any idea what it was about ?
http://www.dvinfo.net/conf/showthread.php?p=732317 |
Quote:
|
Embedded Solutions
From www.ffv.com their flash based record - miniDVR Pro uses an embedded 386. The processor used in Neuros OSD is a dual core ARM 9/TI DSP. If you integrate an MJPEG hw encoder and CPU on a chip and have high I/O you dont really need that much power. Software is incredibley inefficient compared to doing something in h/w..
Quote:
|
Keeping the thread alive - list of possible cameras
So far, here is my list
Imperx IPX-2M30HC-L/LC / LYNX IPX-2M30H-G, LYNX IPX-2M30H-GC Si-2K mini (just the camera head) AVT PIKE F-210B/C JAI TMC-2030GE Any other Altasens 4562-based industrial cameras (1080P) ? Any other links to ibis-5a based industrial camera (720P) ? Any other cameras ? |
| All times are GMT -6. The time now is 07:43 PM. |
DV Info Net -- Real Names, Real People, Real Info!
1998-2025 The Digital Video Information Network