Thank you for the links Rai. I either have missed your e-mail due
to much moderating work here at DVInfo or it was never received
by me. If it is the former I do appologize for not getting back to you.

I in no way wanted to insult you or say you didn't have what you
claim you have, but this is a webboard, anybody can say anything
you like. I'm just a bit skeptical of claims without any backing,
that's all. I hope you understand.

We all still would like to hear what you used to built your camera.

Close to which part of Holland are you situated? North, middle
or south? Perhaps I can visit and check your camera out sometime.

OK Rob.

I have sent emails to you and not received a reply myself, so I don't send emails and get on with what I can do (which is way too much with the number of other projects log jammed here).

The guy excitedly preanounces he has finsihed working camera and websirte is coming in a few days, that is not too long to ask (even weeks). I can take a guess that he is probably very busy, and the nature of the business (like many businesses that ussually are bigger than individuals) might not allow for much of a preannouncement (very common in the real world). You can veiw his absense as a plus, he's obviously been busy making it instead of bugging us for help months on end. Got to respect that.

Sure any new camera is a threat etc, we could sit here and demand a tell all from all other manufacturers. I haven't yet seen anybody else's capture software posted for demo/sale. How quickly can the software be done depends on the programmers, some are ten times quicker, and I'm sure RobS will tell you that if he had to do it again with all the skills he's learned he would do it much quicker.

Now I've submitted information about cards, cameras, the cameralink homepage that has a database of these, before, and not much attention was paid.

Sorry, but I think it is just too harsh a way to treat someone, especially when somebody intends to drop a golden goose in our laps (and it doesn't matter if it is a small one, I rathered have three gooses in my lap than one). It is a matter of wait and see, and as Rai commited to a few days he should deliver that (a few days is ussually upto 3 days in english), and even if it is delayed not more than a few weeks

Now onto my $200 camera unit investigation, I am at a preliminary stage and there has been a hitch. It does require a professional approach (business and engineering sense), but things have come up since last week and I don't have the time to do it propperly, let alone programming testing and development, and I have to do other stuff. I might have to take an extended technical leave shortly (no more research).. So I might have to throw it open to somebody else volunteering to do it instead in a lightly collaborative effort. It is still a community initative, but also open to a commercial venture. I would not get your hopes up because it is nothing concrete as there is insufficient "public" data, and the company is not interested in our market, so it requires the right approach to get it out of them. I will have to consider what to do over the next week.

I appologize to you as well Wayne if you haven't received a reply,
sorry about that.

It looks like we will not agree on this, and that's fine. I'm not sure
why a new camera would be a threat. I welcome Rai and his new
camera.

I'm wondering why you keep talking about a "business". I have
not seen Rai talking about a business or commercial effort other
than that his new camera will be used to shoot a movie with.

rai orz
 

regarding Rai's help on the mini35 -

Rai has consistently offered highly technical information about the building of the Mini35.

With this, he has also given us detailed drawings on making the mini 35, which is even being used by some, to build the product and come back here to sell it to members .

I am extremely grateful for all Rai's help in building mini35, and look forward to his new camera design.

That's great to hear Richard, thanks!

BTW guys,

Biggest concern here that nobody seems to be addressing, and that's the issue of sound-sync.

Rai, is your camera sound-sync, or does it go out-of-sync when recording for longer periods?

Jason: that is a good point. Are you talking about recording sound
with an external device and then synching that up, or do you think
the camera records sound as well? I would suspect it is the former.

The former. And I think we MUST test that out and see what the problems are, or else we're going to have big problems with our cameras basically not being well-suited for production.

BTW, the "external" recording device can be a DV camera.

Maybe a good assumption, there are a few groups here who intend on selling.

<<<-- Originally posted by Rob Lohman : I appologize to you as well Wayne if you haven't received a reply,
sorry about that.

It looks like we will not agree on this, and that's fine. I'm not sure
why a new camera would be a threat. I welcome Rai and his new
camera.

I'm wondering why you keep talking about a "business". I have
not seen Rai talking about a business or commercial effort other
than that his new camera will be used to shoot a movie with. -->>>

does anyone know of a good microatx board that has AGP and PCI or pci-x? I have to buy a board for testing with a Mobile chip on it..without this I will have no idea how well CineLink will function on a Mobile chip ;) ideas group?

BTW the tiny motherboards with on-board video will NOT work..I have tested with onboard, it's is much too slow.We need an AGP slot for video..I have never seen a micro board with agp..anyone have some info for that?

What resolution are you showing on screen?
if it is 960x540 at 24 fps it is around 37 MB/s so I can't see how you can't show that with the built in board.....
If it werent possible you wouldn't be able to see any standard resolution video on them neither..

960x540 24fps yes..it is really slow on the built in cards..I just found an Aopen microATX board that has pci and agp slots..I will buy that one now for testing

But the machine I'm using right now to write this has a Crappy SIS embedded video card using 8 MB of share memory.Running WinXP with just 256 MB on an Athlon XP 2000 and it plays 1024x768 8 bit uncompressed without problems.
It doesn't work with higher uncompressed resolutions cause it gets HDD speed limited.
1280x720 HiDef WMV9 works smoothly too......

Obin, are you using OpenGL or DirectX (DirectShow)?

Also were you using the Axiomtek board? What small motherboard were you using?

Jason: I fully agree. Audio needs to be sorted out fast and on a
pretty long recording as well to see if it drifts and if so how bad.

Hi all, first off, I've been following the board for a while and have been really impressed by everything everyone has done so far.

Obin, I'm not exactly sure if this will fulfil all your needs, but I found something with alot of the right stuff here:
http://www.rei.ricoh.com/download/pr...oduct_FB8M.pdf
The model is the FB8M

According to http://www.bwi.com/scripts/site/site....php3/id/9689/, this board is subject to a minimum order, but perhaps you can get single units elsewhere.

<<<-- Originally posted by Obin Olson : does anyone know of a good microatx board that has AGP and PCI or pci-x? -->>>

Conor,

I'm not sure that the board you spec'd is going to help out Obin, and then again, I'm not sure that Obin is necessarily having a problem with slow on-board graphics.

Even though the board you listed has an AGP slot, the graphics it's using is the Intel Extreme 2 which is embedded in the 855GME chipset. All these small boards that are high-quality now are using this 855GME/6300ESB chipset.

The Intel Extreme Graphics 2 engine is pretty nice. The only downside might be that it works off of the main system memory, so you'll want the fastest RAM you can put in (DDR333 for these chipsets).

Here's the specs:

http://www.intel.com/design/graphics...2_brochure.pdf

As you can see, they're pretty good, especially for embedded graphics. Maybe they're not a NV40 or X800, but I don't think we need anything better than Geforce2 or Radeon 7500 for these apps, do we?Is that shared with the main system memory (any type of UMA), or is it dedicated graphics memory?

If so, then again, this makes me think it's another problem, not a chipset/graphics problem.

I guess when we find out if Obin's using DirectX/OpenGL or what, we'll find out.

BTW, for 2D graphics, the Intel Extreme 2 Graphics engine is optimized for DirectShow, GDI+ and GDI.

yes, it is shared with the main memory.That leaves 248 MB for the OS. :(
Also if someone is interest the memory is DDR 266 and the video processor clock is 133 MHZ.

So then the Axiomtek and Kontron embedded boards should be fine, because they're using the 855GME, so you can use up to DDR333 for faster graphics performance (at least on the Kontron board).

Hmm, the problem with these onboard scheemes (and cards in general) is that there are so many ways they work, and many onboarders are less than impressive. So sometimes you may have to program different subroutine sets to get most of the cards working at optimal performance (something like the GAPI API does this for you). You wouldn't think this was a problem in 2D, but it is possible that the chip UMA is upsetting the stream lined pci->memory->cache->processor and back to disk chain, and causing stalls and misses. Somewtimes it is a bios issue, and short of getting the MB manufacturer to do a bios upgrade, there maybe nothing that canbe done with the board.

Juan, good to hear that my old SIS 8MB might be upto it ;)

the only hardware problem or limitation I can think of is if the video were going thru PCI bus, but even in that case adding 37 MB/s wouldn't clog it so, I give up.

In a modern chipset, the video shouldn't be traveling throught the PCI bus.

For instance, with the 855GME, the video is on the northbridge which is directly connected to the RAM. So we're talking for DDR333 @ 2.7GB/s, that's a whole lot more than 37MB/s!

Again, I'm wondering what Obin is using, since he was having tearing problems before, and using any double-buffered system and OpenGL/DirectX, there shouldn't be any tearing problems, or they should be extremely minimal.

<<<-- Originally posted by Rob Lohman : Jason: I fully agree. Audio needs to be sorted out fast and on a
pretty long recording as well to see if it drifts and if so how bad. -->>>

There are external, but pricey, devices that can accomplish this-word clocks. As far as just testing to see what the drift is - even once you find out, I don't think there will be much you can do about it as long as picture and sound are on seperate devices.

What I mean is, you can't just slap a crystal synch motor on this camera. A device to keep video and seperate audio in synch is such a specialized piece of equipment, I don't think it will be possible to build an adhoc replacement for it.

You could, I suppose, feed audio and video into the computer and have it keep synch for you. That probably would not be difficult, except that it would eat into your processing speed for video preview.

You also could set up a seperate computer that did nothing but keep synch between video and audio. It wouldn't need as much as the recording computer because it wouldn't have to record video. On the other hand, that will limit your mobility even more, increase the number of crew you will need, and possibly cost as much as buying a word clock.

Once, or maybe I should say if (that would be up to Rob S., or Obin's guy I supposed) the software reached an advanced enough iteration it should be able to take incoming video and audio, keep it in synch, and capture it to a quicktime/avi file in synch like a firestore. That will solve the synch problem right there (even if your also capturing to a seperate backup like DAT or DV or HDD or whatever). But I don't think we'll be able to do that right out of the gate. What do you think, Rob?

May I ask, given that the CMOS cameras (for example, one of the SI range) use an electronic shutter with a set clock-speed, how synch can become an issue. Surely if the timing of the images is electronically controlled, and, say, if you record to DAT or hard disk, then image and sound will remain in synch (once you align the clap/red-bleep).

As for the Motherboard problem, the FB8M I suggested is the only one I could find that was small and had a PCI-X slot for those fancy-dan framegrabbers. Does anybody have links to any other ones?

If film cameras have been doing sync-sound with crystal motors for the last 30 years (at least), and now we have a CMOS camera that has a clock synthesizer on it that can go down to the X.xxxMhz (3 decimal places) in accuracy, I think it's a little strange if you can't keep sync, at least for 10-15 minutes at a time, with an external DAT.

Frame Grabbers
 

Hi all. I was gone for a week at the Vision show in Stuttgart. In answer to your frame grabber questions, there are many 64 bit/66MHz frame grabbers out there. Add Leutron to the list. The issues are: cost, features, cost, OS compatibility, cost, SDK tools, cost, camera support. Did I mention cost?

We can bundle the Epix FGs for $500 with our cameras including $200 worth of cables and power supply. The 64 bit should bundle for $1K. My apologies to all for their problems shipping their 64 bit product. I've been hearing more optimistic delivery dates than those posted but this board is clearly a problem for them. The reasons (besides cost, which I think I've covered) we like them are: Good GUI (for machine vision) and an SDK for both Windoze and Linux. Good external triggering. Responsive customer support. Excellent color tools.

We have worked with many of the others. Some are specialized, like Datacube with lots of FPGA and RAM for $4K+. Or built in SCSI RAID controllers like IO Industries ($$$).

Others are just competent FGs, like Eurosys and Matrox. Not really cheap, but they seem to work well...... and get delivered. I can't bundle any of the others right now so expect to spend $1200-$2K including cables and power supply plus tools (some of the SDKs are not cheap) but I will ship a camera to any FG company that wants to support our cameras.

The alternative is to go gigabit since our interface supports data packing (2 12 bit pixels in 3 bytes) over the gigE interface. It also has a large enough buffer to implement the every other frame and average the burst bandwidth. (1920x1080x30fps x 12 bits = 750Mbps, under the 800Mbps for the interface). There are SDKs for both OSes.

Anyone out there waiting for the 64 bit FG and not wanting to wait anymore for Epix, I'll do a credit for them (based on the amount paid, not our full price since I'm discounting to this group).

If film cameras have been doing sync-sound with crystal motors for the last 30 years (at least), and now we have a CMOS camera that has a clock synthesizer on it that can go down to the X.xxxMhz (3 decimal places) in accuracy, I think it's a little strange if you can't keep sync, at least for 10-15 minutes at a time, with an external DAT.

It's very easy for DAT to drift away from clock speed unless there are some specific devices, like a word clock or something similar sending a synch signal from camera to recorder. It doesn't happen as much with HDDs or solid-state devices, but it can happen quite easily with DAT - one of the reasons sound recorders are happy to be moving away from DAT recorders.

Sorry Steve, I wasn't trying to spread FUD about the shipping dates on the EPIX, the February time frame was what their sales rep told me when I called to ask about some features in XCAP.

BTW, it's great to see you back. Hope you had a great trip.

Re: Frame Grabbers
 

<<<-- Originally posted by Steve Nordhauser : The alternative is to go gigabit since our interface supports data packing (2 12 bit pixels in 3 bytes) over the gigE interface. It also has a large enough buffer to implement the every other frame and average the burst bandwidth. (1920x1080x30fps x 12 bits = 750Mbps, under the 800Mbps for the interface). There are SDKs for both OSes. -->>>

Hi, I asked this of your sales people already, but can you give an indication of the price of the 1920HD GigE package (I assume that includes Camera, C-link cable, CL-GigE box, SDK, but will gladly accept correction)? I was kind of baffled by the response I got, in that the GigE version was more expensive despite not coming with a FG card. I naturally assume I have misunderstood, so better to ask again. Thanks.

As for sound, perhaps a simple solution would be to front- and end-clap long takes for two synchronisation points. You can then adjust any shift more easily in post, with a little simple editing. That is, if there is any.

The GigE solution comes with a framegrabber that hooks up via Gigabit ethernet. So it takes in a cameralink signal and outputs over Gigabit ethernet.

Re: HD Movie Project
 

Welcome Markus, good to have you here.

Steve, I think the problem with the Gige, is that, as I unbderstand it, it costs as much as a frame grabber to implement, it is not a hundred or two hundred doller solution. So the piont in buying it can become less attractive.

Gigabit
 

Some clarity on our gigabit solution. Right now we are using an external interface box (about 3"x4"x2") that converts our camera link camera into gigabit ethernet. That output is true ethernet - can go through switches and hubs and can be received by any gigabit card. For maximum performance, you need an Intel Pro1000 compatible card since we have custom drivers for it that will run continuous 800Mbps data. The serial port used to control the camera over the camera link side of things is virtual at the computer end - the data goes back to the camera over ethernet and is converted into true camera link (with hardware serial communications) at the interface box.

Right now the cost is more than our 32 bit frame grabber bundle but will decrease when we integrate the interface directly into the camera (underway). I will discuss prices off-line with anyone needing the specifics.

ASA 25

Until Markus tells us the sensor and configuration, it is all conjecture, but there are tremendous differences in sensor sensitivity. A good deal is related to the pixel size. Our SI-1300 has a 5.2 micron square pixel or 27 sq microns of sensing area. The SI-3300 has a 3.2 micron pixel or 10.24 square microns of sensing area. The SI-1300 is *Much* more sensitive. It is worse than it sounds because the capacitor and active circuitry for a pixel are fixed in size, so they take up a larger proportion of the possible sensing area in smaller pixels which reduces the fill factor - the amount of the pixel area available for photon sensing.

If the camera uses a global shutter, more transistors are needed for shuttering, which also reduces the fill factor This is why the IBIS-5 is much less sensitive than the Micron 1.3Mpix, even though it has larger pixels 6.7 micron).

The ideal sensor for this group would have large pixels, a good global shutter with minimal leakage and a Bayer filter. With this magic combination you get good sensitivity, no rolling shutter skew, limited DOF and single chip costs.

Oh well, you can't have everything :)

At least the ProCamHD 3560 sensor is definitely a great step in that direction.

what camera and capture setup are you using marcus/conor?

At the moment, I'm not. I was on the verge of buying an XL2 when I stumbled on this board. Since I have some time, I'm exploring the possibility of buying a set-up like this instead, since I'm primarily interested in full production.

it just occured to me that we could use a numberpad (like the mini keyboards that people use to crunch numbers) as something that could be attached to a camera body and allow on camera control... here's a link to what i'm talking about..

http://numberpads.com/products/numbe...tmedia_np1.htm

maybe someone already thought about this..

Actually yes . . .

Try this: http://www.xkeys.com/xkeys/xkstick.php

It also comes with software to map the keys and mouse clicks

Hey Ben I am strongly considering buying a sumix IBIS-5 camera. I know that this is not going to be a final version camera. Eventually I would like to be shooting on the Altasens but I need to start getting something put together now and hopefully shift the altasens into the workflow once its setup. I am wondering if you could just give me a little sum up of your experience with the ibis-5.

I would seriously not purchase anything at this point in time. The Altasens sensor-based products are right around the corner here in the next two-three months.

Also beware that they won't be cheap. I believe that Steve has already mentioned here that you should expect to pay $4500 for the camera with that sensor. So if you go out and purchase another $1000 for the Sumix, you're getting yourself that much further behind.

A lot of ground covered. Yes there are relatively cheap fast lenses:
http://www.navitar.com/zoom/cctv_do2595.htm 25mm f0.95
http://www.navitar.com/zoom/cctv_do1795.htm 17mm f0.95

These are 1" c mount and sell for $380 and $450 single piece. There is also a 50mm listed for $725. They will have a narrower FOV for smaller sensors.
These are machine vision lenses so they are not in the same league with Schneider and such. It depends on the sensor pitch (like film grain) how much of an issue it is.

IBIS-5A. If you want a 12 bit A/D, that is what we have. The internal 10 bit only makes things worse. Global shutter is a good thing for sure. Compromises are made.

Rai and Markus, my hat is off to you - you completed the camera project and are using it for its purpose. That is a real accomplishment. It is up to you as to whether you want to use or add to the collective information transfer of this group.