Obin

I've had a look at your pictures, great, I love the colour, beuatifal. I'm impressed and would to see the results from a 1080 or SHD version oneday. I noticed all the artifacts that people were talking about, and that is why I think that Bayer will take away from the resolution and detail quality for resolution upscaling for the big screen (not to mention green screening as the bayer does not give a correct per pixel colour edge).

My latest Opera Web browser or Radeon 9000 driver, appears to be performing some sort of upscaling/deblocking, I can't see a square pixel even at 1000% magnifcation, and it looks good (except colour averaging of the bayer).

How about using a test chart to work out the real picture specs (latitude, low light and sensitivity), or side by side comparisons with the DVX 100 on the same images? Alltogther it leaves SD single chips for dead, and even the colour of 3 chip SD (I hate oversatuation), this is probably the sort of colour we will eventually see on single chip HD cameras in the future. Definetly good enough for cheap indie film, it looks almost natural (the latitude and falling away to black and blowout being the biggest variation). I think your way ahead of 28 days latter.

Obin, about NLE editing computer, we are close to the technology of being able to fit the NLE in the box with medium to high comrpression, maybe not this year (unless a low powered multiple processor server board is availble) but maybe next, so you can NLE from the camerra connected to a usb hub (for mouse, keyboard, external drives) and monitor. Your system is also the lightest camera in processing requirements, so you probably can do that right now. Your camera's USB2 connection, a nano-itx board (fastest) and a single laptop drive might be able to handle a pure packed bayer image. If you can get a faster cpu you might even be able to compress. People get caught up in the camera link thing (and I wonder why SI don't pack their data in the head, it is a simple circuit/proceadure) but a PCI cameralink board should have more than enough bandwidth for 1080. I wonder if it has something to do with the unreliability of USB2.0, or the fact that the data is read so quick (unbuffered) that it maxes out USB2.0? Steve?

<<<-- Originally posted by Steve Nordhauser : Although it is possible to adjust the vertical blanking time somewhat, what you proposed hasn't been attempted yet. It might take some firmware changes in the camera. What Obin was proposing is based on the rolling shutter artifact. Each line is sequentially read from top to bottom. That means that there is a temporal difference on any image of one frame time from the top line to the bottom. The faster you go, the less the difference. Obin wants to readout at twice the frame rate he needs and toss every other frame. This will get him the desired rate with no timing adustments but reduce the single frame time in half.

I will have to think about what Rob suggested though - extending vertical blanking for a full frame time.....hmmmm. -->>>

The problem with these scheemes is that you will need as much shutter time (every 24th of a second) as possible to accumulate light, and also to blend movement from one frame to another (to stop the jerky motion). I think I'am prepared to live with upto one frame difference between top and bottom (as motion looks disorienting anyway), and at higher frame rates the jerkness dissapears and the motion difference will be much smaller anyway. I think it's possible that the horizontal oreintation of film shutters might be to get rid of the rolling shutter artifact, as movement tends to be horizontal in one direction. Whereas on the normal Video we are stuck with up and down movemnt, which is great for an overhanging camera on a assembly line.

Steve, for rolling shutter, am I understanding it right? Can you read out much faster than the 24th second exposure time, this should reduce the difference between top and bottom to much less than a frame?

One question I would like to ask about these cameras, is it possible to adjust the shutter, and gain to maximise the latitude of these cameras? Most of the time we have plenty of light and want to maximise the latitude (and minimise the blow outs), and most components have an optimum setting that expands their responsiveness. We then could use manual aperature to adjust the amount of light, therefore adjusting the range to teh desired level. So will this work Steve?

Steve to justify yourself to your boss, SI and Sumix are at the forefront of supplying this new market. But if you want the sales it has to be simple enough (aswell as good and cheap enough) to offer true pro performance at prosumer HDV prices. Ideally that would have meant either complete software, capture (with simple effective external camera/capture controlls/interface), and lense adaptor, pc computer, and display options worked out (which then can be sold to buyers), plus bundeling with one or more NLE (like Prospect HD) would be good. On the more advanced level (using the freeware prgrammable gate array work of that Russian fella (or a modified server like multiple processor mini-ITX with cameralink interface) a complete backend box system with raid storage, that can be sold to owners of any manufacturers industrial box camera. But neither SI or Sumix has expressed any desire to do offer complete simple systems, and that scares a lot of potential buyers, because it hasn't been worked out. So my guess you might be able to sell 10-100 a month as it is now until we work it out (then maybe 100+), but many more people would by a complete worked out package, and that is what people are trying to do on these threads, to effectively use SI and Sumix cameras. But what you are doing is helping to establish a new market for your boss. I myself, look forward to seeing your new HD cameras, I hope there will be 10+ stop box cameras, operating at below 2 lux, rendering true 1080 effective resolution and even three chip 1080 for $1-$3K. As you can see from the discussions that the requirements here are different from machine vision, for beautifal pictures, range, sensitivity, resolution and accuracy.

<<<-- Originally posted by Steve Nordhauser : David,

The word I hear in this group is that they don't want to compromise on what I've been calling pre-post processing - the Bayer filter, RGB->YUV, compression steps. If this can really be done in real-time, all the way up the camera scale, you have an impressive product (or will when the cheap camera link cameras are supported) and I would suggest that it is not worth anyone here writing their own code. $1K to record fully processed and compressed data with a preview window, maybe with basic camera controls would be great for the people here. -->>>

But what about the $500 cameralink bundle packages with the Prospect NLE lite software packages (actually I would prefer to pay $200, but I don't think so ;)?

<<<-- Originally posted by Steve Nordhauser :
I think the biggest processing and recording issues are a complete understanding of any step that is a potential loss of quality - like the Bayer filter. -->>>

Yes, hate bayer filter, love bayer filter (it is much of a love/hate relationship for me so far, but offer me a 8mp bayer camera and I'll forgtet all about it ;)!

<<<-- Originally posted by David Newman :
through the trouble to design and build your our camera you don't want to compromise on the quality of it output (i.e. you want 10bit or better.) CineForm Prospect HD is priced the way it is as is designed for multi-stream real-time 1920x1080 compressed and uncompressed workflows over HD-SDI. i.e. expensive hardare and the software to manage it. Do you guys need that?
-->>>

David, we don't need that but some do. So you could offer two light versions of Prospect HD, one with HDSDI support high end support, and one for DV, HDV, HDV2, box cameras, and low end professional camera formats. I'm aiming on using pc interfaces, disks and component i/o to do my transfers.

<<<-- Originally posted by David Newman : >-- Originally posted by Obin Olson :

It is designed for HD online. It is equilevent (or better) than D5 (which is YUV 4:2:2 10bit.) D5 is the workhorse standard for HD masters.

HD> David why YUV 4:2:2??? whynot RGB 4:4:4 with 10/12/16bit?
..

YUV is a more natural compression format -- optimized for the human visional system. RGB compression is less efficient. 150Mb/s compressed RGB would look worse than 150Mb/s YUV 4:2:2 (this is even true for 4:4:4 YUV although to a lesser extent.) Basically is you want the benefits of compression, YUV is the way to go.

> the whole point that this camera can shoot images that you have more control in post is 4:4:4...maybe 4:2:2 would be ok if it was high bit depth...?? -->>>


Yes that's the name I've been trying to remember, D5, I think there is also a 4:4:4 storage format as well?

My take on how good 4:2:2 is:
Industry have claimed that reduced colour bandwidth signals are a good compromise to 4:4:4 for years but I've been able to see the obviouse difference, and my eyesight is not that great. The problem is that eyesight maxes out at 2400dpi in B&W and and 1200dpi in colour, and HD is nowhere near that (approx 75dpi and 150dpi, equivalent to 150dpi and 250+dpi because it is a emissive display rather than a reflective paper display). Even taking into account the reduced resolution of the eye as you go out from the center, the maxium colour resolution of 720p is so low you would probably have to be legally blind to be completely unable to pick the difference between 4:2:2 and 4:4:4. But from my own observations and estiimates the situation is helped because in a semi trance thought (or watching movies) people tend to slightly defocuss their vision and the mind starts integrating nearby pixels at above 150dpi (720p). So I take 720p 4:4:4 to be the mininium suitable resolution for theater (except for Imax, or if your sitting near the front)) that also offers suitable detail, colour and res quality for resolution upscaling to 1080+. That is probably why they upscale SD for cinema release (but you will notice that the image details are not 150dpi small or are blended too much).

Now with 4:4:4 the colour accuracy should help a lot in the accurate upscaling (because at 300dpi, upscaled 150dpi 4:2:2 colour detail canbe inaccurate and/or equivalent to 4:1:1 double hieght 300DPI, now go to 450dpi (around SHD 8mp) 6:1:1 triple hieght colour 450dpi. At 4:4:4 150dpi you should end up with 450dpi 3:1:1 triple height colour instead, but still 150dpi accurate colour areas and detail so the colours should be well blended, and match the corresponding detail edges because of the correspondance between detail and colour (in a non bayer system). This is also very important in effective special effects,as the boundaeries should be easily and acuratly bleneded.

It all seems trivial, I know, but that is the unfortunate nature of the movie business. I also have my own unique upscaling concept that I want to try one day on true 4:4:4 footage.

Now it maybe true that 4:2:2 offers better compression, but I imagine that is because we are throwing 1/3rd the information away that the eye does not really notice at these resolutions.

I think implementing 4:4:4, bayer, and higher bit depth side support in your software would be good. It would come in handy for regular customers too, as the industry is moving to single chip consumer cameras, three chip prosumer and professional cameras, and bayer movie cameras.

Thanks

David. I am still going through this thread before I get to your over post you told me about (spent 17 hours + on catching up on the three threads, so far)

<<<-- Originally posted by Rob Scott : Product -
http://www.vinc.com/product.asp?ID=56&PID=21&SEQ=2

News articles -
http://www.cdfreaks.com/news/9852
http://news.designtechnica.com/article2925.html -->>>

If you look up Sigma Design on the web (even www.via.com.tw for embedded eden itx formfactor DVD players) I think they are the ones that make the chip sets for these. They ussually list their DVD player manufacturers somewhere on their site, or mention them in their news sections.


<<<-- Originally posted by Mike Metken : Guys,
..
There is a Sony HDC-X300 1080p camera that costs $15K. Canon HD auto focus/manual lens for it is $7K. It outputs HD SDI. If you can make the storage box work with this camera, you've made a Sony F900 killer.
..
Mike -->>>

Is that the 1440*1080 chip version there using in the Sony HDV1, and Canon XLHD?


<<<-- Originally posted by Les Dit :
There are a couple of other methods out there, one from Kodak ( patented, of course ) that seems to deal more with defect management than the actual demosaik itself.
-Les -->>>

I think somebody said that the Kodak routine was the best one out there.


<<<-- Originally posted by Steve Nordhauser :Maybe Obin could do some test sequences of fast panning on objects with large vertical lines (buildings?) to test the rolling shutter artifacts at 24 and 48fps. I really don't know how objectionable the skew really is - everyone talks about it but I've never seen images other than packing labels on conveyor belts.
Steve -->>>

:)

Well guys your doing a good job, and answering many of the questions I had, thanks, hope it all goes well.

<<<-- Originally posted by Obin Olson : uggh...I posted what i have been doing with HD at dv.com and got a bunch of child-like responses. Guess I will stick to this site! -->>>

Don't let it faze you Obin, I have seen the same on other forums, they probably will sing a different tune when a worked out system is availble. You probably will be one of the most interesting people on the forums when you have it worked out and show off real work.

Have a look at these, they might help cheer you up.

www.hoojum.com/index.php

http://hoojum.com/gallery/slideshow....e&slide_full=1
www.mini-itx.com/news/nanode/

Seen that plugin article, at least we know who has the best lossless codec at the moment "BitJazz's", sheer is close behind.

Everyone: I've gone through the whole thread and merged almost
all posts that someone made back-2-back (except for your last
large ones above here Wayne). Some posts counts has come
down as a result. No information has been removed!

Please try to avoid posting several times in a row. Stick to one
post unless you have very large posts like Wayne above. Thanks!

Steve: how can my numbers be an average transfer rate? At
fixed framerates this should be a sustained (uncompressed)
transfer rate (one way, not two way).

Obin: Can you please answer the following that was still left
unanswered?

1) do you have a RAW 10 bit pre-bayer file for us? This CAN be a lower resolution STILL file. No movie, no high res.

2) which lens(es) are you using with your camera now?

3) could it be the stuttering in that movie is due to your harddisk not keeping up?

4) which camera settings did you use to record that movie? (gain / exposure)

5) did you do any color correction or other conversion to the material?

6) Which Bayer algorithm did you use?

This are important questions to the people looking at also getting
a chip or not...

Rob S: how do you determine how many FPS you can write to disk?

Sorry Rob, so late, and I was trying to address significant posts to people individually. I don't think I will have much need to post here in the future as people are allready asking the right questions, and most significant issues have allready been covered (and I think that will be the trend in the other threads to).

Thanks Rob, your effort is most appreciated.

I generate a set of bogus frames (of the correct size), shove 'em out to disk and keep track of how long it takes to write out n frames.

Er ... well, that's how I'm doing it with the code I'm writing. Is that what you meant, or was it more general?

Wayne: no problem! You wrote a lot as well. Your input is much
appreciated.

Rob S: well, both general and in this case. I've always had a hard
time wrapping my head around framerates and things like CPU
usage etc.

I was figuring you have one thread filling a circular buffer and
one thread reading is. When the the filling thread has caught up
with the reading thread you cannot write the data fast enough
to disk. How to express this in numbers....

Ofcourse you can write 1 GB to disk and time how long it takes
and divide that as well indeed....

It's just that I've never really dived into things like that.

Yeah, that's exactly right. I don't really have a scientific way of doing it. I have a "control block" class that acts as a gateway to the circular buffer. The frame generator grabs a buffer and stuffs in a frame at a predefined rate (24 fps, 30 fps, etc.). If the "frame generator" stuffs in frames too fast for the "writer" to handle then the "control block" marks up a "missed frame" but continues on. The "generator" runs for a preset period of time and stops. At this point, I stop disk activity; then count up the total time elapsed and the number of frames actually written to disk.

(Edit - at the end I also can determine how many frames were skipped.)

OK.
Rob L: average vs peak clock rates. The average is the visible image size x frame rate (1280x720x24fps = 22.1Mpix/sec). Due to blanking time, for the SI-1300 to do that rate, the pixel clock is 27MHz. This is the rate that, during image readout, the bus must meet. With an HD with a big buffer, the average # works fine.

Wayne: Rolling shutter. I think you have it. The rolling shutter 'artifact' is tied to the single frame readout time. The time from the first line read out to the last is always one frame time. You can run the SI-1300H up to 60fps. This will drop the time for one frame from 1/30 to 1/60 sec, reducing the artifact. As you say, this will reduce the integration time (light sensitivity). UNLESS (this was the hmmmm part), you read out the frame at 1/60 sec and then have a long vertical blanking time - all the pixels will continue to integrate during the trash frame time. Now you are integrating at 1/30th sec, reading out at 1/30th sec average, but the frame you read is done top to bottom at 1/60th.

Wayne: On making money. Yes, we will be interested in building systems and creating bundles. I have to wait for my R&D group (you guys) to come up with a product. Seriously though, I will always be clear what is public domain to future customers. I don't have the resources to solve all these problems, but I may help out. If that BitJazz codec does what it says - 2:1 lossless faster than the speed of light, I will consider negotiating a volume license and give a license away with the cameras. I do have the corporate blessing to be helping here. I think great things will happen.

Wayne: USB 2.0. To get high data rates, you eat a fair amount of CPU time. Also, transfer rates are highly dependent on the host controller. Intel ICH4 and 5 south bridges are 2-3x faster than external controllers. The typical USB interface chip has small FIFOs making real-time tough at high rates when you don't want to drop frames. We don't compress in the camera because either you want lossless, which only gets 2:1 or lossy and then you need to be able to select a lot of variables. CPU compression and raw recording are more cost effective.

Obin,

Right now Bitjazz is nice, but it's only 8-bit. I also believe that's real-time ecoding for 8-bit SD video, not HD video.

On the rolling shutter topic again:
How slow or fast does the shutter have to be in order to get away from the artifacts. From the footage that I saw on the wmv file, there's apparent stretching artifacts at all. How bad would it be at 24fps, with a 1/24 shutter speed? Also couldn't we just blank for 1/48 of a second and then take the next frame on the next 1/24th of a second, so it's imitating a mechanical shutter at 180 degrees (like a film camera). I think this was mentioned before, but I'm not sure what happened in the response. I heard something about a firmware upgrade needed.

The problem is that if we clock the chip at a high Mhz to satisfy the problem, and drop frames, then we're loosing the ability to shoot slow-motion. Not good.

I believe the firmware upgrade was just to allow a long blanking time. By setting it to 48 fps and then grabbing every other frame, we get the same effect. (Unless I'm missing something.)
The way I envision it, the software would adapt to what you're trying to do -- if you want 48-60 fps, it would not try to skip frames in between. The skipping would only be valid in the 24-30 fps range.

I see what you're saying, but then you have the problem of too much motion blur when shooing from 48-60fps. Typical film shutters work at half the frame rate. So for 48-60fps, we need a shutter that's working effectively at 1/96th to 1/120th of a second.

Obin:
I think there are two sets of test images the gang would like to see. First is a horizontal pan with lots of vertical edges. This should show up the rolling shutter problems. Or, a stationary camera view and someone driving by.

Second is Les has asked to see two consecutive frames - no movement between them. He has a lot of experience in noise analysis and will help understand the requirements for image enhancement.

Group:
To sweeten the pot, anyone who *substantially* moves this project along - programming, research, testing can have a 20% discount on a camera or bundle purchase from SI. Again, Rob coordinates the software, not me. Obin, you are clearly carrying your load on test image generation and ponying up for a camera purchase. You don't have to be a programmer, just take the lead in some valuable aspect of getting to usable tools.
Steve

With this particular chip, I don't think we have any alternative, unless we use a mechanical shutter.

The Kinetta's not using a mechanical shutter, only a mechanical one. I saw it myself. And it's going to have a lot of nice frame-rate features, so that must be feasable with this chip in an electronic shutter mode.

On a second though, the kinetta's going to use an Altasens chip, maybe there's something different with that chip than with the Micron.

Another thing we need to realize is that this Micron chip was made for digital still cameras (at least that's the way it's listed on their website). You can get very long exposures with those cameras, how come again there's no problems with rolling shutter artifacts. Also be aware of the fact that consumer digicams don't have any mechanical shutters, just electronic.

I am doing my best to lead this along... I should have been working today instead of this stuff but I was not ;) anyway here is an AMAZING codec

http://www.bitjazz.com/sheervideo/

that thing compressed the 1300 tiff files from 580megs down to 109megs with NO visible loss in quality whatsoever...amazing ...I was playing full on HD off of my firewire drive today with NO problem at all...15-16megs a sec as it ran the clip!!!! then I took the image into after effects and whacked it out to see if it would fall apart from the compression...not at all, it looked great! Much better compression then the Panasonic varicam has.

And they are in BETA with a 10bit version of the codec!!! yeeeee

<<<-- Originally posted by Jason Rodriguez : Obin,

Right now Bitjazz is nice, but it's only 8-bit. I also believe that's real-time ecoding for 8-bit SD video, not HD video.

On the rolling shutter topic again:
How slow or fast does the shutter have to be in order to get away from the artifacts. From the footage that I saw on the wmv file, there's apparent stretching artifacts at all. How bad would it be at 24fps, with a 1/24 shutter speed? Also couldn't we just blank for 1/48 of a second and then take the next frame on the next 1/24th of a second, so it's imitating a mechanical shutter at 180 degrees (like a film camera). I think this was mentioned before, but I'm not sure what happened in the response. I heard something about a firmware upgrade needed.

we can capture at 30fps and run the camera at 60fps and then when we wnat to capture 60fps for slo-mo we just keep all frames..no biggie also I can still shoot at 24fps with a higher mhz like 54mhz on the camera, this will allow for a nice image like in the wmv file...if you put the mhz down to say 27 the rolling shutter is VERY VERY bad as you pan the top of the iage lags way behind the bottom...I think you guys need to calm down about this..it's not that big of a deal and I know of atleast 2 ways to deal with it..no problem

Obin,
The truth is in the pudding, whatever that means. Since we know what kinds of shots will be the worst, shoot a few and post them. I'll try to get to it but I'm not impartial (Wanna buy a camera?) and I'm not a cinematographer, I'm an electrical engineer (anybody get the DeForrest Kelly flashback from Star Trek? boy am I tired).

I think rolling shutter is only an issue for medium frame rate. If I were to expose for 1/8 sec and read out in a 1/60th of a sec, the top to bottom blur would be minor compared to any motion blur.

For testing with the current software and hardware, Obin, if you can't get the frame rate you want, use a smaller window. The frame rate is the issue - must be 24fps to be a valid test.

Bitjazz: No miracle, it is not lossless. 5:1 is not lossless. They might have a patent worth searching to see what they do. (don't infringe, that is intellectual property). We do need to understand the losses. They could make their own artifacts under certain conditions we don't know now. Remember what I said about fully understanding any step that has a potential effect on the final image quality. Compress before recording is the holy grail. This could be good. Even if we do the R,G,B separately into a non-standard file and provide a tool for crunching them back together. And we want 12 bits. But 8 or 10 is a fine start.

Sorry Steve, I'm not really following this thread too closely, but the Bitjazz Sheer video codec certainly is lossless according to them and according to my own tests.

Obin: we will calm down when we see some footage. Besides
24 fps I would also like to see the same footage at 48 fps to
see how much it goes away. The most easy way is to have a car
going from left to right and right to left and have the camera
in a 90 degree angle. The car should be driving a real speed
(ie not 10 mph or something).

It is not a problem you can fix. At 48 or 60 fps the problem will
still be there, only lesser. So you might not see it, but it will be
there because it is inherent to a rolling shutter.

Can you please respond to my question list that I put up above?

Steve: it looks like (according to their claims) that the codec is
lossless. Or so they claim. We could easily verify this. It looks like
it is only out for the Mac platform at the moment though. Also
they claim to do a 2 - 2.3 compression themselves.

I think this adds up. Think about it that Obin's TIFF files are 16
bit!! with only 8 bit information in them. So if you divide 580 by
two you get 290. Divide that by 109 and you get a 2.6:1
compression ratio which is basically what they claim.

I'm wondering if we can do something more efficient since we
know we will be working with Bayer data and they don't. I mean
in storing the data to disk. We still need to do Bayer conversion
after this so it might then be a very interesting codec to use
for editing (solves a lot of our problems). The Dalsa L3
compression is pretty similar in rates, but probably far far far
more expensive.

There is a text on compression for such chips which can be
found at this location. I'm not an IEEE member though...

Everyone: they are looking for beta testers so this might be
interesting. I'm wondering if they are supporting all sorts of
resolutions as well.

Steve: I have been looking a bit into pre-recoding compression
before laying it out to disk. I'd much rather have a single harddisk
then two or more. Ofcourse it should be lossless and fast.

Rob on BitJazz:
On their web site, they claim 2.4:1 or so for YUV. They also say they can do RGB but don't give numbers. This is realistic for lossless. I was commenting on Obin's <<from 580megs down to 109megs with NO visible loss in quality>> . This is lossy. I'm sure that they are doing more than packing bytes. Using the basic tools (Huffman, RLE and some varients that are common) you can do 2:1 lossless. Very image dependent though. And *Very* noise dependent. Remember that they are talking images after the Bayer de-mosaic step which puts that into the real-time path. I'm thinking the best method is to create a red, blue and green separate buffer and RLE each one. That should be doable at any resolution in real-time and save the Bayer for some real crunching. We need to hear from someone deep into Bayer. I'll try to get to the library and get a copy of that article.

Rob, I don't think it's the framerate but what mhz you shoot at...I have shot at 24fps with huge rolling shutter and then put the camera mhz up and it goes away at 24fps

Steve, what I got was VERY acceptable for production and I could edit from a firewire disk drive! I would be happy with that codec..for really important stuff you can use 16bit tiff files

it's such a pain in the ass to capture with Xcap I will wait and see if streampix fixes the dll file and then try and shoot more...I have seen enough that I don't have a need for more. I do understand that you guys want more ;) and will do my best to help

1) do you have a RAW 10 bit pre-bayer file for us? This CAN be a lower resolution STILL file. No movie, no high res.
I will look on the hard drive today..problem is i never have them i have 10bit packed into 16bit tiff files

2) which lens(es) are you using with your camera now?
el cheapo CCTV lenses, 25mm and a 75mm - yes I am sure the image would be better with a higher res lens

3) could it be the stuttering in that movie is due to your harddisk not keeping up?
I have issues with keeping the camera shooting at 24fps with Xcap, it could be my hard disk sure

4) which camera settings did you use to record that movie? (gain / exposure)
that is 3 shots...they are all 8 bit. the truck was exposed for the hot background and then I pulled truck up from the shadows
the shot of me is exposed for my face and blows the crap out of the backgorund
the flowers? dunno

5) did you do any color correction or other conversion to the material?
flowers are raw colors, everything else is "fixed"

6) Which Bayer algorithm did you use?
dunno whatever Xcap uses

This are important questions to the people looking at also getting
a chip or not...

Obin, you are doing great. On the XCAP, try recording to memory since your test clips are small, then you should not stutter. Norpix should have your new .dll files today.

I'm a little not clear - you are able to record at a fixed frame rate independent of the pixel clock? That is news to me - I will have to check it out. I would suspect you occasionally get duplicated frames - I will talk to the Epix technical people about this.

XCAP uses a very basic Bayer as default. I'm pretty sure that you can change that under the 'colors' tab in the left hand camera control window. I think they support a number of algorithms (just saw this yesterday) in the latest version. One of the nice things about Epix and Norpix is that they never charge for upgrades - just download the latest version.

not sure Steve, I can just type in 54mhz and then shoot at 24fps..don't ask I have no idea! :) but it seem to work..Maybe it's not working at all, it's hard to tell when you can't just type in 24fps on this crappy software..What I do is slide the frame period up and down till the "video" and "Display" read about 24fps seems like they vary from 23.97 -24.2 ...this is one big reason we need software that LOCKS in 24fps 30fps 48fps etc...it's got to be a constant framerate, no fluctuation

The Sumix info is up at the Viper thread, and it is good, Altsens sensor to, but no 3 chip yet.

This is something I forgot to post last night which I just mentioned in the Viper thread, that maybe of some interest to Rob, and Rob, and Steve:

I have some cheap tech that could do the compression without FPGA, and be programmed in weeks. I have spotted it some time ago, it has an array of parralell risc processors with memory and fpu's, at extremely high perfomance and low power, but only just remembered it. That would move developement time of this part of the circuit up 10 times. Steve if you would like to pass it along? This is not the other tech I mentioned before that was mainly for PC's processing. I am such a dope not to remember this earlier, this would let even a low speed PC do all the capture, compression, and editing you like (as long as the software can take advantage of it).

www.clearspeed.com/news.php?page=pr&pr=2

http://www.clearspeed.com/technology...c7694795e722fb

www.clearspeed.com/products.php?page=si

www.clearspeed.com/products.php?page=faq

I have included all these links as it is hard to get an idea of the extent of it's capabilities from one page.

Summary:
- from 10's to thousands of Risc 32-bit processors with Floating Piont untis
- programmable in C (Rob could move code to it).
- can act as main processor, or coproccessor
- very low power at very high performance, or even more performance at higher power levels.
- 64 bit version coming.

With something like this, a cameralink comrpession board could have been within reach of the Robs.

We better watch out with recording at 24fps. For the guys in the audio department, that could end up being a REALLY bad idea. Right now, everything shot for television at 24p is really shot at 23.976 to keep compatability with 29.97 NTSC. If you shoot at 24p and then try to go back to NTSC, and your audio is at 24p, that could spell problems. These are just a couple things I've learned from shooting on the F900 where you have the choice between both 23.976 and 24p. The 24p option and NTSC always meant trouble.

BTW, normally with film, the audio is slowed down and synced with the video in the telecine, which is also actually slowing the film down also from 24fps to 23.976.

I may not have mentioned it, but from the beginning I was planning to have a standard vs. NTSC timebase option.

So in the UI you would have the option of any frame rate -- 24, 25, 30, 48 -- even 27.5 I suppose -- and then separately you would select NTSC timebase. I think that would keep the UI a bit cleaner -- what do you think?

hmm...streampix is working now, just captured 48fps 8bit! using a ide raid 0 2 drive setup now...gets 51megs/sec single SATA drive gets 40 or so....looks like we may have trouble with rolling shutter at higher framerates..not sure why but I can see it playing 48fps at 24fps..I will do a better test outside soon

<<<-- Originally posted by Steve Nordhauser :Wayne: USB 2.0. To get high data rates, you eat a fair amount of CPU time. Also, transfer rates are highly dependent on the host controller. Intel ICH4 and 5 south bridges are 2-3x faster than external controllers. The typical USB interface chip has small FIFOs making real-time tough at high rates when you don't want to drop frames. We don't compress in the camera because either you want lossless, which only gets 2:1 or lossy and then you need to be able to select a lot of variables. CPU compression and raw recording are more cost effective. -->>>

I thought that might be the case, I thought I heard about them upgrading their specs so that it would off load the cpu ussage to a dedicated controll circuit (much like firewire), but I'm probably mistaken.

I like to say all this stuff with the read out peak speeds (with 1 GB you can average them out to disk) maxing out the interfaces is dissapionting, why don't they use buffer memory on the chip/camera (then you can run the next Micro camera at 216fps (24fps*9) and blank 8 out of 9 frames, that would solve much of the problem.

<<<-- Originally posted by Steve Nordhauser : Rob on BitJazz:2:1 lossless. Very image dependent though. And *Very* noise dependent. Remember that they are talking images after the Bayer de-mosaic step which puts that into the real-time path. I'm thinking the best method is to create a red, blue and green separate buffer and RLE each one. That should be doable at any resolution in real-time and save the Bayer for some real crunching. We need to hear from someone deep into Bayer. I'll try to get to the library and get a copy of that article. -->>>

This is what I was thinking too, the bayer has a pattern, but if you take all the pixels of the same colour you get three seperate gradient monochrome images, that the fax compression routine you mention could probably do a good job on (that was a looseless routine wanst it?).

About that compression performance of 5:1 (was it really 5:1). I think that any routine that reliably gets rid of niose before compression to get higher comrpession is acceptable, and it is prefferable to get rid of it at some stage anyway. RAW yes, but we are going to nuke this niose anyway, and a couple of other things. Am I right Steve, if we preproces the niose, Bayer (split to three mono files), and artifacts, we can archive higher than 2.5:1 average lossless compression?

Thanks

Wayne.

I had that very idea! Once I get a camera in-hand I'm going to try separating the channels out into separate chunks and do zlib compression on them. I also found a real-time very fast compression library that I'm going to try out. Depending on the compression, we might be able to get far higher frame rates with a single drive.
I think that would make the shutter speed too fast and would tend to give unblurred frames. Good for sports, perhaps, or a "Saving Private Ryan" effect, but not for everything.

Rob,
I've found that noise really limits the compression of digitized images. Using LZ compression on 10 bit images only gave me maybe 30% .
A lot of the codecs and compression schemes are a lot trickier when you have 10 or 12 bits of which the last few bits have a significant noise component. It's very important to keep those bits for color correcting later.
-Les

Wayne on compression:
I think it was Obin that was talking about 500MB files in about 100MB of space. True lossless will max out around 2.5:1, no matter what you do. Certainly the less the black level offsets and gain non-linearities, the better the compression because then a smooth color will give smooth values.

Wayne on speeds: Yes, buffering in the camera or grabber would reduce peak speeds to average. Not sure if it is worth the cost.

Wayne on high speed: very fast is epensive - the Micron parts are rated at something like a 60MHz clock, Altasens at 75MHz. With internal A/Ds, you can't run much faster. Really fast parts like the Micron 1.3Mpix with global shutter have more taps out of the array and run them in parallel - that is a 10 tap.

Jason on rates: We have a programmable clock generator that works off of a base frequency. If we can't get to the exact number, we can change the base frequency. Using 23.976 as the target frequency, we can hit 23.977 with a 45.5ppm error. For Obin and Rob, that is a value of 0x35BD8F to the clock generator.

Well, that might still give me enough breathing room to get 30-40 fps on a single hard drive. Or prevent hiccups when Windows has to "do something" during capture.
Interesting. Does anyone know how much error we can tolerate? Is there some tolerance specified in the NTSC and/or ATSC standards?

If we can't get close enough, I guess we'd just have to adjust the speed audio to match the video, like the "old" days of shooting silent film and wild sound. That's OK with me, doing indie filmmaking, but I'm not sure it's going to be OK with everyone...

rolling shutter test
 

A good test for the rolling shutter artifact is panning across some vertical objects, like some buildings or a picket fence.
The image will look 'trapezoidal', as if for each scan line the image is offset by a pixel or so.
Most consumer still digi cams *do* have a shutter.
I have an el-cheapo CMOS one that has a 2MP sensor, and it has horrible rolling shutter problems, because it has no shutter. I took it apart, and I think it has either a Zoran or Micron sensor in there. Too bad it Jpegs it all, I can't see the image quality.

You may not see problems on a passing car, as cars these days don't have many straight edges, they look more like a used bar of soap :).

I think it will be essential to allow a longer integration time, and a short readout. Otherwise the image will look like it was made of Jello as you pan around, for lack of better words!

Any luck posting two Bayer images that we can look at for noise content?

-Les

Les,
You are sure you were seeing rolling shutter problems and not interlacing? Interlaced images have their own problems with panning - the odd and even fields are one frame off so you get sawtooth edges - much worse than a RS effect.

frame rates
 

Indie film makers get away with shooting 25 fps in PAL and transfering it to film at 24 with NO CONVERSION at all !

Close enough for them !

Steve,
Most defiantly rolling shutter.
It's a SiPix still camera, a sub $100 still camera.

-Les

<<<-- Originally posted by Steve Nordhauser : Les,
You are sure you were seeing rolling shutter problems and not interlacing? Interlaced images have their own problems with panning - the odd and even fields are one frame off so you get sawtooth edges - much worse than a RS effect. -->>>

Re: frame rates
 

True enough! There is plenty of software available now (I think Audacity will handle it) for adjusting audio without changing the pitch. (And a minor change in the pitch is usually no big deal -- for dialogue anyway.)

Les: the two are not related. Rolling shutter is the sequential reading lines in a frame while the other lines integrate. Interlacing is reading every other line each frame so you traverse the image top to bottom twice as fast. The opposite of interlaced is progressive - no skipped lines for each frame read. You can have interlaced rolling shutter or progressive. All of ours are progressive.