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

BTW, I've found a very fast solid-state device.

They're planning on releasing an SCSI U160 and U320 device that can sustain 230MB/s. Right now the sales person that contacted me said that it should cost around $1K per Gig, which isn't too bad if you have a couple gigs on this thing to serve as a temporary capture device and then offload to another slower SATA drive. But again, load one of these puppys up (they're expandable to around 122GB I believe) and you're definitely not going to have to worry about lugging around a hard-drive array and any associated problems with RAID 0 or 1.

check it out at http://www.bitmicro.com/products_edisk_transit.php

If you only get 1 or 2 gigs, why not just get 2 gigs of RAM and record to that? Much less expensive...

For the Altasens you're going to need a lot more than 2Gigs, especially if you want to record 12-bit linear, which the chip is capable of.

Might be slightly pricey, but then again, this is for something that could sit nicely on your shoulder.

I'll be shooting with the Altasens at 720p and probably 10bit. 1080p at 12bit is a bit much for me right now. But I understand where you're coming from.

Do people out there really want an all-in-one shoulder-mountable ENG-style camera? I sure don't, especially if it will cost more. I don't do a lot of handheld shots -- so if the camera's going to be on a tripod or dolly anyway, I don't mind having a laptop sit next to it... The Kinetta is cool, but you pay a high price for an all-in-one solution. Not to mention the fact that it's not very easily upgradable. By using cheap and standard components, you can swap things out pretty easily...

I've done more research, and I think a good alternative to high-end solid state stuff is strapping together a few 7200rpm laptop drives in 2.5" FW800 cases. Stripe them into a RAID configuration, and hook them up to two or three FW800 buses (2 CardBus FW800 ports + built-in FW800 port). Check out this page at barefeats.com giving benchmarks for this type of configuration. (http://barefeats.com/fire42.html) They were getting 67 MB/sec over CardBus with a 2 drive RAID. I'm sure you could do much better with three or four drives.

How much is 67 MB/sec? Well, 1920x1080 @ 24fps in 10bit is around 60MB/sec. So you could handle that with just two pocket-sized external drives taped together. Or you could do 1280x720 @ 48fps in 12bit, which is around 63MB/sec.

I think cheap external RAID is the direction I'm headed.

one Raptor SATA has a 72 MB/s speed and costs 199...............

Yeah, but you can't carry it with you. I'm talking about laptop solutions...

Why I cannot carry with me a normal PC Hard drive, are you kidding???

How are you going to power it? Plug it into a tree? Carry some custom battery?

If I can carry a Laptop with its batteries, I can power one little disk which just needs around 10 watts and weights 1.60 Pounds I guess, but as usual I know you'll tell me I'm wrong....


http://www.westerndigital.com/en/products/Products.asp?DriveID=65

No, no, no. Relax -- I'm seriously asking. How would you power it? Most laptops probably won't deliver 10watts through any of the buses (maybe over 2 USB2/FW buses combined?) so would you adapt a batter for it?

If I can't take power from the HDs conectors I guess I can take it from somewhere else, if not I can take it from the Laptops battery connectors and add a little regulator, transformer (don't know the exact english name) to power the disk..
If all this fails, I guess I'll need another laptop battery or a camera battery with a power regulator to get 12 and 5 volts from it....
Anyway it would always be smaller and less power hungry than a Firewire RAID or several disks...

A FW raid with 2 disks would only take 6W maximum during read/write operation, and it could all be bus-powered... No extra power source needed...

two laptop disks??
Are you sure?

What do you mean? Yeah -- laptop drives draw a max of 5W on spin-up (5.5 for 7200rpm), but only draw a max of 3W during normal operation. With two separate buses, you should have no trouble powering them (a single bus may not power both, depending on the laptop).

And 2 FW800 drives is enough to give you 67MB/sec, like I cited before...

can the laptop drives be used on a SATA connector? that would be a very good setup and somthing I will look at for the camera

Steve will I get a 3300 soon?

once again we used the camera for a "real" shoot today of a product on a bluescreen for comping and once again the "streaking" ruined the shot...the good side is that the streak was on the blue so it was cut out anyway...

Obin, is your software finally working?

Obin, when you get your new 3300 please could you give me an aproximate sensitivity in ASA scale ?

I haven't been paying attention to the DAC offsets in my camera's settings, and I think that's why we were seeing excessive banding in previous images. I'm still experimenting with how far I can push the image once the DAC offsets are set correctly, but here's an example image with no hardware image correction (http://www.bensyverson.com/hd/images/footage/ben-cinegon.jpg), but with a software gamma applied, and my chromaPop plug-in.

I think I'm getting the hang of it. There's still a little banding in certain areas, but it's way less intense. I might be able to push the hardware gamma up a tad without affecting the banding. Software gamma adjustments from 8 bit data will definitely accentuate any banding...

- ben

Ben Syverson wrote:
But I'd rather not work directly on Rob's app, as I think he's focusing on a PC-based solution, whereas everything I do is on the Mac. Also, I think Rob's sw is basically capture software specifically for CameraLink (Rob, correct me if I'm wrong), which doesn't apply to my camera.It may make sense to share certain techniques and code snippets, but if I decide to go forward with a Quicktime codec, a lot of that code will be fairly specific.I am working on two things: Capture app -- CameraLink- and Windows-specific (for now)
Convert app -- cross-platform conversion/filtering appThe Capture app will probably be closed-source, but the Convert app will be developed under the GPL, so it would be a good place for your Bayer algorithm to go, if you're interested in incorporating it.

When I have some time, I'll try to work up a better road map of the software under development.

(I have also thought about working on a codec, but I have way too much on my plate already.)

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/products/ethernet/linecard_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/lippert-at/products/ITX/Thunderbird/TME-ITX-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.

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 (http://www.dvinfo.net/conf/search.php?s=) 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.

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

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/data_sheet_files/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/tutorials/expose-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.Joshua Starnes wrote:
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?First format will be 16-bit TIFF, as Wayne mentioned. Check out the Convert development roadmap (http://www.obscuracam.com/wiki/static/Convert.html) for further details.Jason Keenan wrote:
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.

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.I absolutely agree, at least for the Convert (http://www.obscuracam.com/wiki/static/Convert.html) 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 (http://www.obscuracam.com/wiki/static/Capture.html)" 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.

Wayne wrote:
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)

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