Rob L - bin/subsample mode on Altasens:
You are correct - the Altasens is the first sensor that I have seen that can do that combo mode - binning and subsampling together to downsize 1920x1080 (native sensor size) to 1280x720 using the full sensor. The 3300 only supports subsample and ROI resizing.

Altasens:
A *preliminary* spec sheet is here:
http://www.siliconimaging.com/SI1920/SI1920%20Spec.PDF
Still due around the end of October.

Obin:
Sorry we don't have a hefty price tag on the SI-1920HD, just a low price. If you want, I'll create a hefty price tag for you.
Now if you want to know the low price, it is $3995, single piece.

Steve,

are you incorporating all those features in the brochure? If so, how will we access them? Will XCAP be able to access them, or will we have to send out serial commands and edit registers?

Jason:
Life is never easy. We will give you access to all those features. You will be able to get most of them from the XCAP GUI (not what you want) but if you use the SDK, you need to send strings, just like the other cameras. Depending how many people want to use the SDK for independent projects, I might put a camera discount bounty on the developer who releases an open source wrapper that lets people use higher level calls.

Steve do you have a web site so we can check out your camera or when is it do to hit the market?

<<<-- Originally posted by Steve Nordhauser : independent projects, I might put a camera discount bounty on the developer who releases an open source wrapper that lets people use higher level calls. -->>>

I thought that was the original objective for Rob's software? To just use camera specification files to let the software know what features are available and where they go for a new camera.

Wayne:
It is not clear what on Rob's software will be open source and what is not, but I think he said the camera specific stuff may not be. It is up to him how that works.

Gary:
My sig file has my company web address with all the released information. Every once in awhile I toss out test files or preliminary information on DVInfo. I just posted the SI-1920HD prelim spec a few posts ago. Delivery is expected around the end of October. The other cameras - SI-1300, 3300 are on the web site and available now.

Well I'm not sure if Rob's software is going to give us access to all those goodies listed in the brochure. Of course I know that Rob is working very hard, and there are only so many features that are really necessary for this project to work-if he tried to incorporate every feature this chip has, he might be programming for th next year before we get a good beta release, and I wouldn't want him slaving away for more obscure features. What I think would be interesting is some access to these calls so that if you did want to really tweak your camera you could.

BTW, why is XCAP so bad?? Of course it's not great, and there are better things out there, but it doesn't seem as though it's horrible, like totally unusable. Oh well, I haven't used it, so I can't really comment, now can I :)

That was one of the original ideas, yes. However, I'm not sure how practical it is -- XCAP (for example) tries to do this, and ends up being so flexible that it's hard to use. To be readily used for filmmaking, I think the ObscuraCam software needs to know a lot about the individual cameras that it supports, which would be very difficult to reduce to capability profiles. That's not to say it would be out of the question, but I don't see it happening any time soon.

-- EDIT --
That's correct, Steve. My intention right now is to keep the "firmware" application closed-source.
Yeah, I'm going to have to pick and choose based on what I think is best for filmmaking. 1000 fps with a tiny window? Probably not. 120fps @ 720p? Almost certainly. Interlaced? Not sure.

<<<-- Originally posted by Steve Nordhauser : Wayne:
It is not clear what on Rob's software will be open source and what is not, but I think he said the camera specific stuff may not be. It is up to him how that works.
-->>>

Yes, your right, sorry my fault.

Rob, I agree with Jason, common (+good) features version first. But a profile file system in future, would make it easier for camera makers (or advanced users) to "register" their cameras for use with your sofware. I scribbled up an idea for an extensible interface and menue system the other week, that sorted out all these problems. If you like I can share it with you for the next version (though somebody is also talking to me about doing something, so maybe I'll have to check with them first).

jason or anyone who would know..why did a variCam 35mm transfer look really really dark today when I ran it at the local cinema? would it be the projector ? or the print transfer CC is wrong? all the darks are really really DARK

There's a lot of things that could have gone wrong. Typically most transfer facilities should have some calibrated monitor systems to give you an idea of what you'll get on film.

When you say the darks are really dark, are you talking about the blacks being crushed? Or just the gamma of the picture in general is dark? Crushed blacks could have come from you trying to make the picture look contrasty on the monitor system, since monitors don't respond the same way as print film, especially Vision Premiere, which tends to have very rich blacks (to offset the very flat look of color negative). So something that looks nice with the blacks on your monitor will look crushed on the screen.

BTW, other than crushed blacks, how did everything else look? Highlight handling, colors, compression, etc.?

compression is good..i don't see it colors are ok...one shot that was lit with nothing but clouds in the sky looked really great!

the darks are BLACK not dark like on 2 TV sets one HD one non and on the monitor in the field..or could it be the projector bulb?


I gota say that it felt like a cheap contrast was on the footage...if I think in terms of what I know it felt like a bad and really heavy contrast...the lab did a "CC" for all the footage and a "CC LOOK" for 3 shots

I will try atleast one more projector..they have a good one at ScreenGems Studio here and also JDC has one


720P is enough resolution but 1080p will be better ;)

For everybody that wants to know more about sensor specs I have discovered this page:

http://www.ccd.com/ccdu.html

Silicon Imaging also has some basic tutorial pages on their site.

I work with film transfers every day of my life ( I do them :) or to be clearer I'm the guy who could make your footage look good or dark...) and If I'm allowed to tell anything, I would say it is very normal to see your video footage darker on 35 mm...
Around the internet is a common saying of giving cameras (video) darker blacks that what it is supposed for TV standards , and that's not right..
The standard black for NTSC is 7.5 IRE and for PAL it is 16 IRE, ( I suggest always use 16) and they work very well..
May be some of that things got messed up somewhere in the chain, don't know really...
Anyway, film material always looks darker (or with more contrast) than the video master...
Remember that your video master goes thru a standard gamma correction on the film recorder to be transfered to film, and if the video original isn't captured within TV Standards limits (From 7.5 or 16 to 235 IRE) or corrected within that limits anything can go wrong...
Also remember that anything blue will look darker on film against video most of the times...
Hope this helps..

BTW, did you use a MAC somewhere in your workflow before sending the images to the facility?

no I shot and sent it off..NO editing at all jsut a tape

CCD course:
Please be sure to notice that Wayne's CCD course is just that - about CCDs. Similarly, the information on our web site is mostly about CMOS sensors. There is plenty of overlap but some differences.

<<<-- The standard black for NTSC is 7.5 IRE and for PAL it is 16 IRE, ( I suggest always use 16) and they work very well..
Remember that your video master goes thru a standard gamma correction on the film recorder to be transfered to film, and if the video original isn't captured within TV Standards limits (From 7.5 or 16 to 235 IRE) -->>>


This info is not correct.

The IRE scale is for NTSC only and the legal values goes from 0 to 100 IRE.

All analog American NTSC signals should have additional "setup" which is a blacklevel correction that puts all blacks at 7.5 IRE.

Analog PAL uses Volts instead, and the legal scale goes from 0 to 0.7 V.

Both scales are only relevant in the Analog domain eg. after the DA conversion.

ALL digital video signals both PAL NTSC and HD, has a legal range of 16 to 235 if we assume a 8 bit depth. Levels 0-15 is for subblacks used by old DSK keying, and 236-255 is for additional latitude in the highlights.

In NTSC a level of 7.5 IRE is digitized at 16 and 100 IRE is digitized at 235.

So internally a PAL signal or a ntsc signal with or without setup should have its blacks at 16 and be whiteclipped at 235. when in the digital domain.

as you like :)

I made a big mistake ,though putting IRE after 235 instead of saying 100 IRE.

If you can mention it, who did you send your footage too?

Good places I'd recommend are Technicolor NY, Efilm, I/O Film, Cinesite, and Duart. I'm sure there are more good places, but I've found these to be the most knowledgeable or experienced with tape-to-film transfers.

BTW guys, new info:

With the Altasens chip, you can NOT do 720p AND keep the 2/3" optical format-you must to windowing, reducing the optical format to 1/2". Now I don't think this is a deal-breaker by a long shot, but this is just something I thought you'd all need to know now, and not get surprised with later.

I'm thinking then for my setup I'll use the 2.5" 36GB Seagate Savvio's (10K RPM U320 drives). I'll stripe four of them together on one SCSI channel, and that should give me enough bandwidth for 40fps 1920x1080 at 12bits. Hopefully Rob can incorporate 12-bits linear to 10-bits Log so that we can easily do slo-motion with this drive setup, because then we're only recording 10-bits to the hard-drives, and that'll get me another 8fps up to 48fps before I hit what I think will be the 124MB/s barrier on a U160 interface (that's as fast as I can find a MiniPCI card right now since they are typically 32-bit 33Mhz). I'd like to get 40fps at least though, I think that should be enough slow-motion for 1920x1080. Either that or I'm thinking that 1/2" optical format won't be so bad, but I'd like to stay away from that if I can (plus I'm not interested in the lower resolution of 720p, but I do like how high a speed it will give me, so I'm weighing the choices-but either way, four of these drives striped together should give me plenty of bandwidth).

I also remember an Australian 7 Network tech teaching us about the super white/black values being reserved in Pal because they interfered with certain emergency radio freequencies, and also causing the TV station transmission towers to kick in extra generators and cooling.

Jason-
You can probably solve the slow motion problem by using a fast 64bit frame grabber to save the short sequence to 4 or 8GB of memory and then saving it to disk betrween shots.

Actually, it appears that as long as we support the oddball Bayer pattern, we can keep the 2/3" size.
I'm not an expert of these systems (yet), but if you're using 32-bit/33 MHz PCI, you're going to have a problem with bandwidth. The frame grabber card is going to use a good chunk of your PCI bandwidth, so if you have the hard drives running over PCI as well, you will need to use 64-bit/66 MHz, or a split bus, or both. (Somebody please correct me if I'm wrong. :-)
That's a good idea too. Elsewhere someone suggested doing this in software, so of course you'd need a motherboard that would hold that much RAM, a 64-bit CPU and a 64-bit OS -- but 64-bit Windows is not available yet (again, unless I'm mistaken).

Well I'm not really sure it's mission critical that we keep the 2/3" optical format. Like I said, that's really not a deal-breaker. Also an odd bayer pattern is going to cause some weird artifacting, especially when you have two greens right next to each other and then a red or blue right next to each other and back to green. Now I saw Wayne's post on the technical discussion board, and it does seem like it might work, but I'm worried about new weird artifacting patterns and other associated artifacts. For instance, variable number of gradients needs nine pixels total, or a 3x3 block to work correctly-with the sub-pixel mode we only have 2x2 blocks-so more advanced algorithms are going to get messed up. I think it's just best that we get a really fast drive array in as small a package as we can. Again, we have new 2.5" 10K drives from Seagate (Savvio), and they can sustain around 53MB/s.

Also Rob, the board that I'm using does have a split bus, since it's using 64-bit PCI-X for one PCI slot, and then the other slot is 32-bit MiniPCI. The 36GB models are around $350 right now, so four of those striped together should do a nice job of keeping around 120MB/s the whole way through. And when we want 720p, we simply window down to that format and crank that sucker as far as we can push!

Again, something else to consider is that most video lenses, especially those on DV cameras, don't open that far f-stop wise because of the prism needed for 3-chips (like maybe f2.8). You can get 16mm lenses though that open to f1.3, so the depth of field problem becomes mitigated at that point-that's amost 2 1/3 stops wider than f2.8. The only "problem" you might have is with super wide-angles, but that's about it IMHO.

But again, if I can get this thing up to 120-124MB/s drive-speed wise, then we should get around 40fps at 1920x1080, especially with 10-bit log conversions from 12-bit linear.

BTW, a motherboard that holds 8GB of RAM is HUGE-I'm not going to be carrying that around on my shoulder.

Okay, I looked at lenses some more, and it appears as though you can get primes that are around 5.9-6mm for 16mm, which translates to around 22-25mm when thinking of it in 35mm terms when used with a 1/2" chip format. So no real need to get worried about using 1/2" chips with 720p windowing.

Jason, since you have a split bus, you should be in good shape. I wanted to make sure you didn't have any nasty surprises later on, but I believe you're on top of things.

You're probably right about artifacting with the oddball Bayer pattern. To get a good image, someone would probably have to create a custom algorithm.

One more thought: Those 10K drives sound nice and fast, but with four you're only going to have 144GB - enough for about 1.5 hours at 720p and 45 minutes at 1080p (10 bits, 24 fps).

45 minutes should be plenty for one magazine. That's like one tape. And using USB 2.0, we can offload 144GB fairly quickly, like 50 minutes max (hmm, that does seem like a long time).

BTW Rob, if your software could make a new folder for each capture, like "scene-01-shot-001-take-001" "scene-01-shot-001-take-002", etc., that would speed up the transfer process quicker because we could keep the USB drive hooked up all the time, and just offload the takes we want when there's a break in shooting (without searching through a bunch of file sequences-THAT would be very confusing and take forever).

If the drives were removable, that would be nice. I'm not sure how practical that is though.
Without promising anything :-), I'll keep that in mind. How would you suggest handling setting the scene/shot/take? (In the UI, I mean.)

I liked the way that S-Two did it with their D.MAG digital disk recorder.

At the setup of the new "reel" it would ask you what the reel number was and what the scene number was (if you were continuing from the same reel as before). So in a reel (for us it would be our hard-drives), it would then add a folder for the scene number that you had entered, and then with each stop/start, it would make a folder for the take.

Each time you erased the hard-drives, it would set-up a new "reel" number (if you wanted), or you could keep the reel number from before. Then it would save the files out using the name format of r001_s001_t001_XXXXXXX.dpx. Of course they were using DPX files (we'd be using IHD files), but that seemed to be a very easy way to identify what file was what, and it was embedded nicely inside a reel-scene-take folder system. Wasn't hard to setup at all on the user end, and it helped a lot in keeping track of what when where, even when files got seperated from their respective folders (or when you were importing files into a program, they all didn't have the same number sequence). BTW, the seven digit number sequence was actually timecode. I'm not really sure that's necessary for us though, but seven padded numbers does give us a lot of frames for recording, if one decides to fill up their hard-drives.I think I'm going to up the capacity then using the 73GB hard-drives. That'd be like having "two" magazines if I went with the 36GB HD's. 1.5 hours of 1080/24p is a lot.

I have new scene/take files every time you hit "record" they all stay in the folder you make when you start shooting

Obin,

Do you think it's possible though to have the information for each scene/take in a new folder hierarchy of scene->take? Then you're not scrolling through a million files trying to find the right scene/take number for the files you want to copy over.

That is what a Script Super is for right?

Yes multiple files, or at least an index, for scenes is a good idea. Maybe a slider, thumb wheel (in the case) to skip back through the scenes.

Jason. About the funny bayer pattern, I think the funny pattern comes from combining the skipped pixel with an adjacent pixel into complimentary colour (but I haven't read the 1920 pdf properly yet). So yes all bayer filters would have to be rewritten for it. Altasens should have some softrware filter solution allready (It plagues me as to why the TV industry did not do 540p*960 (or even 810p), which divides into 1080p*1920 evenly compared to 720p, it also would have made the transition to HD much quicker).


<<<-- Originally posted by Jason Rodriguez :
BTW, a motherboard that holds 8GB of RAM is HUGE-I'm not going to be carrying that around on my shoulder. -->>>

Sorry, I didn't realise you were after ENG style. I thought you were after stationary cinema shots that could be done with a big case. Two other suggestions, I think eventually (within a year) we are going to see a smaller version of that Nvidia 8GB capacity board, I mentioned some time back, in a small cube case. There used to be PCI card based ram disks, I imagine there might be soimebody out there with a PCI 64 version that takes upto 32GB in PC memory sticks.

<<<-- Originally posted by Rob Scott :
a 64-bit CPU and a 64-bit OS -- but 64-bit Windows is not available yet (again, unless I'm mistaken). -->>>

As far as I know the 64-bit PCI is independent of the bits of the processors or OS, or where you talking about something else?

Thanks

Wayne.

Wayne: I think Rob S. was talking about 4 - 8 GB of memory which
might need a 64 bit OS? I'm not sure what 32 bit XP supports.

Rob was saying that right now it's hard to address 8GB of RAM unless you're using 64-bit Windows, or Windows 2003 Server, 64-bit Linux, etc. If you try to go with Windows 2003 Server, be prepared to spend as much on the operating system as you will on the computer!

Also 8GB of RAM is very expensive, it's probably much better to just purchase those small SCSI drives I was talking about from Seagate. They run at 10K RPM, that's very fast, and they only use around 5W to seek.

Hello All.

Steve, do you have any more frame grabs from the SI-1920HD that you could share?

Best, Magnus Andersén.

<<<-- Originally posted by Rob Lohman : Wayne: I think Rob S. was talking about 4 - 8 GB of memory which
might need a 64 bit OS? I'm not sure what 32 bit XP supports. -->>>

OK, I understand, yes you should be able to use 8GB, in a round about way, but you will have to check with how XP works to see if it supports this. See, if you can have virtual memory areas of 4GB each then you could have two of them paged into memory (for everybody that is not familiar with this, that means the memory acts as sort of disk cache).

Also with the ramdisk cards (you can use small board and rightangle card extenders to reduce size) they would be addressed as a disk and can have the maxium capacity.

The suggestion for the 8GB, in this case, is so you can shoot slow motion frames as fast, and reliably, as you want, faster than 4 drives. This is a specialist solution, not the normal solution for the rest of us. (personally I would just rent something like the high speed phantom (mentioned on the other thread) for a day on a feature film (nature doco/s you would be better owning your own I think))).

Has anybody thought about using Linux instead of Windows for the camera??
I guess it would eat less resources and be more controllable on every stage.......

Yes Juan, that has been discussed. I believe Obin's programmer
might be doing it under that OS. Rob S. and myself choose
Windows because we are both programmers under that platform
and it we should be able to more easily support things like GigE
since there are no drivers (the specific ones for the camera's!)
for Linux etc.

Basically in the end I personally don't feel Windows will be taking
a lot of resources away from the camera application which is
running with high thread priorities. The most important elements
for now are the bus speed, CPU speed and harddisk(s) speed(s).

Keep in mind that the processing application to turn all the captured
files into some other format and do a de-bayer etc. will be
completely open source and hopefully cross platform so you can
run that on windows / mac / linux in the end.

Yes, I know :)
It was I just thought everybody was developing only for windows,just that.
Thank you..