I've been following this thread, the 4:4:4 thread and DVX100
thread with great interest. I really think the current industry
is moving in the wrong direction with HDV (MPEG2) and there
does not yet seem to be support for lots of things.

Most of you will probably know me as one of this boards
"moderators" (or wranglers as we call 'em). What not everybody
might know is that I'm also a professional programmer.

I mainly do pretty large intranet/extranet/website development
on the backend (business logic with connections between
systems and whatnot).

Some might even know me from a little device called the Iomega
Buz which was an analog capture card back in the days that
really didn't got off the ground as it could've been.

I've been dabbling with video (especially computer related)
for 10 years or so now and have programming experience with
a lot of languages including Assembly / C(++). I also have a
thorough understanding about low-level PC workings, protocols,
communications etc. etc.

Since Obin is desperetly looking for some programming assistance
I might be of some help. I do need to say that I only have real
experience with the PC and Windows / DOS / low-level and
not with things like Mac / Linux for example.

I'm willing to donate time to this project since it is of much interest
to myself and the community as a whole. The only problem is
that I do not have the money to but such a system myself just
yet.

What is the cost indication for the 1300 chip? Do you really need
that $500 box to connect the camera or is that just to make it
easy to get started?

<<<-- Originally posted by Rob Lohman :
I'm willing to donate time to this project since it is of much interest
to myself and the community as a whole. The only problem is
that I do not have the money to but such a system myself just
yet.
-->>>

Rob, I'm pretty much in the same boat. I don't have a lot of money, but I am interested in building one of these cameras in the near future. I am also a professional developer and have been thinking about developing software for this project.

I'm assuming we're talking about free/open-source sofware, so I've started to do a little digging to find GPL'd software that we can adapt for this purpose (The Gimp, CinePaint, transcode, Jahshaka, etc.).

I'm probably getting ahead of myself here, but here's a few of the first steps I was thinking ...

1 - Read raw files from SI-1300 camera
2 - Apply Bayer filtering
3 - Write files to OpenEXR format (preserving high bit depth)

The OpenEXR files can then be opened in CinePaint. Once we can do that, we'd have something working and could continue development to ...

1 - Support other file formats
2 - Perform color and gamma correction
3 - Support various lossless and lossy codecs and formats (QuickTime, AVI, Matroska, image sequence, etc.)

At some point, perhaps we should set up a SourceForge project for this...

Just FYI, I've added a page on my wiki to list possible software we can use:
http://obscuracam.com/wiki/wiki/run.php?iRequest=wiki/ViewPage&iPage=FOSS

One thing to watch - the Bayer filtering is a 3x data expansion with no new information added. That is why (aside from the real-time processing concerns) that most recording software records in RAW format. Also, not all Bayer algorithms are equal, so you are frequently better off doing it slowly as a post process.

I was also told (don't know for sure) that recording in AVI format is the only easy way to keep sound synced to video. That may not be a problem with editing software - I don't know.

Someone asked about lossless compression. Expect 1.5 to 2.3x compression for a non-noisy image for truely lossless. And never compress a raw color image - the Bayer will kill you. Point at a green background and you get a perfect checkerboard - completely uncompressable - most algorithms like RLE will expand the data (two bytes used to describe each byte - this color for this long).

If you want to go to YUV space on the fly, then you will have to do the Bayer on the fly also.

guys from what I can see sofar we need a VERY basic capture program that is easy to use unlike the camera link programs like streampix and norpix stuff...this needs to look and act as much as it can like a *normal* video capture app and we also need a way to view the live stream as it's captured on a TV or an LCD that can run by cable or wireless to the camera ..what would really be nice is if we could somehow take the cameralink signal and feed it to a harddisk AFTER we setup the camera settings via computer....

I agree with obin about the easy to use. I for one am much more an artist than a technician. The more "user friendly, one shot" type deal it is, the more condusive it will be on the set. And the more universal the finished captured footage is, the easier people can apply it to different platforms. Keep in mind most people using this stuff will be technical laymen in your eyes. This sounds awesome guys. Keep it up.

Obin & Laurence -- I absolutely agree with both of you. Problem is, without a camera & card, I'm not sure I can develop that software.

As a first step, I thought it would be helpful to be able to successfully open & process a raw file. Then I might have enough confidence to buy the camera and continue development.

Obin, what comes with the capture card? For example, does it come with

1 - an SDK (Software Development Kit)
2 - documentation of the file format(s)
3 - sample files

Those would be helpful to get started.

Ask this of Steve Rob because I am not sure I *think* I heard somthing about a SDK. I will poke around and find out!! I may even work some type of deal like send you my camera for a couple weeks if you really need it for code writing...we can talk for sure about this as things progress . It sure would be great if you could find a way to cut the PC out of the loop once the camera was setup for capture...what about the device that Steve sells that takes cameralink and feeds it down a gigabit wire to a gigabit card on the pc? can this somehow be fed to a disk instead of pc? dunno just an idea....

<<<-- Originally posted by Obin Olson : It sure would be great if you could find a way to cut the PC out of the loop ... what about the device ...that takes cameralink and feeds it down a gigabit -->>>

I've had similar ideas, Obin, and I'm not exactly sure which way to go yet. I think it makes sense to go with CameraLink for now, since it supports a higher bandwidth than Gigabit Ethernet. We'd be set up for higher-resolution chips later on.

My current idea is to build the camera unit into a box with a Mini-ITX motherboard, CameraLink card and a RAID 0 2-hard-drive array. With appropriate software on-board, you'd be able to capture with a (pretty much:-) portable unit. Offline, you'd connect to the camera box via Ethernet & FTP and download the raw files; post-processing would take place on your PC later.

Either way, you need the software on your PC to take the raw files and process them, so that was where I was going to start.

I have some details here:
http://www.obscuracam.com/wiki/wiki/run.php?iRequest=wiki/ViewPage&iPage=RobScottDesignApproach2

(I'd love to try out your camera, Obin, but I might end up buying my own before too long. We'll see!)

Steve -- does this capture card come with an SDK? Can you send me some of the documentation? Thanks!

Rob,
There is an SDK for the capture card. You can get Linux or Windoze support. The cost is $495 but there are no runtime fees so if someone developed a recording application, there would be no cost involved in sharing/selling it. It would be tied to the frame grabber somewhat. If anyone undertakes this and is offering the software free, I will give them aggressive pricing on the SDK and a discount on the camera.

There are two places software is needed - first, capture to disk in RAW format with display preview and basic camera controls (gain/digital exposure). The commercial options I know of are around $1500. CineForm may provide a lower cost option.

Second is the pre-post processing, if you follow that nasty phrase. Moving the RAW images through the basic pipeline - Bayer, YUV, any color balance, etc. to some generic format that can be used by the standard post processing tools.

I think Rob's computer would be perfect for the SI-1300 capture. Find a motherboard using the chipsets with integrated RAID - no bus traffic. Use cheap big drives.

<<<-- Originally posted by Steve Nordhauser :
Rob, There is an SDK for the capture card. You can get Linux or Windoze support. The cost is $495 but there are no runtime fees ... -->>>

That's exactly what I'm interested in!

Another question -- Do you have any idea if there are any similar boards in the Mini-PCI form factor?

<<<-- Find a motherboard using the chipsets with integrated RAID - no bus traffic. Use cheap big drives. -->>>

Exactly -- Mini ITX motherboards are affordable and many of them have integrated RAID and Gigabit Ethernet.

<<<-- capture to disk in RAW format with display preview and basic camera controls (gain/digital exposure) -->>>

Right, that software would be inside the box with a monitor output.

<<<-- Bayer, YUV, any color balance, etc. to some generic format -->>>

Yup, the conversion software would run on the user's PC or Mac after the raw images were downloaded from the camera box.

Why do we want to convert to YUV from RGB??

That seems like a big step down IMHO.

If possible, it would be great to keep the option for full-bit-depth 4:4:4 RGB files.

<<<-- it would be great to keep the option for full-bit-depth 4:4:4 RGB files -->>>

Absolutely, full 4:4:4 RGB (post-Bayer) would be available for output. (The OpenEXR format, for example, supports either RGB or YUV.)

In some cases you might need some processing that you can only do in the YUV domain. Some types of color correction, for example.

Also, some lossless (and near-lossless) codecs work only in YUV -- HuffYUV, for example, and Cinelerra's 10-bit uncompresed codec.

(edit - BTW, YUV isn't necessarily a step down -- it can still remain 4:4:4 and lossless. You don't lose any information other than a tiny bit because of the mathematical conversion involved.)

sounding VERY good. I did not know that ITX boards had pci or pci-x slots..ROB I jsut spoke with the cameralink card company and they will have a 64bit card in a few weeks forsale..that will allow a MUCH higher datarate = higher framerate and or higher bit depth all = good things ;) um what aobut this 10bit stuff? if I save as 10bit like the camera outputs how do you use that? I think that file codecs are 8bit 12bit and 16bit right? or?

I can't find any ITX boards with sata but lots of mini-atx with raid sata

http://www.directron.com/ideq200vb.html

<<<-- Originally posted by Obin Olson : I did not know that ITX boards had pci or pci-x slots -->>>

Yes, all the Mini-ITX boards I've seen have one PCI slot. (Mini-ITX is 170mm x 170mm)

<<<-- they will have a 64bit card in a few weeks forsale..that will allow a MUCH higher datarate = higher framerate and or higher bit depth all = good things ;) -->>>

Yes, definitely something to keep an eye on, but IIRC, we don't need anything beyond 32-bit for this particular camera.

<<<-- what aobut this 10bit stuff? if I save as 10bit like the camera outputs how do you use that? I think that file codecs are 8bit 12bit and 16bit right? or? -->>>

You're right, most codecs are 8-bit. (HuffYUV, for example, is 8-bit 4:2:2)

Most of the uncompressed codecs I've seen are 10-bit. For example, Apple's QuickTime has an uncompressed 4:4:4 10-bit codec. I'm not sure about AVI codecs -- I haven't seen anything other than 8-bit so far.

What file format will you be needing to use?

We need to keep the Rob's apart in this thread, heh.

Steve: I'm very interested (and the other Rob seems too) in such
an SDK and camera option. I'm all for open software on this since
there will be enough hurdles to take after we complete this.
Perhaps we could both work on the project together Rob?

A mini PC of some sort would be most ideal in my mind as well.
It should be more easy to work with than a chip which needs
programming and if we look for the right one has all the options
we need to hook it up to the rest of the world.

It's basically writing the camera's "firmware". Can you shoot me
an e-mail Steve with some more details?

well the question is if you save as a 16bit tiff then you waist the extra bits right? and make a file that is bigger then needed?

I will need 10bit or the max the camera can output so that in post with software like Combustion we can take all the bits and color grade the footage images are fine I don't have any need at all for avi or "video" files

<<<-- Originally posted by Obin Olson : I can't find any ITX boards with sata but lots of mini-atx with raid sata -->>>

Yeah, I'm having some trouble finding exactly the right board. I'm sure it's out there (or will be soon). This one is pretty close:

http://www.viaembedded.com/product/epia_sp_spec.jsp?motherboardId=261

... but has only 100 Mbps Ethernet. Painfully slow when downloading such huge files.

<<<-- Originally posted by Rob Lohman : We need to keep the Rob's apart in this thread, heh. -->>>

Too true! :-)

<<<-- Perhaps we could both work on the project together Rob? -->>>

Sure, I'd love to! Assuming, of course, that we can agree on the goals and detailed design. I suspect we're on the same page.

<<<--- A mini PC of some sort would be most ideal in my mind as well. ... It's basically writing the camera's "firmware". -->>>

Exactly. I looked into embedded chips and so forth, but that seemed a little intimidating to start out with. On the other hand, I'd like to write the software in a modular enough fashion that someone could adapt it to a fully custom hardware later on.

<<<-- Originally posted by Obin Olson : well the question is if you save as a 16bit tiff then you waist the extra bits right? and make a file that is bigger then needed? -->>>

That's true, assuming there is no compression (such as RLE). I'm not very familiar (yet) with what you can do with a 16-bit TIFF file. Assuming it can be compressed, the extra bits (containing lots of zeroes) will disappear.

<<<-- I will need 10bit or the max the camera can output -->>>

Absolutely. I think it's extremely important to find as many formats as possible to keep all the bits intact as far into the post-processing chain as we can. Ideally we won't "truncate" to 8 bits until we're doing the final encoding.

Can I assume that some of the software you use -- such as Combustion -- supports 16-bit TIFF files? I know CinePaint supports 32-bit TIFF, so I may take a look at its source code to see how it works.

Hi everyone
obin, thiis is a link to the agus 35 with the 1500 grit .
http://www.dvinfo.net/media/mellor/


this might be fine enough grain for our high def cameras

this is a link to the ground glass
http://www.optosigma.com/miva/merchant.mv?Screen=PROD&Store_Code=OS&Product_Code=pg211&Category_Code=Filters+%26+Apertures


the part number is 099-0160

combustion does support 16-bit TIFF. It also can work in a 32-bit-per-channel color space.

Rob Scott, that board looks great! it has SATA AND a pci slot..all you need...is that CPU fast enough? can you do a sata raid off 2 standard sata connections? why the need for sata anyway..I have heard that sata as it is NOW is slower then the best IDE drives by a good %...true?

7200RPM SATA is *supposed* to be able to do 50MB/sec continously. Theoretically, 1280x720x30fps 8 bit is 28MB/sec avg, about 35MB/sec peak.

In theory there is no difference between theory and reality. In reality, there is a difference.

The biggest is that drives slow down as you move from the outer tracks (outside circumference of the platter) to the inner tracks. Smaller circumference for the same rotational speed equals less data in the same time. Which way do you think the drive manufacturers spec their drives - slowest or fastest continuous spec?

If the RAID controller is built into the chip set, you will pay a $30 premium or so. Two drives will cost more but give you twice the recording time - not a real loss - use smaller drives if you need to save money.

I guess what I'm saying is that if the 2 drive RAID doesn't cost much more, it is a better option.

Steve, I got images captured from Streampix (learned how to do it) now the only problem is the color red is green and greens are red....can't seem to figure it out...bayer processing does nothing to fix it ..ideas steve?

<<<-- Originally posted by Steve Nordhauser : 7200RPM SATA is *supposed* to be able to do 50MB/sec continously. Theoretically, 1280x720x30fps 8 bit is 28MB/sec avg, about 35MB/sec peak. a better option. -->>>


I am a bit lost here: this HD camera model is supposed to generate files that will later, in post will be converted to film via a film recorder and 24 frames/second is needed. By the way is there an option for the SI cameras to work or have a factory preset at 24fps?
Are we looking only at HDTV? Isn't that a 1080p format?


In stills photography the RAW format is the only acceptable capture for professional results. There are quite a few RAW convertes out there. The one I like is AdobeCameraRaw that works as a PlugIn in Photoshop. I don't see why not it can be ported to AfterEffects (same manufacturer and sort of similar architecture). For compositing, color correction environement, 16bit RGB files are a must. The output renders can be 8 bit.

As for capture software, a simple one is here:
http://www.bensoftware.com/btvpro.html but unfortunately is written for Mac (9 @ OSX , though OSX is a variant of Unix).

The Viper camera files are also recorded in a RAW variant. There is a converter capable to open them at www.xnview.com
If anybody is interested, I have some sample RAW captured frames from the Viper that are free to be assesed, but they are 7.9Mb each!!!!

Valeriu,
Sorry, that is me generating some confusion because I don't know the industry. Our cameras have a programmable clock generator - you can set the frame rate. I'm never quite sure when people will want 24 vs 30fps since I think the broadcast people all want 30....in the US anyway. PAL is a different rate. Then some people want a camera that can do twice the frame rate - for special effects, to drop every other frame to minimize the rolling shutter artifacts or to meet one of the new standards.

I just know frame sizes, frame rates and clock frequency.

Thank you Steve,
Yes, the PAL standard requires 25 frames, but film projection is set to 24 fps worldwide. It will be a a very daunting task to convert 30pfs to 24 or 25 especially when you deal with such a huge amount of data for a feature length project. Wouldn't be simpler to have the 25, 24, 29.7, 30 fps inbuilt or easily programable. All the HD cameras we are trying to emulate or surpass are capable of doing this...
...And I have a vested interest: I work in PAL and film environement.
Also, 25 fps can be used in projection as long as the soundtrack is altered for the 24fps lengths and the pitch adjusted. Many "films" shot with Canon XL1or other PAL cameras are done this way. There is a demand of PAL XL1 cameras among independent US film makers especially for this reason.

Steve can the 1300rgb be locked at 24fps or is that going go up and down as you shoot?
FILM 24fps
BROADCAST TV 30FPS and 60fields/sec
Europe 25fps PAL broadcast TV
effects shots 1-120fps
get rid of rolling shutter 60fps and drop one in two frames for broadcast TV and 48fps drop one in two frames for film production

HTH

I understand what a rolling shutter is, but what are the electronic shutters on the Sony F900, etc. like? Are those rolling, or are they single shot? Will rolling shutter look funky on the movie screen?

Also doesn't the SI1300, or at least the Micron chipp it's based off of have the option for a single-frame mode instead of rolling shutter?

Hi Guys, playing catchup, some valuable information below for a some of you.

Robs' it is good to see you here on this. (and I was just getting used to having two Steves ;)

You may notice my spelling improving a bit, as I got rid of the wireless keyboards (virtually smashed the thing) and got another usb model. Interesting thing is that I think the regional HD test broadcasts where what was interfering with it, the same time every day in particular.

Now some important programming stuff.

<<<-- Originally posted by Obin Olson : guys from what I can see sofar we need a VERY basic capture program that is easy to use unlike the camera link programs like streampix and norpix stuff...this needs to look and act as much as it can like a *normal* video capture app and we also need a way to view the live stream as it's captured on a TV or an LCD that can run by cable or wireless to the camera ..what would really be nice is if we could somehow take the cameralink signal and feed it to a harddisk AFTER we setup the camera settings via computer.... -->>>

There might be the possibility that you could control the capture program from a seperate control program written in Visual C or something. You would have to check if you can pass commands to the capture program. This saves you from writing a capture program and allows you to use the best one you want.

Yes I agree that keeping the data in Bayer (for a Bayer camera) is probably the best until you want to edit, then what do you do? Converting to a true image (and back to Bayer might not be feasable). Look at what the film industry is using, might be best. I don't like it at low HD res, too many compromises, especially when there will be 3 chip cameras cheap. With Bayer you are loosing and keeping it there is good, but with true 4:4:4 3 chip, you have 100% data and can convert it to any format desired with maximun quality.What happens when somebody hacks direct to disc off the head of one of those. People are allready talking of doing this with Single CHip HD10, so we defintely want sensors that beats it (even if they do achieve it the camera is still too restricted).

Before anybody buys anything more, remember that Sumix (if they are going ahead) maybe here within months and there also is Silicon Imaging. So a few people might like to hold on for them, and if we had real data the software could be made the same time. Otherwise if they deliver the goods you won't have the money to buy it. Still you could develope remotely, and the guy with the caera tests it. Go look at the site ofd the Russian fellow, you will find interesting stuff there and probably reference to existing Open source software, even if it is in Linux it could be converted to Windows.

Compression software must be slack if it can't compress a true simple checkerboard pattern (which would be a handful of bytes).

Rob: about the ITX boards, things are going to continue to imporove over time. Email the ITX section of VIA, they are very helpful, describe what we are doing and ask them about what features they have coming out on there mini-itx, and nan-itx boards int he future. The ITX section is spread over a few sites so I don't know who totalk to anymore, I was goign to pretty much wait until closer to the release date and look then myself. Ther make a number of reference boards for different products, while I don't know if they would make a cameralink reference baord for us (and I guess many camera vendors would also like to sell), one of the future reference designs might suit. Actually the processor uses something like 7watts per GHZ, thats nearly ten 10GHZ worth for around the same power ussage of some of the AMD processors. This makes them excellent chioce for thin blade servers, so maybe they might have a future 4+ processors MB up their sleves that could be used. Also remeber that capture should need a lot less processor than simultaneouse capture and compress. I think Intel or Micrososft also has a Mini-Itx like board coming out. Also a number of manufacturers do small boards for small cube cases (SIS is one).

As far as I know ITX has PCI in the mini-itx (but also look for AGP), and mini-pci in nano-itx (but look around for full PCI). I think it is also possible to get a mini-pci to PCI adapter. I have also seen PCI/AGP benders, that allow the cards to sit parrallel to the MB (they are a special testing tool around $30US I thiunk).

I've seen these boards quote virtual Raid (also have heard of software raid). I have asked here what that was before but got no reply, does this board say that?

Does anybody know of a board with dual Gigabit ethernet, that would be good (if there was a daul GBE hookup to a camera).

By the way, as the bayer on the 1300 camerra only requires 24mbs why not just go USB.

Data Packing should be able to be done on the data being outputed by the capture software (in parrallel).

Robs, their are small book sized minpc's out there also (with big processors). Look at the partner, and design win pages of the VIA ITX pages for links )hard to find, I think in the smnall blue links on the right hand side, or go through the drop doen list). While you maybe able to hack these for extra drives, some manufacturers offer the MB seperately. Have a look in the links I posted previously, I'm sure the Cappocino PC maker is there.

Valeriu:

The Viper is a bayer pattern camera isn't it? Maybe you could give us some advise on how it processes it's images.

<<<-- Originally posted by Wayne Morellini :
The Viper is a bayer pattern camera isn't it? Maybe you could give us some advise on how it processes it's images. -->>>

Wayne,
I posted an URL of a site than has a image converter that will open the Viper frames into an RGB TIFF. The original camera frames that I have are 7.9MB each. If someone volunteers to host some samples, let me know.

Here is the link again for the software that can open the VIPER frames: http://www.xnview.com
Both VIPER and DALSA are using bayer pattern chips. I would love to see a Foveon based chip that can sustain high frame rates and good sensitivity. They are probably the next gen chip, but for now, we have use what we've got.

Valeriu & Wayne

I agree with keeping the signal as high quality as possible. I think 1080 is much more important for those of us looking to do theatrical realeases. 720 is pushing it.

Also, I'm curious, there was mention of "doing the final encoding at 8 bit". Maybe I'm not thinking straight here (I'm assuming you mean final encoding of footage into a format one can edit with . . . yes, I'm a programming layman) but I think if it's possible it should stay in 10 bit. 8 bit, just like 720, is pushing it for theatrical release. Both 720 and 8 bit are MINIMUM most professionals consider for going to the screen, not hardly preferable, and would make quite a sacrafice when considering a finished product.

Another thing is that you were talking capture rates of 50 Mbps? I heard rumors Canon is coming out with a 50 Mbps HDV camera by the end of the year under 10 grand. If that's true, we all surely would have wasted some serious cash, for what the canon would deliver, complete with lens, would probably be so much more worth the convenience of an extremely cumbersome, and not nearly as feature-filled system. Again 50 Mbps is not theater screen quality really. Might get away with it, but . . . you're pushing it.

We must remember that if we want MEDIUM quality (somewhere between TV and theater movies), that's not too far away for a price similar to what we're talking about drumming up here. If we're going to all this trouble, let's do it to compete with the BIG BOYS, not just to go to the next category closer. Otherwise, somewhere between 2 and 5 years from now we'll realize we're back in the same place . . . wondering why we AREN'T making hollywood level films.

Just IMHO.

Okay: I'd like to make a couple of suggestions:

1) BB code FAQ (http://www.dvinfo.net/conf/misc.php?s=&action=bbcode). Please everyone read it. I've edited almost all the posts here with hyperlinks to make them clickable. Please take the time to read that short page so everybody can make their own links working. Thanks!

2) I think it is time to slowdown a bit. I think all the enthusiasm is great and all the information that everybody is digging up, but I'm personally getting a bit lost and swamped and I feel others are as well.

Let me elaborate on point 2. The only person currently having the
chip on this thread is Obin. Rob S. and myself are currently looking
into seeing if we can get hold of it as well.

After we or anybody has the chip we still need to hook it up and
get it running which Obin seems to have in the basic form. Let's
wait to here from Obin and see some pictures first.

Then we need to start working on getting frames ourselves
(to learn how the device is working). After (or perhaps in the
same time) it is time to start working on the design of software
and hardware etc.

Personally I'm not going to invest time and money into things like
mini pc's or mini-PCI/ATX boards etc. just now. Let's get a
prototype working correctly on our normal PC's first. Then it is
time to work on the whole camera package.

My guess would be that we are months away to get a working
prototype with our own software and controls and file output
working and in a format to allow it to be editted.

Then it is time for the complete package and whole different
range of mainboards / computers / harddisks / connectors etc.
might be out.

Ofcourse we need to keep an eye out and do our research in
time. But I have the feeling we are now all running around looking
for information and dumping it all in this thread. It might even be
wise to setup multiple threads and I'll have some chat with this
with our great forum owner Chris.

I say it's time to get working a bit from structured with lists and
stuff to do?

What do you all think?

p.s. I will be out on sunday and monday doing things with the
family so I won't be able to attend much. Please keep it as
structured as possible in the meantime!

<<<-- Originally posted by Laurence Maher :
Also, I'm curious, there was mention of "doing the final encoding at 8 bit".
-->>>

I suspect that was referring to final delivery format such as AVI/Divx, QuickTime or MPEG-2.

<<<-- Another thing is that you were talking capture rates of 50 Mbps? I heard rumors Canon is coming out with a 50 Mbps HDV camera -->>>

Actually, we're talking about 50 MB/sec ... that is, 50 megaBYTES per second, which is 8x more than 50 megaBITS per second.

There is no question that a Canon (or other brand) camcorder will be far more convenient than the system we're talkin about here, but we're talking about 4:4:4 10-bit uncompressed data, and I don't see any manufacturer doing that for under $10K any time soon. They would cannibalize their higher-priced market.

<<<-- Originally posted by Rob Lohman :
1 BB code ...-->>>

Will do.

<<<-- My guess would be that we are months away to get a working
prototype with our own software and controls and file output
working and in a format to allow it to be editted. -->>>

Absolutely true. This is definitely a long-term project and we need to pace ourselves.

Thanks!

Thank you Rob! the thing is this even if Canon or whoever comes out with a lowcost HD camera we can still apply what we learn to a 2, 3, 6, even 12 megapixel camera that will blow what the big 3 will put out away in terms of raw image quality..I seen no need to worry at al,l I for one started this whole thing because what I am about to get from a a 2-3,000$ upfront cost is good enough to work with in many ways..it's great for color work in post it's great for greenscreen shots it's great for tracking animation and when all is said and done after you compress it's size to fit a standard tv screen it looks much much more like film then cheap video AND you can get the high-framerate for REAL slomotion(this being the biggest reason our production company wanted to build this thing anyway) so is it worth it? IMOH yes. will they come marching to our door with all the features above for $4,000 or even $10,000 ?? no.


Update:

Late last night I got the capture software capturing at 24fps. Something is wrong with the colors, reds are green and everything looks the wrong hue...I will get back on it monday and see if I can figure it out...I think it's a bayer issue, looks like the streampix software does not deal with the 1300 camera's bayer filter in the right way.I ordered a 2 week trial dongle for the x-cap standard edtion so if streampix never get's working i can test the camera with x-cap...both software packages cost over $1,500...this is one reason we need that simple software made...this stuff has tons of features that we have no use for in the production markets...all I want is exposure, framerate, basic white balance, gama, ROI, and gain...thats really all we need and a bigger cmos chip atleast 2/3inch

Cool Rob and Olsen,

Thanks for clearing everything up. Makes all sorts of sense, (especially now I know you're talking bytes, not bits, lololol). Are delivery formats usually not 10 bits? (Don't know much about delivery specs).

here is a good display device for the itx system!



I bet that would be just nice!
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=3698&item=4134438908&rd=1

<<<-- Originally posted by Laurence Maher : Valeriu & Wayne

I agree with keeping the signal as high quality as possible. I think 1080 is much more important for those of us looking to do theatrical realeases. 720 is pushing it.

give me 720p 4:4:4 anyday rain or shine over 1080i or p that is compressed like ALL of the cameras on the market are today - yes even the 100,000 dollar sony and panasonic


if you would like to spend more then 8 grand on a system you can have that NOW no question about it - go for it! i don't make feature films I make 30sec commercials for broadcast and have no need for more resolution then 720p. I know that some have shot with the Panasonic varicam that is 720p for blowup to 35mm with good success and great results - some have even shot with the little dvx100 and all of it's compression and still blown up to 35mm... it's your project not the camera that makes or breaks the show

Steve can you build a SDI HD or a s-vhs out for broadcast monitor preview? or better yet a digital interface like you have on a computer graphics card so we can jsut pipe a true hd signal to any old cheapo CRT computer display? that would be the best and cheapest for the market to use....feedback?

I've looked into HD-SDI at the urging of this group. It looks expensive and unnecessarily complex. So, for camera out we will probably stay with camera link and gigE. I will be actively assisting in getting CL integrated into a usable form for filmmakers.

Since our cameras must run with a computer, it would make sense to me to attach your monitor there - there is a wealth of cheap cards with s-video ouput. I poked at that Lilliput monitor link - looks nice. Too bad it isn't 1280, but very interesting. If Rob and Rob write some software, they might be able to do some tayloring of the controls so that the buttons are coarse enough to use the touchscreen for changing exposure, stop and start recording, etc.

Rob and Rob need to program the the capture software so that it's using video overlay to display the live camera image . That way we can use a dual-head card and pipe 2nd head on the card out to a CRT/lcd that supports 1280x720 OR a converter box that will take the signal and convert it into a true HDTV analog signal for a broadcast HD monitor.

With video overlay you can have your graphics card dislpay the overlay fullscreen on the 2nd monitor out from the card - i think maybe this is a function of DirectX??

someone must know this, can we take a laptop screen that is 1280x1024 and make a homemade connector to plug it into a D-sub connection on a standard graphics card port? if so we can have a 12in and a 15in display...much better then lugging around a big 17in lcd for the itx system

i can't find ANY standard off-the-shelf screens with 1280 resolution smaller then 17in lcd

http://www.xenarc.com/product/700ts.html

This one will go up to 1600x1200, so you can definitely get 1280 resolution out of it, and it's a touch-screen to boot.

Physical Resolution: 800 (H) x 480 (V)

<<<-- Originally posted by Jason Rodriguez : http://www.xenarc.com/product/700ts.html

This one will go up to 1600x1200, so you can definitely get 1280 resolution out of it, and it's a touch-screen to boot. -->>>

nope I don't think that wil cut it