![]() |
Hello,
Thanks for your question Wayne, I'm currently developing the video editor plugin for the "codec". But I must ask you that please don't exaggerate: as I stated earlier the encoder will only do the minimum to fit into the 353's disk write speed, nothing more. If that means only 2:1 compression then that will be. I wouldn't even call it a "codec" at all as it will be dumb as possible. And if I have to do a really complex encoder then I won't do it. Also, I only make a verilog encoder and an importer for a video editor software so the term "codec" isn't appropriate, again. So if Rob is looking for a general purpose codec then this might not be his choice. And as I still don't have a camera I cannot test the encoder so I don't know that it will produce the desired results or not. Let's wait with this. Zsolt |
Big Question is:
Why not giving to Elphel camera a PCMCIA interface? It shouldnt be so difficult ,there is already Verilog/VHDL code for a PCI interface at Opencores......, just add a device driver and a grain of salt. |
BTW, is there any way for me to get uncompressed 10 or 12 bit bayer video????
I mean It was impossible for me to get stuff like that to experiment with. |
Quote:
BTW, do you know if the 353 will support writing to disk and streaming Ogg Theora video simultaneously? Thanks! |
Zolt, this is sucking time out of my tight schedule, but where did I exaggerate? I've asked you questions in times past, about your claims of much more than 2:1 performance from your experiments, but received very little reply. I merely stated that you could, on your large claims, out do the lossless codec that was worked on for Obin's camera, which was simple and 2:1 or so, the cineform codec is visually lossless (not really lossless, not so much of interest) so is a different matter to which I was talking about (but from your previous claims it sounds like you could have a go at that). The need for only a codec that could , at a minimum (2:1) to squeeze raw through, was originally my proposal anyway.
So, please, I don't need anybody else needlessly coming down on me, I am aware of the limitations and the possibilities, which is usually more than we can say for most. You and Rob have fun together. As you can see, I am mostly away from this, deliberately. Thanks for your efforts. Quote:
Quote:
External PC units for display etc: If anybody wants to hook a computer for display/control, then 5 inch UMPC's (mini tablet Window XP computers) have just been shown off for next year, and Apple is hoped to come out with one of these next year. The Intel G965 chipset, with unified shader direct X 10 GPU, I suspect they will sort out the problems of, and the mobile version is expected to come Q1 07. Eventually, I expect this will come to the UMPC. But for anybody wanting a small PC hooked to the unit, without graphic card, the G965 (G versions only) might be well positioned. |
Quote:
Quote:
Quote:
Quote:
Zsolt |
Quote:
Quote:
Quote:
Thanks! |
Quote:
|
Thanks Zolt.
I think testing the effectiveness of the JPEG compression on an grayscale of the bayer mask should be tested to see how well bayer interpolation holds together, with adjustments made to the compressors parameters. The main parameter to test is the quantisation phase (? I forget, the phase when they divide down the pixels to even them out to make them more compressible). A maximum of 3:1 compression, would probably be best. it would probably be near lossless at the most, and nowhere near as good as a bayer compressor. But ti would be better for existing camera owners. Very simple intra frame compression then could be added, as was being designed elsewhere. Rob, a lot of those drives are power hungry and big, so select carefully. I would like to move in different directions than doing anything camera/codec development related, but I am interested in your bayer footage. if you could post 10 second scenes and bayer format information that would be useful? A simple scene, simple shooting, an complex movement but simple scene, and a complex scene and complex movement. This would provide good test subjects for codec performance. I'm itching, but have too much else I should be doing. |
Quote:
Quote:
Quote:
Quote:
|
Quote:
Quote:
Quote:
Quote:
Quote:
Zsolt |
Quote:
Quote:
Quote:
|
Quote:
Zsolt |
Quote:
I did a bit of Googling and found this document which states that the FS supports UltraDMA mode 2 (33 MB/s). The bandwidth required for 1280x720, 10 bits @ 24fps is 26.4 MB/second, so it may be possible for the FS to write the raw data to disk with no compression at all, or with only slight compression. |
Quote:
Quote:
Quote:
Based on all of the above, I expect something around 10MB/s and that requires 3:1 compression ratio. Anyhow, we're going to be on the edge, that's for sure. Zsolt |
Quote:
Quote:
BTW, have you looked at some of the components available on OpenCores such as xmatchpro lossless data compressor or Video compression systems? Thanks! |
Quote:
Quote:
Zsolt |
Quote:
Edit -- Andrey mentions using the ETRAX FS in this post and this post and indicates that the CPU should be roughly twice as fast. |
I see that Etrax FS has PCI support built in so, does it mean that you just can connect a PCI board to it or what?
|
Quote:
|
Back on track
I had do deal with some events of a personal matter - that caused slowdown with the 353 project. But now I'm again working on putting life into the first unit, CPU+network+memory are tested, now we have to write NAND flash boot loader for ETRAX FS - it turned out that it is not yet available from Axis.
For those who are interested, I can email circuit diagrams - I don't want to post it until I'm sure it does not have errors (2 already found/fixed so far). We also made some noise measurements with Micron 3 and 5 megapixel sensors and plan to make this software as part of the camera firmware. 3 MPix has about 22ke- full well capacity, 5Mpix - about 10ke- with rather low readout noise - just above a couple electrons (with high settings of analog gain). |
Quote:
Thanks! |
Quote:
As soon as I'll test the board electrically (with minimal software running) we'll be able to order a small batch assembled - then it will go to developers. |
Quote:
Thanks! |
Quote:
Andrey, What did you find for noise average db and latitude, for 3 mpixel, and 5 mpixel binned to 720p? Have you seen this brand, they have 170db latitude, and 0.001 lux sensitivity?: http://www.hdrc.com/sensors.htm http://www.hdrc.com/hdrctech.htm Some of the demo pictures are pretty interesting, and I wonder when they will go HD. Thanks Wayne. |
Guys, is there any way for me to get a small video clip of the bayer kind of 10 bit bitdepth?
Andrey, I know I can sound really stupid sometimes but I will make this question anyway. Is there any advantage about using an ATMEL AVR 32 bit RISC instead of the actual ETRAX FS? Second stupid question: http://www.latticesemi.com/products/fpga/ Lattice has some interesting and inexpensive FPGAS with gigabit output/input, is there any use for them inside the Camera framework? |
Quote:
|
Quote:
0.001lx? - easy, any regular sensor can do it with long enough exposure. |
Quote:
|
Quote:
Zsolt, you mentioned working on a lossless compressor for the FPGA (to reduce the size of the the raw image data) and I'd love to help with that as well. I've never had a change to do any FPGA work and it sounds like an interesting challenge. I'd also like to write front-end (or is that back-end?) software to provide a viewfinder/heads-up interface. Perhaps this would involve a modification/plugin for ObscuraCap; I'm not sure yet. |
I just saw an announcement for Hitachi's new CinemaStar hard drives. They could be good choices to use with the 353.
|
Quote:
The QE of the Microns is about 40% or lower, isn't it (not to mention low fill factors)? I've seen a sensor with upto 90% QE, and experiments in recent years have succeeded in getting one photon to move two electrons (QE*2). Then there is loss from the color filter, and another advantage that the FF sensor had, was that because of the 100% fill factor, a microlens was not required, so very fast aperture lens could be used. Rai, that designed the Drake camera, could get F0.85 or something lens. So, there is a lot of latitude over what the Micron can currently do. If HDRC go HD can get some of this advantage I think it could be a sweet deal. I can't get a reply from them yet, I am interested in one of these cameras for my own project, and some research purposes. Thanks Wayne. |
Quote:
Quote:
The problem is that the fpga will have to create two streams simultaneously and I don't know that the architecture and software will support that or not. Andrey? And if we somehow manage to create two streams, the Theora will be very bad quality - I don't know if it will be enough for precise focusing. I'm afraid we'll have to modify the theora encoder too (maybe with losing all the color information) and that's also not very easy. Zsolt |
Quote:
Quote:
Quote:
|
Quote:
Quote:
Zsolt |
Quote:
Quote:
|
Good ideas guys.
Andrey, I know that you are somewhat into sensor design, I am not, but I had a few ideas today, and some older ones. I was thinking that the sampling mechanism between four or more Bayer sensor pads could be shared, reducing fill factor. Using a multiplexer, the inputs of different pixels could be sampled sequentially or combined into different combinations producing an new value for binning and even debayering (4Mp binned 2*2 to either red green or blue for 720p bayer for that position). Because of the speed of internal sample the delay between pixels should be minimal. A larger number of pixels could be shared depending on noise induced on trace length, to further reduce fill factor loss. A large amount of data could be fed out in parallel because of the serial digital data nature. If you used a serial like A/D conversion, the fill factor loss could be reduced to a few percent. I turned to the thought of storing charge, and realised that the chip manufacture process is compatible with extra Vapour layering (or magnetic level layering). To stop over charge effects, the sampling method gives some resistance of course, but then continual sampling and dumping/discharge of over charge would give further resistance, but an over charge sink can be made to earth it (I have a unique process to do this (to handle large amounts of over charge) but it has greater potential and I have this in mind for other things). The circuits can be protected and the pads can be covered with layers promoting light gathering and capacitance. This allows for very much capacitance. I realise that some of this sounds suspiciously a bit like a CCD and existing cmos methods, but I think it is an alternative method that can easily be added to a cmos assembly line without having to substantial change existing components, and keeping it open for production runs of other normal chip items. What do you think about this process, your comments? Thanks Wayne. |
Quote:
|
That's O.K.
I saw your paper on some sensor function some time ago, and thought you might be into the senor hardware side. Thanks Wayne. |
Dear Wayne
Do you have a glue about the Playstation 3 and the linux disk
in France maybe, maybe middle next year ???? |
All times are GMT -6. The time now is 02:39 AM. |
DV Info Net -- Real Names, Real People, Real Info!
1998-2025 The Digital Video Information Network