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.

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...

Ben is exactly right about this. I've had, to my extreme frustration, this exact experience working in 8-bit. It is a real pain.

<<<-- Originally posted by Jason Rodriguez : 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 can give you an idea. It probably is at least equivalent to a P3, but go to tomshardware, and anandtech, and see if you can find reveiws on 100 processors, or news links to, maybe it is included in the bechmark tests.

I can guess, without looking, the defficency of the VIA processors are first SEE, MMX and floating piont. For pure logical operations it is probably closer to P4. So for raw storage there maybe little different, for logical/integer debayering there will be a little bit more, for compression and floating piont dependant debayering there will be a significant difference, maybe %50+. Now most of the delay is actually on storage speed, rather than compression, so once you get to speeds required for storage, on each processor, we may have exceeded the speed requirements, in the unused Floating Piont/ SEE/MMX, for debayering/maybe compression. We won't know what that speed is until we optimise for OS, C, architechure, processor. Just an opinion, if you can follow my abstract thinking.

Really nice mainboard Jason, they didn't leave much out ;) .

Wait to September for new MB/? releases.

Wayne, did you see the new motherboard I posted?

Pentium M-based with PCI-X and SATA?

Yeah, I forgot to add it to my reply post, I just re-edited it in. Nice board, but I also know a few nice things coming around the corner (not saying they are any nicer though).

There's one new board coming out that's from a military manufacturer, it's going to be very small and very thin (mini-ITX, 2" thin with enclosure), but the only problem I'm having is that it'll need a PMC card, which means that Rob's work on the EPIX cards will be no good, I'll have to probably use a card from EDT. I'm not sure how big a problem that will be.

BTW price on the system is expected to be $2,000, but that's small compared to what you're getting (Pentium M, mini-itx form-factor, dual channel SATA, and PCI-X in a PMC format)

Obin,
Any news about the 3300??

Here is a brief tutorial on how to expose well witha 12 bit sensor. have a nice day and good exposures!!!

http://luminous-landscape.com/tutori...se-right.shtml

NEWS?

Wow the Panasonic VariCam is a NICE camera!

I have been shooting it today and I can't say I don't like anything about it ;)

but on the other hand it does cost a good $110,000 for the right setup with camera, lens, deck etc..so...ya this little tiny 1300 looks good ;) and even better then it did because I really think we/I can do more in post if you can get a GOOD chip like the Altasense or maybe the 3300..we will see....

Workflow sure is easy with the Panasonic...

Good link on the RAW stuff....I did learn a bit from that ;)

god that Varicam with the Canon glass is NICE..arrggg I want one! could I EVER build a camera that felt that PRO??


Oh yess real NEWS:

we are STILL fighting the SDK output for our capture software...my programmer is not to happy about this project ;( it's taking way more time then we thoguht it would..but I think we will have it over the "hump" soon..or so I hope...in the mean time it looks like Norpix has updated the Streampix software to support full color preview while writing RAW on the disk with not much system speed hit at all...and they will soon have camera serial commands for 1300 and 3300...

Well, according to the people over at Altasens when I visited them at NAB, their chip smokes the Varicam.

I saw the 3560 prototype's output, they had an evaluation board set up shooting the people passing by, and I must say I was very impressed-extremely smooth, no-noise images. We cranked the gain a bit, and still there was no noise that was perceptible. The head engineer on the floor there told me that out of the 4096 levels you can get from 12-bit linear, only the bottom 3 levels were noise, so this was a very noise-free chip. I guess we'll soon see how things pan out.

that would be GREAT Jason..lets hope!! I see that the VariCam has lots of range even though it's 8bit...I wonder how they did that? it has way more range then run-of-the-mill video cameras

variCam is HEAVY...I wonder if I should ad weight to our camera at some point? sure makes for a steady shot

Perhaps it would be best to have weights that the user can add themselves so that he/she can find the best weight and balance that fits him/her individually?

The Varicam has lots of great range because they're craming up to 11 stops onto an 8-bit tape (in the F-REC mode).

But have you tried color-correcting that stuff? With the heavy compression combined with 8-bit it goes south very fast. That's one of the reasons why I much prefer the Sony versus the Panasonic. Waaayyy too many compression artifacts with the Panasonic.

Sorry these responses are delayed -- I just got back from vacation.First format will be 16-bit TIFF, as Wayne mentioned. Check out the Convert development roadmap for further details.I absolutely agree, at least for the Convert app -- where most of the sophisticated algorithms will go. It definitely needs to be cross-platform and that eliminates assembly language for the most part.

On the other hand, often-used and well-understood algorithms could be optionally implemented in assembly -- the x86 code for PC/Windows, C/C++ for other platforms (or vice versa).

On the third hand, the "Capture" app (the "firmware"), just about requires assembly language to get reasonable near-real-time processing and preview.

Hey guys, I've been looking around,

and I'm not sure we're going to be able to power our "cameras" via battery power AND get 1920x1080. It seems like for a portable system we're going to be at 720p for now.

Here's my reasoning, and somebody please tell me if I'm wrong:

We're going to need at least a powerful Pentium M motherboard. That's a good power-draw right there.

Okay, we then need to run the chip at 48Mhz to get rid of any rolling shutter artifacts. This is based on the fact that even in a film camera, the film is only exposed for 1/48th of a second, the other part of that 1/24th of a second is for the film movement to move the film to the next frame. So the shutter is never open more than half the time. At 48Mhz, we're talking 199MB/s for 1920x1080 at 12-bit (because of un-packed bits, anything over 8-bit is going to use 16-bits from the camera). To record that 199MB/s speed you're going to need at least 4 Western Digital Raptors in RAID 0, and they each take up 9W each for Read/Write, and probably there's a pretty big power-draw in amperes for the spin-up (the Fujitsu below is 1 Amp). I'm not sure if the capture software knows to throw-away every other frame or not.

At 1280x720 12-bit, you're only using around 100MB/s-you'll still need a wider-bandwidth card, but at least this is reasonable for recording. I figure you can use 4 Fujitsu 5400RPM 2.5" SATA drives (80GB) in a RAID 0 config, they only use 2.3W for read/write, and 1 Amp for spin-up. Also recording at these speeds will give you 24 minutes of recording time on a 240GB RAID. That is again if the software doesn't know to throw away the "second" frame.

Hey Wayne, can you share that with the group?

Jason, how are you calculating your figures? Even at 16bit, 1920x1080 @ 24fps == 94.9MB/sec, nowhere near the 199MB/sec you cite. Remember that just because you're running at 48mhz, you don't need to record every frame -- the software should be able to record a frame every N milliseconds, or (hopefully) just let you enter an arbitrary frame rate.

1280x720 24fps @ 16bit == 42.2MB/sec...

That's assuming that the cameras will only be able to transfer at 16bit, which I believe will simply not be the case. Sumix in particular doesn't have the luxury of CameraLink's bandwidth, so anything they do will not be padded -- you'll get it as 10 or 12 bit data. Here are the numbers:

1080p (24fps) @ 8bit: 47.46 MB/sec
1080p (24fps) @ 10bit: 59.32 MB/sec
1080p (24fps) @ 12bit: 71.19 MB/sec

720p (24fps) @ 8bit: 21.09 MB/sec
720p (24fps) @ 10bit: 26.36 MB/sec
720p (24fps) @ 12bit: 31.64 MB/sec

I do agree that you're going to have serious power issues when dealing with 1080p. But at 720p, it's nothing a middle-of-the-road laptop can't handle. By the time the Altasens cameras are actually here (October or November at the absolute earliest), maybe we'll have slightly better gear anyway.

In any case, I still think 2-4 external laptop drives in a RAID-0 or RAID-5 (connected to a laptop) is the way to go. You should be able to do 10bit 1080p pretty easily with a few 7200rpm laptop drives...

- ben

I should add that unless the image coming directly off the Altasens sensor is as bad as the IBIS5 or Microns, you shouldn't need to even use 12bit -- and 10bit may even be overkill if the image is nice enough.

Logarithmic you mean?

dollar bill images Comparo
 

Here is that dollar bill image grab from my JVC. I think to really compare, we need to post a slightly moving camera image, as the potential for aliasing and crawl is high with the details on the bill.
I put Ben's grab on there too, for convenience.
http://s95439504.onlinehome.us/dollar-bills.tif

The tif is about 3 meg.

-Les

Hey Ben,

I want the full 12-bits off the Altasens. My Canon D60 is 12-bits and it looks phenominal, with plenty of room to modify the image any way I want.

BTW, if you're recording a frame every N milliseconds, can't you get off a bit if you're not recording at the begining of every frame? Say I end up grabbign at the middle of a frame, won't that screw things up? Or will it wait till the begining of the next frame, but again, you're probably going to drop a frame somewhere like that.

Ideally you would grab both frames and then just dump one from the image buffer to disk.

Also the camera has to run at 48Mhz initially, with that info streaming into the card, unless they're doing something on the camera to knock that down. But unless they're padded bits, like you said, it's going to be 16-bits transferring across the cameralink cable.

With the EPIX SDK, this won't happen because the SDK handles breaks between the frames for you.Yes, I'm planning to support straight 24 fps and "48 fps-drop-every-other-frame."

Jason,

I'm not sure what the methodology is, but I mentioned the need for arbitrary FPS to Sumix, and they seemed to think it wouldn't be a problem.

- ben

Obin,
The expose-to-the-right isn't so right!!
Be carefull with that, they make some asumptions about how the binary scale works that are not correct...
Anyway the rest of the info is good...So don't expose too much to the right...Right? :)



Ben and others,

What do you think if, using a 12 bit sensor, I apply through LUT a conversion to 10 log on the RAW Bayer?

Would it be a nonsense?
It would give us a data reduction of around 5 Megabytes per second at 24fps for a 1280x720 source and around 12 Megs for a 1920x1080 same Fps..

<<<-- Originally posted by Jason Rodriguez : Hey Wayne, can you share that with the group? -->>>

Not much, except things are developing as I predicted, and if we wait for the next cameras, or Rob's software, we should have a wider range of good options in cameras, main-boards, and maybe compression, to choose from. It really doesn't pay to rush out before suitable components are available, unless you want to experiment. I personally wouldn't mind a $1000 camera head, I'm still waiting to find out how much that $2K?? 3 chip Altasens 1080i/720p JVC HDSDI camera head will cost. You know there are multi mega-pixel still cameras for prices close to $100 (none really any good that i know of) but does a good 720p/1080i camera head really have to cost $1000-$3000 dollers?

<<<-- Originally posted by Obin Olson : that would be GREAT Jason..lets hope!! I see that the VariCam has lots of range even though it's 8bit...I wonder how they did that? it has way more range then run-of-the-mill video cameras

variCam is HEAVY...I wonder if I should ad weight to our camera at some point? sure makes for a steady shot -->>>

The problem is range has little to do with the amount of bit's used to represent it. 12 bits will go into 5 stops or 50 stops of range, the bit's represent the maximum amount of levels in the overall range, and you won't get those unless the camera is sensitive enough and noise doesn't wipe it out. Hence all my questions of sensitivity, range, noise and response curves for each colour (add highest resolution as well) for different gains, and target luminances (3 levels of each should do it lowest, medium and highest). If we had Only that (and lack of blooming smearing) can complete reveal the performance of a camera, even without a test image.

Thanks

Wayne.

You can read about how they did it with this paper at http://www.hpaonline.com/i4a/pages/index.cfm?pageid=236

Basically in a nutshell they've remapped the output of the CCD's so that it's not so high-contrast. They also added automatic gain in the darks, so you have to watch out when you CC'ing the stuff, since the shadows already have gain added and you don't want to add any more.

For the "flash" among us a new card standard, 120MB/s and 2 Terabyte capacity, USB2.0 compatable, hide it behind a large stamp etc etc, now if only they were out and we could afford one ;):

http://www.digitimes.com/news/a20040805A4013.html

Toms have reveiwed the "sticky pod", for us to mount our cameras onto moving vehicles (though if I would mount a $3K camera to such a thing, I don't think so).

http://graphics.tomshardware.com/vid...806/index.html

They have done niose tests on small cases, ouch that is a lot more niosey than my tower case, which is itself too nioise for portable apps.

http://www.tomshardware.com/howto/20...ebones-38.html


Thanks

Wayne.