I was going to reply to your other message, which I am most appreciative for, latter, but I'll condense it into here, as I am in a rush, as you can see by my jumbled thoughts:


lossless techniques

The techniques I am describing are all true lossless, the data still is reversible to lossless, you still store the differences that represent the lossless.


Advantages of using inter frame for storage and converting to intra frame for editing.

Converting to intra frame lossless for storage will quickly consumer a lot of space, and costs many hard disks. If done properly all the techniques with Inter compression added, might compress marvelously. The original intention with the inter frame compression idea was to convert to intra intermediate compression codec only when you were ready for editing, and save back to the inter frame version for storage. So you get the best of both worlds, but know that bayer lossless with 100 hours filming is a lot of drives, before you even get to extra footage in the editing process. Not completely nice, but a compromise between two problems.


First frame uncompressed

You do not need to leave the first frame without compression, you have the original image in the buffer to perform the difference comparison on, if you compress the first frame lossless then you get they original frame back on decompression. If you are talking lossy, that is a different matter, as there will be a quality difference between the first frame and others, as the others are virtually lossless differences, and the first frame is lossy. A intensive way around this is to compress all frame and decompress, now consistent quality, and then record the difference between each subsequent frame. there must be an smarter way of doing this without having to fully compress.

Maybe you could compress a heap of frames as a extended frame, therefore getting advantage of repetition represented there by the sub frames. This takes extra time, but the long buffer could be sued to smooth it out. As you can see there are too many variations ;).


UMPC/Origami

As long as you are not developing a Microsoft Origami/ Intel UMPC hardware device, I think free SDK/application development platforms should be available. I am sure there is a Microsoft cross platform development environment. With Linux, you are in the usual situation, somebody is probably is trying to develop a version of Linux for them.

At any price under $799, you are getting too close to to the cost of ITX+ monitor+ batter system. I expect we will see (try VIA Web-pads too) UMPC below $500 eventually.


Disk transfers uncompressed

If the processor is off loaded from the compression task, i think there might be enough processing power, as long a DMA is available and it is not restricted to 16MB/s. Just a very simple/easy option, and it can be compressed post for storage. Of course I am only talking about 720p25/24 here, not 1080, which I agree would be too much.


Not dual Ethernet/Disk formats

You can transmit via Ethernet for viewing and record to internal camera disk the same format, and do the intra conversion latter. But if the processor is free enough from the FPGA JPEG process, you could record to disk and use FPGA to produce Jpeg to Ethernet. If it pases through the processor then maybe not, unless there is DMA to perform the transfers.


Quality

Even if we can get max quality Jpeg on a disk, that is an improvement. Does anybody know what compression ratio max quality is? I think 3:1 or better is what we should be looking at, 2:1 is probably close to visually lossless of cineform. But Jpeg is very sloppy and imprecise, there are way to get it to compress a much sharper image. I do not know what quality of Jpeg mechanism the Elphel uses, the images look nice so maybe it already sues a better more accurate Jpeg mechanism, does anybody know? For this difference refer to the threads in those newsgroups I mention, and the compression faq related to the newsgroup, under the section to do with lossless Jpeg implementations that explains some problems with normal Jpeg unable of preciseness for true lossless.


Well the afternoon is gone again, looks like I didn't save any time anyway ;).

The human eye is most sensitive to the green channel (that's why there are two of them). And because of this, this channel carries most of the luminance info therefore the frequency content will not match with the other two colors. However, the other two colors might be joined together into one channel as you suggested.

Yes but only one pixel's missing and that pixel is usually an intermediate between the two pixels on the channel. So basically we halve the original frequency of that channel but they're remain similar frequencies. If we introduce this middle pixel and do the grayscale conversion then what we win on the smaller difference between adjacent pixels we lose on the greater variances in the frequency domain, introducing more peaks and lows into the compressed stream. So the stream won't be as smooth even if the average data rate will remain the same. So what's the use, keep it simple.

However, all of the above is obsolete if we use an interframe method which I'm starting to like more and more.

I already have an algorithm which I implemented in Java and I've done some tests with it. In lossless mode the intraframe results were about 1.5:1 on high freq data (picture of a tree with sunlight coming through its leaves) and 2.8:1 with low freq data (an asphalt as background with some vehicles on it). If we consider that the frequency of the same pixel between frames is usually much lower than the content of the mentioned low freq image then we'll be able to achieve ratios even larger than that. And we need only 3:1 (or even smaller ratio is enough if we write to disk, see below) so there'll be some bandwith remaining for camera panning/object movement which generates images harder to compress in the time domain. If the camera/object movement is really fast then the resulting motion blur will smoothen the differences between pixels anyway so we get the same frequency as if the movement was slower.

The usability depends on how time consuming will be this conversion before and after editing. After all, we're talking about terabytes. But for long-term storage (archiving) the solution is definitely interframe.

That's right but then we introduce two kinds of compression only to compress one frame of information with the first method and all the other frames with the second one. My current approach is to initialize an internal buffer to zeros and the first frame will contain the differences from this zero-filled buffer so one method will be enough. This first frame of course will be larger than the following ones, even larger than when there's camera/object movement, but that doesn't matter as it's only one frame. The reason I wrote "uncompressed" is because the resulting size will be the same as an uncompressed image's.

According to Andrey, current bottleneck comes from the encoder's speed which is around 40Mpix/s, 2/3rd of the original pixel speed of 60Mpix/s. Because the clock freq won't be raised in the 353, the maximum output rate we can reach is 1.5 times larger than the current speed. So, the current speed is 8.75MB/s, with the new memory architecture and processor we might have, let's say, 10MB/s on ethernet with Theora. Using a one pixel/one clock cycle compression we can have 15MB/s on disk, but to write totally uncompressed, we'd need 26MB/s.

See my answer above about speed bottlenecks.

Zsolt

Hi Zolt, thanks for replying, what I meant was (I did not put it correctly in my rush), is that detail is revealed by every pixel despite colour in Bayer. I know most of these facts. My ideas are just to process or use prediction, to smooth out the frequency data to real detail, to get over these problems and get better compression. My first suggestion would be a simple pre-processing stage that smoothed out the data for better compression using the existing Jpeg composer, just an add onto the existing Jpeg FPGA code. My last suggestions are more complex but still relatively simple compared to say Jpeg, and reduce the difference between the real data and there predicted results, to increase the performance of difference compression.

Yes, that's exactly what I meant (well one form of it) except I am trying tho think of ways to smooth out the frequency domain and just leave real detail left to compress.. For even better difference predation, in the comparison you can adjust ether the green interpolation, or the red or blue pixel value, to better match the ratio of the other one (even further adjusting the value by using blue Green interpolation prediction to bring predicted value and reality further together then record the now much smaller difference).

I think we might be speaking two different languages here, you seem to be on about Spatial to frequency considerations like they use in Jpeg and wavelet (and most codecs), I am talking about whole values and simple integer based compression and difference schemes, Like used in Fax standards) as well, with some mathematical prediction to reduce this difference. These integer based difference schemes with some prediction are much simpler in software and FPGA then the normal schemes, and I think less processing.

What is best is probably to test all methods and decide which works best in which circumstances, and include the best, or for better compression, if small enough on FPGA, swap between them as context dictates better results (more advanced).

Good, if you look through the Obin's thread and my technical thread, you might find additional ideas. I know that Cineform is doing 6:1 average at the moment after looking at these ideas, so I imagine 3:1-4:1 average might be a reality for us in lossless. I think the ideas presented here, and the ideas presented on that comp.compression newsgroup I told you about would help. But by all means pick the simplest ideas from them all first try them out. Most of the difference suggestion stuff is simple enough, and you can pick up the code, the pre-processing and predictive stuff is just a couple of registers for the different pixels values, a simple calculation, and an output result, much less complex then then most compression stages (thousands of gates).


I think it will not be too much hassle, and as you do a scene file at a time, or groups of takes, then it is a lot quicker.

I see what you mean, not two compression schemes like Mpeg2 does. Still with two simple compression stages we can get results. Consider this, fax like horizontal and vertical difference compression on one channel, then difference between the channels, and using your 0 difference first frame, difference between frames (comparing to previous uncompressed frame, you use similar circuits, and even the same if speed permits, for all stages. Predictive/data normalisation elements would be straight forward fro this as well.


Thanks for the accurate specs of the current systems performance. Pity that it can't do uncompressed, but it still puts reasonable compression within reach.

I should say, bayer compression is definitely the way to go, you instantly get a 3:1 improvement over 4:4:4, which is very hard to match by 4:4:4 compression. Do you know the Ogg Theora people were developing a wavelet lossless composer they put on hold to develop the Theora codec? That should be back up and running.

Keep it up Zolt, I am glad that you have ideas and are examining others. Still, it would be interesting to get Juan's input for ideas, he was doing a difference based post compression for storage.

Once again, I am about the length, I normally rewrite more to condense, but did not get away yesterday and have to rush again today.

My current algorithm is a hybrid somewhere between the two kinds you're talking about: it is integer difference-based compression but it is very sensitive to frequency content. That's why I'd like to use it now for interframe compression because of the usually very low frequencies in that domain.

The only thing accurate was the current speed. The other numbers I only predicted from Andrey's comments in this thread because nobody seemed to summarize that part yet.

I did some thinking on using wireless networks. The new 540Mbps devices haven't come out yet or if they have then they're probably very expensive. So we could only use the normal wifi 54Mbps which is 6.75MB/s, way too thin. So forget wireless: record to disk and transfer a reduced resolution lossy stream to the display of a handheld attached to the camera directly, through a short ethernet cable.

The mentioned 15MB/s disk write is the maximum the new processor will handle. The current ethernet data rate is 8.75MB/s. If we halve the horizontal and vertical resolution and reduce the quality we could get 1-2MB/s so the disk transfer could still use a 13-14MB/s transfer speed. Question is, do we have the time to encode to two different formats?

The problem with this approach is that setting the lens focus won't be easy if based on a poor quality image.

Zsolt

This is not exactly true. In 333 you could easily hit the CPU/Ethernet limit before reaching the the full speed of the compressor (that is still faster than all the Micron sensors but 5MPix - I do not count their multi-output monsters)


Also - that is not so. First of all, the Spartan-3E (compared to Spartan-3) has better implementation of DDR I/O registers, that frees some global clocks in the design. With that it is possible to use separate clocks fro memory and compressor - in 333 they had to be the same.

Also - the new chip is larger, so you may instanciate some modules twice and have twice the speed.

Next - 353 will have 5x speed of FPGA->system memory transfers possible with direct bus control (compared to only pseudo-DMA of ETRAX-100LX)

Thanks for the corrections Andrey. As I wrote, my numbers were only predictions, without exactly knowing the parameters of the new 353.

The increases in the fpga processing speed (mem/compr clock separation, double instantiation, 5x fpga-mem speed) are good news but if we reach the limit of the processor before reaching the limits of the fpga then we've no use of that.

If we record to disk we don't have an ethernet limit so the main question is now: what is the data throughput of the new processor?

Zsolt

Until we have the new hardware running, tried "this and that" the only source of the infoframtion for that is Axis web site with the documentation posted there.

Zsolt

Mihai Cartoaje has just posted, over in comp.compression, that he has added bayer support to the wavelet library Libima. Though he mentions something about lousy (Lossy?).

http://geocities.com/repstsb/libima.html

Probably worth going over to the newsgroup, and seeing their ideas. Have you had a look yet?

With simpler compression algorithms it would be possible to implement two in an FPGA, but we are talking related algorithms (that could use the same circuit if you wanted to save space and design time, but slower). For a really good hardware solution the FPGA should have a pipeline that passes the completed information to the processor, so processor performance is tens of times more than compressed data rate. Of course, I assume a common memory for both FPGA and processor is sued, which complicates things. But the solution there is to use SRAM registers on the FPGA (where ever already pre-manufactured or designed in FPGA) and keep the data in the pipe on the FPGA until it is ready to be written to storage. using very simple algorithms this is possible as the data needed to establish a pixel is only a few pixels around it. Now the data rate can be still kept, hopefully, low enough to compensate for memory timing complications. Counteracting the problems of random access to memory by buffering data on the FPGA in provide memory, or designed memory cells, takes up a lot of space but definitely will smooth and free up memory and processor operation.


I would not mind testing out some algorithm variations myself. My previous thoughts on the bayer predictive issues are becoming clearer now. It has to also do with establishing the ratio of the colours from analysis of the the surrounding pixels, and using that in the predictive value, for the difference operation, as well as the previous information I gave.



Thanks

Wayne.

No, not yet. First I want to get some results using my current method.

Yes. And we have to think in 20x20 pixel sized bayer blocks (5x5 for each channel) if we don't want to rewrite a lot of the original design. Personally, I don't want to, so I'll stick with this input format.

The 353 will include a different bus control scheme than the 333 has now. I don't know yet how it'll work. And you cannot buffer data in registers, those arent' addressable. We have block-ram in the fpga but that's too small for video buffering.

Good news. If you have results please post them here. I prefer java/jmf for this kind of testing; if you need a skeleton which reads frames from a video file and enables you to change it, I can send you one (but I don't do support :-)

Zsolt

http://www.tacx-video.com/images/HD2006/Italy/Rome A few reduced size pictures from the 333 in Rome last week.

Hi,
one question, Phil, please tell me with lens you used in Rome.
I look for a wide-angle-lens like this.

Robert

Thanks Zolt.

It might take lots of time before I am ready, some unexpected things are up. I'll probably email you when I am freer.

The register suggestion (also implying on chip ram as register) was only on the basis of doing a pixel at a time, needing only a few memory words/registers for surrounding pixels and intermediate results, not on 20*20 blocks of pixels.

Noise and compression artifact removal.
 

If anybody is interested. Michael Schoeberl, who has had experience with noise removal in medical imaging, over at the comp.compression thread has put me onto some very good noise removal software and plugin, also works on compression artifacts. There is both a still and video versions.

http://www.neatimage.com/
http://www.neatvideo.com/index.html?snim

Would lead to more compressible cleaner files in post. I am aiming to look for routines suitable on camera as well.

Have looked over the examples, and the results are pretty amazing. I have compared the before and after file sizes on their site, and mostly reductions upto less then half the original size, usually less reduction for the stills. I must admit this does not entirely make sense, I think the re-compressor they are using is not doing such a good job, otherwise I would expect more reduction on average than this. Some minor loss in detail at times, and gain in some other places, as it tries to predict what is what. But still very nice.

http://www.neatimage.com/examples.html
http://www.neatvideo.com/examples.html
http://www.neatimage.com/reviews.html

Reported to be very good too (see conclusions)
http://www.michaelalmond.com/Articles/noise.htm

Yes they're not bad but consider that these are interpolated rgb images, not bayer. Interpolation introduces noise and jpeg compression introduces more. This noise is algorithmical and can be removed later by software if correctly recognized.

You're probably aware that the cmos chips we intend to use contain analog noise removal circuits and they're really good (removing the noise digitally is not nearly as efficient).Well, unless you push up the analog gain in the chip - that seems to be the case with several images posted on the above link. And the other set of images are just poorly jpeg-compressed.

By using correctly exposed sensors with normal analog gain levels we should have no significant noise on the raw bayer images.

noise
 

The biggest noise visible on the CMOS (compared to CCD) is FPN (fixed pattern noise) caused by differences in the pixels. Actually the camera FPGA code in the 333 (and even in older 313) has the code to subtract array from the image and multiply - reading that correction data from the same video memory. This processing can be done in parallel with the compression so no slowing down.
But I never got the time to write some code to calculate that arrays without individual measurements for each particular settings (and sensor temperature) like taking an image, closing the cap on the lens and getting a dark one to subtract. It is possible to do the compensation without that - just while using the camera.

Sounds good; I mean there's room for improvement. I think I'm going to do that when the camera is ready. Seems quite simple, especially if integrated into the post-process instead of fpga.
If we use strictly interframe-difference compression then this noise won't decrease the encoding rates (because it's fpn). And if we use lossless, then we can reproduce these "black frames" without errors.

There are far better ways then interpolation to remove noise, I understand they use a number of different methods including temporal, where they compare across frames.

But you have to remember that this is only for post processing MJPEG and Theora at the moment, not bayer, though I expect you can do bayer through one of the camera noise removers listed in that review link.

Yes, but the purpose is to clean up after shooting, or if I can find something suitably simple for FPGA, it is suitable for increasing compression. According to information I read, intra frame compression performance, and severely inter frame lossless compression, is limited because of noise. Extra non consistent complexity in the image limiting intra compression, and changes in pixel values between frames reducing inter performance.

In a film set, yes, but using in the field, under various conditions, there are extremes of exposure that has to be used, as with most cameras producing noise. The SN is also not very high on these chips compared to Ibis (with proper external setup) Altasens, or ENG cameras, but probably close to a number of HDV cameras.

I personally want to increase aperture through a condenser 35mm adaptor, but these chips have a limit form their microlens that restricts maximum aperture (another reason why the IBIS5a was so good it had no microlens and you could use very fast apertures of less than 1 for more stops of light, and great latitude extension). I would like to minimise lighting (an personal experiment).


Thanks

Wayne.

I meant the source images not the results.

Okay, I've got it now, sorry.

And what do you think the maximum aperture is for the microns?

Switching topics: today I finished the development of the encoder. The source material for the tests were the following files:

http://3lib.ukonline.co.uk/cricket/imran1.mpg
http://www.elphel.com/3fhlo/samples/snakeriver.mov

I converted both of them to grayscale mpeg-s before processing. The java/jmf framework provided the decoded buffers with a bit depth of only 5 so I upconverted it to 12 bits (shifting 7 bits to the left, zeros coming in on the right) and replaced the lower 3 bits with random noise. I write this because it's not the ideal input - we could have better or worse when trying it with a real 12 bit stream.

With both of the above files I've got the targeted 3:1 ratio with lossless interframe compression. So my prognosis was good: the much lower frequency content of the time domain really helped the same encoder routine to provide better results than using it in intraframe mode.

I'd like to add that in java, the encoder routine is only 10 lines (!) long so I should have no problems implementing it in verilog... And it will be fast because it works with a 1 pixel per 1 clock cycle way. And because of its small size I could even instantiate an encoder for every pixel in a 5x5 block.

I have some more ideas for optimization but I don't want to implement them until I have a camera and the test results demand better compression performance than the current one.

Now I quit posting to this forum for a while; you'll probably hear from me again when I have a working camera in my hands. Hope this happens very soon.

Thanks,
Zsolt

What do you mean by this magic analog noise removal? And what kind of noise do you mean?

CMOS have on-chip black level compensation (still not as good as "digital" - subtracting individual pixel black levels). The only analog that can be better then digital (and it mostly applies to CCD) is true binning (with reduction of resolution, of course). The S/N gain compared to averaging of the output pixel data (can be done on chip for CMOS, always off-chip for CCD) can be better up to square root of the number of the pixels binned (e.g. 2 for 2x2 binning) The reason is that binning by combining pixel charges does not introduce any noise, so each cluster of pixels binned get noise from the output amplifier only once, and if you average pixel values after the amplifier each pixel will have the output amplifier noise added, so averaging of non-correlated noise will give you square root.

The above is true only for the noise of the output amplifier that can be a major factor with CCDs in some conditions (pixel thermal noise low - short exposure and/or cooling).

With CMOS the most visible is FPN that can be nicely removed by digital subtraction of the "dark" image.

It's not magic, I was talking exactly about the black level which has both analog and digital correction phases (at least in the micron). It is not amplifier noise that it removes but thermal noise generated by the pixels themselves. Sorry for not being so specific.

Anyway, are you talking about this method not being as good as the array substraction because the pixels used as the base of the black level are only surrounding the visible area but they're used for every pixel being read out?

Zsolt

There is no way to reduce thermal noise but cooling the chip. Subtraction of the dark level as in Micron chips is OK as a first approximation, but measuring/calculating (and subtracting) per-pixel data produces much better results.

Andrey would know, I forget, but probably at around 1.4 it will start to wash out (or was that 3 chip, one was closer to 1.6 I think).

I am impressed by the ten lines of code, but exactly what sort of system are you doing, can you describe it? With only ten lines you could almost just use an array of small processing cells (look for Misc processor cores on the web less than 16K gates each) to achieve it without custom design.

Have you got any raw bayer files to test? There might be some RAW bayer footage on the Silicon imaging camera threads, or the Drake camera thread, or Obin Oslo's original camera thread. Compressed 4:2:0 files already have much of their information removed, and the most hard to compress data is in the last 2 bits.

I will, as soon as the code works in a camera and produces the results I have now. As I wrote earlier it's an integer-difference compression with a bitstream output.

For ten lines one doesn't need to do really heavy design work... What I'm more interested in is that how this routine will fit into the Elphel design. If I take one of those cores then I might have a hard time fitting it into the 353.

I don't remember bumping into any raw videos when I was browsing through those threads. Anyway, in what kind of format they could've posted them, if they did?

I know, that's why I inserted 3 bits of random noise into the pixels - which the encoder couldn't really compress effectively so basically I had the lower 3 bits uncompressed... Hence the only 3:1 ratio.

Cool, no DCT.

Doesn't the 353 have something like 1.2M gates, the Misc core is only around 16k (I think). www.ultratechnology.com/chips.htm has a archived list of forth chips that had the FPGA Misc variants (their are other sites on the web with the more info).

They did, I think they padded them in Tiffs and the like (their are still camera raw formats) and maybe custom formats. I know Obin's for certain. You could email him. But when you get your camera you can shoot small windowed raw frames output as monochrome bit-mapped. You could get somebody to do stills here even.

If you are not compressing 4 blank padded bits we have a very promising start. The three bits of random noise should go to offsetting the lack of detail in the heavily compressed video. You could compare against the existing lossless video codecs, that I linked to on the web wiki before, even on their test footage.

Another interesting link I came across, if useful.

http://www.data-compression.info/Algorithms/RC/


Thanks for your efforts Zolt, keep it up. I wonder where everybody else has gone with their cameras?

Wayne.

Over at the comp.compression thread, a commercial oriented guy from this company: http://www.algopix.com/ has turned up and is interested in developing noise removal for increasing lossless compression ratios.

He is aiming to do a simple two frame comparison, where he uses the noise removal to also identify inter frame movement, and then compresses lossless.


Thanks

Wayne.

I did a search for something and accidentally came across that thread I posted on comp.compression newsgroup for reference:

http://groups.google.com/group/comp....ee766672dc7727

It seems to be turning up in different places:
http://archives.devshed.com/forums/c...r-1937388.html
http://groups.google.co.jp/group/com...lnk=raot&hl=ja


Thanks

Wayne.

new 5mp sensor by micron
 

look at this!

"Leveraging its heritage in high-speed, high-performance imaging, Micron will unveil a new 5-megapixel high-definition (HD) image sensor for mainstream digital cameras. The new sensor is capable of capturing video at 60 frames per second (fps) in 720p (progressive) format and 30 fps in 1080p format. Micron will begin sampling this sensor in the fall of 2006.

Designed specifically for digital video camcorder applications, Micron will also introduce a new HD video sensor that captures 60 fps in 720p format. Designed to work with long-range zoom lenses, the sensor was built using Micron’s stunning 2.2-micron pixel technology. Additionally, the sensor has additional pixel area for image stabilization, which reduces the effect of shaky and blurred images typically caused by jittery hands or camera-shake. This sensor is expected to begin sampling in the first quarter of 2007."

taken from:
http://www.micron.com/about/news/pre...A76239EFA2B68E

I'm working on something similar -- ObscuraCam -- which is a "heads-up" recording program specifically for filmmaking; and also a post-processing program to convert the raw files into something useful.

I've just recently discovered this thread, and I find it very intriguing. The Elphel 353 could be an excellent choice for a DIY cinema camera.

I just realised it wasn't Rob Loham posting to the thread. Long time no here, still got the same email?

So, still doing the Obsura, how is it going?


Actually, Zolt, what is happening after a month?


Matteo, I think that is the one Andrey aims to use.

Good to hear from you Wayne! Yup, same e-mail address.

I re-started the project a month or so ago and am working on it as I have time. I'd love to get my hands on a Sumix M73 or an Elphel camera ... wish I had some extra cash.

If you contact Andrey he has special pricing for developers, or maybe ask him for a loaner.

I find those sourceforge pages hard to follow, what's the level you are upto?

If you look at my Technical thread, you will find updates on some interesting technologies, except three or so new camera threads. The last few pages have the most relevant info to you. I don't have the technical link here with me, but here is another link that I have open in the background, on a sensor technology that has 170db range (latitude?).

http://www.dvinfo.net/conf/showthrea...45177&posted=1

It's basically alpha quality, currently only supporting the SI-1300CL.

The capture software will do 1280x720p 10-bit raw @ 24fps; on my system, this requires two hard drives in tandem. Multiple-drive support is built in; of course, you can use a RAID array or a very fast drive. It's a full-screen "heads-up" UI using DirectX. I'm going to investigate moving to OpenGL to be more portable.

The conversion software will process the raw images into 16-bit TIFF. Eventually it will support OpenEXR and DNG (for processing elsewhere). It is currently command-line only.

[Edit] One of the issues going forward is that nobody I know of has the SI-1300 and I doubt anyone will go out and buy one just to use this software. Obin was doing something similar (I didn't read the entire thread) and tried the SI-3300 then gave up (as far as I know).

On the other hand, the Elphel is attractive because its' firmware is also open-source, making it an excellent match. If the 353 is affordable I'm going to be very tempted to buy one.

Hmm, Rob, I seem to have an M73 sitting around I havent gotten to use much lately. What are the chances you'll be able to support it? I've gotten a little ways with my VB.net capture program and the sumix api but have run into some issues and now have next to no time to work on it and may not in the near future. I might be able to lend you the camera or sell it to you for a low price or something. If not, I'm still very interested in your project, so please keep us updated on your progress. The elphel 333 also looks like a good option for your program, but it is limited to outputting jpegs over 100BT, but it could be great given a good interface for controling blanking and LUTs.

I already downloaded the API and it looks quite straightforward -- certainly no more difficult than the CameraLink API I've already implemented. I would love to borrow it from you and work on support for it. If I have some success (and I can find some cash) I may be interested in buying it from you. Feel free to e-mail me directly.
I agree, the Elphel camera is very cool, but the 353 sounds nearly perfect, so I will probably wait for that one. Or I guess I could start with the 333 ... well, one thing at a time.

Thanks for your interest!

I would suggest supporting both, as direct X is probably goign to give the best hardware support options.

What computer hardware are you using to achieve this? From what you are saying, you don't have camera to test it.

Yes there are a number of options. If you approached Steve from SI you might be able to access some of their stuff and their workflow, if you approach David from cineform, the cineform Raw is available for license. The codec being developed here is probably a very good idea (not to mention previous work by Juan and Jason under different projects).

You do not have a camera, what are you doing your testing on? Obin was offering to sell his, maybe there was somebody else to.

The latest advice on getting the thing to run full speed (see my technical thread for more details). Is that Epix (is that the name, I forget, you know the one I mean) latest PCIE one lane capture card has buffering, and will quiet happily continuously record without problems according to them. They claim it has just enough buffering to iron out the problems, but to record to hard disk requires the more advanced software, or to roll your own with developer software.

Speaking to an local distributor of another camera (I think) about their setup and capture software, they informed me that there was a simple trick to getting their software to capture it to continuously without dropped frames or timing difficulties. I forget what my thoughts were on this, he wouldn't say, but I had an idea what it was about.

About main board hardware requirements: Black magic has a Intensity HDMI capture card, and looking at the requirements they mention a number of recommended boards and chip sets, but recommend against any that use an integrated graphics in their chipset (though, I imagine a discrete graphics card will be OK with them) because they find that the graphics access to main memory stuffs up the bandwidth flow. I imagine that a new chipset like the Intel G965 express (would wait for finale drivers and see if should wait for stepping after c-2) possibly could be different though, because it uses dual channel memory, and bandwidth is 12.8GB/s.

I found a number of companies that could do what is required for film recording at significantly cheaper prices than what SI offers, even using Dalsa.

Yes.

Noel, could you post a link to what these issues are?


Yes, Rob,

The 333 is good for experimenting with, but is too limited, unless you want to experiment with output grey scale jpegs of the Raw pattern over firewire. Which I am still interested in what results anybody could get out of that, compared to same frame at 75% +. Andrey is doing prototyped 353, you might be able to get a big developer discount for that, as he normally does.

I forgot to mention, the Epix camera card combos are cheap.


To everybody else, I have researched the Jpeg issues, and not all codecs are created equal, for instance the Apple one. That 75% 4:2:2 is the minimum that we should go for (or gray scale of the bayer raw) I think 4:4:4 is above that.

Since I already have DirectX support written, that's probably a good idea.
I do have the SI-1300CL, and the software works with it. I don't have a Sumix camera, which would be a far more affordable (though less capable) choice.
It sounds like the Cineform codec is excellent, but my goal is for this project to be entirely open source.
There is a codec under development? I must have missed that -- where is it?
I can get the camera to run full speed up to the limitations of my current system. I have only 32-bit PCI and no PCIe slots, and no funding to upgrade at the moment.
HDMI is certainly interesting, but probably way beyond the scope of this project for now. Besides, are there any cameras out there which would squirt raw (Bayer) frames through HDMI? Otherwise there isn't really much point.
Yes, it would be cool to experiment with, but the 100 Mbps is just too slow. Firewire? Last time I checked it just had Ethernet. Hmmm ... I wonder if the JPEG FPGA core supports 16-bit grayscale?

Last few pages, Zolt, is working on it. You could probably get hold of Juan/the Obin one if you asked nicely. I think as many techniques you can combine the better. I suspect Zolt, however, will surpass the other ones we had with a richer feature set.

I've questioned them carefully on custom modes, and this looks like the case (unless a camera could be made to output a bayer pattern as a monochrome image). It is 4:2:2 with upto 8 to 10 bits (depending on the camera). the card is $249. Now, most of these cameras will not have access to the quality sensors the cameras we are talking about do. I also have a alternative possible high quality HDMI capture in mind.

Whoops, my bad. I think it does do above 8 bit monochrome Jpeg, but if you consider that 8bit 720p bayer is around 180mb/s+, the photo jpeg option makes sense (but the 333 is very restricted in bandwidth, so the 100mb/s might not be too useful (discussion several pages ago, and probably 4 pages ago). I would go for 10bit packing, if available, and forget the 16bits.

D'oh ... wasn't paying very close attention there, sorry. Now that I've read back through the thread, that does sound very promising.

Thanks!