nope SOftware is NOT working..SDK is broken and we are working aorund that issue now...almost ready to buy a new baord with a better SDK!!! arrgg

will keep you posted

Rob

Have you decided what your Convert app is going to convert to (I assume for the first version it's going to convert to one format only)? or are you still thinking about it?

I believe he mentions 16-bit TIFF on the wiki

Anyone here,

I'm not sure if I remember Steve mentioning any, but are there any shortcomings to using the GigaE Cameralink interface versus the frame-grabber card for what we're trying to do?

Jason:
Here are the pluses and minuses for gigabit:
800+Mbps transfer rate to an Intel Pro1000 interface
This is OK but you have to watch the 12 bit data rates. Roughly equivalent to a 32 bit FG.

More expensive than camera link.

Compatible with laptops - the IBM thinkpad T40 has the fast chip set.

100m from camera to computer - might be nice if you are embedding a couple of cameras that you want to hide.

More data complexity - you have to convert to packets, transmit over ethernet, receive packets and unpack into buffers. Camera link is a parallel dump into memory buffers.

You can use conventional switches and hubs for multiple cameras, >100m distances. Cheap wiring.

By the way, I talked to Imperx - the cardbus frame grabber people. He says that many of the chipsets are slow for cardbus but with the right chipset you can do 800Mbps into memory. He is willing to support our cameras if people want a particular camer model.

Hi Steve,

I went on the Intel website, and I couldn't find a Pro1000 on the ethernet controller page at http://www.intel.com/design/network/...inecard_ec.htm, but the Intel ethernet controller that I'm looking at on that board is the Intel 82541GI.

The board is a mini-ITX board from Lippert-At. The data sheet is at http://www.lippert-at.de/fileadmin/l...TX-PM-R1V4.pdf if you or anybody else on this board is interested. It is capable of up to a 2.0Ghz Pentium M (Dothan), 1GB of RAM, and has a Mini-PCI and a standard 32-bit PCI slot. I figured the camera could be hooked up via GigaE, and then a SATA RAID controller card with 2 WesternDigital 10K Raptors could be hooked up for a lot of data throughput on the available PCI slot.

With the GigaE software, do you loose any functionality in operating the camera (specifying framerates, etc.) that you would have had with the frame-grabbers?

Wayne:

"<<<-- Originally posted by Jason Keenan :
dealing with if I decided to have a play at a basic assembly based bayer filter. It wouldn't be very good, but hey, it's just geek fun.

-->>>

Yes, please do. Rob has had very good results (performance gains) going from straight C to include inline assembler. People are so used to C (and Windows) they don't realise how much of a ball and chain it is compared to assembler."

First problem -

The trouble with assembly is it's inextricably linked to processors, therefore it's not easy to transfer to another platform ie x86 to motorola.

Next problem -

In reference to my "it wouldn't be very good" bit, the reality is that there are people with highly sophisticated mathematical and programming knowledge who are skilled at putting together algorithms. Even fairly simple mathematical processes are difficult in assembly. Generally, PC assembly writers will use HLA (High Level Assembly) like MASM32. Because you end up using standard math libraries, you tend to get bogged down again in stuff that wasn't specifically designed for your purposes alone so things tend to bloat a bit anyway. The reality is, I don't know enough to do really low level programming in assembly. It's just the only programming language I know (or at least used to ;) as, in my younger, more foolish days, I used it to analyse disassembled binaries and write small patches and serial generators.

I think staying in C/C++ is the most sensible option. Using some existing cross platform libraries too is probably a good idea, just so other people can work on porting them with a minimum of fuss.


Random thought-

I was thinking a few days ago about the mounting of these cameras (SI and Sumix and other machine vision) and mulling over some of the discussions about fitting them in old 16mm cameras etc. It occured to me that, if one were up for it, due to their size they lend themselves to unique possibilities.

One thought I had was to put all the other hardware in a backpack and design a simple body/shoulder brace that you could operate the camera on a counterweighted pole (like a broomstick balanced on your shoulder), like a puppet, away from your body with two sticks. Sort of like a mini portable crane. So for example, you could change pitch, roll and yaw by twisting the stick handles, the preview screen would be mounted on the body/shoulder mount in front of you.

I know that some "old hands" are up for a traditional style camera housing, but I just thought there was an opportunity here for something a little more...wacky.

Raavin ;)

Found another interesting Pentium M motherboard

http://www.ibase-i.com.tw/NEWSib880.htm

Has PCI, two SATA connection, etc. Looks pretty good.

I was only encouraging ;) It sounds like most of my arguements, but where else to go for extra power, without extra power consumption. Sorry, I had my hopes up there for a moment. It might be good to use inline seembler in C, or cross platform assembler (for PC and MAC G??, 68K won't cut it, but is slower so you might as well do it in Toas VOS Vprocessor code)) for the most important capture/processing parts. At the moment ROB is aiming at doing cross platform, this is not a death nail to Mac as the processor specific sections canbe rewritten fo that version.

I wouldn't be surprised if Rob could achieve upto 80-90% of the capture throughput advantages of assembler this way.

Everybody:

For cases we can individually put together anything we like. Laptops in backpacks, cameras on poles (been thinking of those myself) are all good. I'm just going to concentrate on solutions for semi-computer technical professionals myself.

Thanks

Wayne.

Back from vacation!
 

Most of you have propably seen me on the forum this week
already and seen me replying wondering why I wasn't at this
thread.

I had 1100 threads to work through when I came back. Took
me sunday, monday & tuesday. All of today I spent looking
at the various building our own cam threads and time to
prune and streamline this thread again. Y'all have been busy!

It's late in the evening already here so I'm turning in shortly.
Tomorrow I will be attending my e-mail, so Wayne, you'll get
a reply to various things then.

Some minor things:


Jason et all: The Search actually can search within just one forum.
You CAN search on a persons name if you stick the persons
exact fullname (as it is written on DVi) in the search by fullname
box. Then you can check "Show results as posts" to not get
the results as threads but as posts, neat huh!

Wayne: if you've read the instructions on the search page you
know you *can* use OR and wildcards like * !


Ben: you've written on numerous occassions in this thread that
you cannot perform a white balance on 8 bit color files. I'm
wondering why you are thinking this since to my understanding
white balance is nothing more than shifting colors around.

I think the problem with low bit images is that they fall apart much faster when you play with the color than high bit. (that's probably obvious -sorry). Take an 8 bit image and enhance it for color and contrast and then compare it to a similar 16bit image (via the histogram). The more bits the more you can tweak the image before you start to see degredation.

Aaron, exactly right.

@Rob: you've written on numerous occassions in this thread that
you cannot perform a white balance on 8 bit color files. I'm
wondering why you are thinking this since to my understanding
white balance is nothing more than shifting colors around.

"Shifting colors around." Oh if it were only that simple. :)

"White balance" is really another word for the "input white" sliders in Levels. So if you white balance to make the image more blue, you're moving the input white slider down in the blue channel -- thus increasing contrast in the blue channel and throwing away precious values.

In 8 bit, you're lucky to get 240 "real" values per color channel. If you have to do a big white balance operation on the image (such as going from daylight to tungsten), you may be cutting the blue channel in half, leaving you with somewhere around 100 or 120 real values in the blue channel.

Try doing that, and you'll see why I discourage people from doing white balance on 8 bit images. If you have to increase saturation after the white balance, you are pulling those values even further. Odds are you won't like the image...

You can try adjusting the gamma of the color channels instead of moving the input white sliders, but odds are you'll wind up with an "off" looking image.

Re: Dual slope on IBIS-5
 

<<<-- Originally posted by Steve Nordhauser : At the risk of supporting my competitors' sales, here is an application note on dual slope with the IBIS-5:
http://www.siliconimaging.com/Specifications/Dual-Slope%20Ap%20Note%20001.pdf
-->>>

I would just like to say that the dual slope example in the PDF looks really good, it is just the sort of thing I'm looking for. How many stop range are we looking at? How much better is the Altasens going to be?

Thanks

Wayne.

p.s. Good to have you back Rob. Sorry about the search thing, somebody resolved that for us a while ago. The email thing, I've just let it slide and given up on it in the last month or so. Onto the next thing now.

Dual Slope
 

Wayne, it might be possible to write a complex autoexposure routine for dual slope. There are two variables - the epxosure time of the dark and the exposure time of the light areas. This is only available in global shutter mode so the exposure time of the dark (the other is a subset) is added to the readout rate based on the current clock. The idea is that this sum plus blanking time gives you your frame rate. More complicated when you target a specific rate such as 24fps.

The Altasens will be much better - more like a true 12 bit and more sensitive. We haven't experimented much with it but there is also a mode called DNR (dynamic noise reduction) which can apply different amounts of gain - much better than dual slope because the integration time is the same.

I think I said it once but I'll say it again. Altasens is delaying shipment on sensors. We will not be in production for something like 8 weeks. It does suck to have a bunch of built up cameras and no sensors. On the other hand, it is probably worse getting a bad batch of sensors so I will assume the delay is justified.

Oh gosh,

Sorry to hear about another 8 weeks for the Altasens,

BTW you wouldn't happen to have any more demo images, perhaps some in color?

Another note,

Is a SATA RAID necessary for our setups? Can we software RAID 0 two IDE drives on an ATA100 bus (master and slave, not two seperate channels) and still get enough throughput for 12-bit on the Altasens at 1280x720 and 48fps?

Also Steve, how much processor power is required for these capture cards? I've been looking at some mini-ITX boards with the VIA C3 processor (the new Epia-SP board has dual SATA channels), but I'm worried that the C3 is going to be too slow for these apps. A 1.3Ghz C3 is probably equivalent to a 800-900Mhz Pentium III in speed.

I may have found THE board for our apps guys,

http://www.axiomtek.com.tw/images/da...s/sbc83810.pdf

This has Pentium M, SATA, and PCI-X!

All in a 5.25" form factor (EBX), so the board is fairly small.

Check out the datasheet and tell me what you think.

I think the only downside is you might need a custom enclosure.