Kyle what camera are you using?
do you have any clips I could see?
are you displaying in black and white or color?

thx for the info on packing we are playing with that ...

Obin & Wayne,
I'll let you all know when the software goes public, or not.

> thx for the info on packing we are playing with that ...
cool. this means also, as you might guess, more work at the RAW conversion end.

> Kyle what camera are you using?

Two mono SI-1300's, one Bayer SI-3300.

> are you displaying in black and white or color?

both, depending on the camera. color display is quick and dirty. stereo display is red/cyan.

My clips are large, I am still learning, and I am a bit shy about posting clips. Right now I am mainly using the SI-1300's for stereo work. I could post a 16-bit linear mono still picture some place (about 2 MB), if anybody is interested. (where? login?).

www.uploadhouse.com or www.imageshack.us

no luck uploading picture to upload house: not allowed for for PSD, SGI or TIF. Limit at imageshack is 1MB. If anyone wants the 1.4 MB (16-bit mono!) TIF file, just email me.

http://img216.exs.cx/my.php?loc=img216&image=vasesample9lt.png

I cropped it. This is un-gamma corrected, un-color-corrected. I don't know if the 10-bit data in the 16-bit TIF survived, or if it's just a plain 8-bit image. Looking at an uncorrected 8-bit image would be a waste of time.

wooohooo..and who says digital is not as good as film??


www.dv3productions.com/pub/BAND.jpg

a photo from a photoshoot I just did...like? hate?

using cheapo Sigma digital lens on my Canon 10D 6megapixel with some NICE light ;) a bit of photoshop work on the curves and the contrast...

I LOVE cmos chips...so "organic" I really see CCD and CMOS now when I look at professional work still/motion pictures

that looks tight obin. now we just need 24fps :)

yes 24fps....that is the ISSUE at hand...LOL

making more progress on save...Kyle we are working with the bit packing...looks like it may not save enough overhead/datarate to be worth it...

Obin,
Sorry to hear the packing is not helping you with your problem. I was thinking that the 64MB/sec packing would be the best (packing 3 10-bit pixels into one DWORD). Read three DWORDS (6 pixels) and write two DWORDS. That puts additional bus bandwidth at (96 + 64) MB/sec. If you have a 533 MHz FSB (2133 MBsec), I thought it just might work. The CPU should not be overloaded -- it sounds like a memory bottleneck. Oh well...

I am finally making some slow progress. I've spent the morning
developing a more efficient way of pacling bits. I'm in the process of
validating the code right now to make sure I am not losing any data. This
will take a bit as things are totally unintuitive and I have to check the
bits every few seconds to make sure things works properly. The main logic is
that pairs of pixels that are in short integes (16bit) are combined together
in 3 bytes thus saving 25%

of the storage requirements. The only strange
going on so far is that the order of these 3 byte packets are flipped in the
conversion for some strange reason. It seems to be happening during the
copying process. I'm debuggin this right now, but in any case it might be
irrelevant if they get flipped back during conversion back to 16 bit format
to create the TIFFs

I wan to try the bytes to Integer conversion first to
make sure we do no lose any data on the trip back. I got some code this
morning from that friend, but I cannot compile it as he forgot to send some
header files with it. It looks like it may be even more efficient, but he is
in meetings all day so I will not get the headers unitl tonight at the
soonest.

Obin,
You'll get it to work, I am sure! Two more points...
1) I wouldn't worry too much yet about doing it "perfrectly correct", and confirming the unpacking during the export process. More important is "optimally", i.e., the inner loop code. You want to make sure that your performance is not compromised, and that you are truly gaining something by writing less to disk, which in your case will be 72MB/sec
2) I have recorded about half a terabyte, so far. I just want to add that every byte you save is a byte earned: in the conversion process, transfering files, and archiving. It will be worth it.
My two cents.

That wont work as the pixels coming out of the SDK are 12bit even
though the underlying data is 10bit. You would need to convert them from 12
to 10bit and that would waste too many cycles. If they were already 10bit
this would be very easy to implement and would be just as fast as the 12 bit
solution with much better performance. I will fiddle with the SDK a bit
later to see if it is possible to get the actual 10bit pixels from the
framebuffer. Since Xcap does not give that choice I doubt it.

> That wont work as the pixels coming out of the SDK are 12bit even though the underlying data is 10bit.

you bit structure is then thus?

msb lsb
0000bbbb bbbbbb00

> and that would waste too many cycles.

not necessarily. this depends on how you are masking and shifting.

but if the 12-bit packing works for you, then great!