4:4:4 10bit single CMOS HD project

Obin Olson · March 19th, 2005, 08:43 AM

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

Kyle Granger · March 19th, 2005, 10:22 AM

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

Kyle Edwards · March 19th, 2005, 11:03 AM

www.uploadhouse.com or www.imageshack.us

Kyle Granger · March 19th, 2005, 11:27 AM

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.

Kyle Granger · March 19th, 2005, 11:38 AM

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.

Obin Olson · March 19th, 2005, 03:40 PM

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

Eric Gorski · March 20th, 2005, 12:10 PM

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

Obin Olson · March 21st, 2005, 08:21 AM

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

Kyle Granger · March 21st, 2005, 09:14 AM

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

Obin Olson · March 21st, 2005, 04:06 PM

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%

Obin Olson · March 21st, 2005, 04:35 PM

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

Obin Olson · March 21st, 2005, 05:00 PM

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.

Kyle Granger · March 21st, 2005, 05:08 PM

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.

Obin Olson · March 21st, 2005, 05:10 PM

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.

Kyle Granger · March 21st, 2005, 05:17 PM

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

March 19th, 2005, 08:43 AM	#2656
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	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 ...

March 19th, 2005, 10:22 AM	#2657
Kyle Granger Regular Crew Join Date: Feb 2005 Location: . Posts: 52	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?).

March 19th, 2005, 11:03 AM	#2658
Kyle Edwards Major Player Join Date: Nov 2004 Location: LI, NY Posts: 274	www.uploadhouse.com or www.imageshack.us

March 19th, 2005, 11:27 AM	#2659
Kyle Granger Regular Crew Join Date: Feb 2005 Location: . Posts: 52	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.

March 19th, 2005, 11:38 AM	#2660
Kyle Granger Regular Crew Join Date: Feb 2005 Location: . Posts: 52	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.

March 19th, 2005, 03:40 PM	#2661
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	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

March 20th, 2005, 12:10 PM	#2662
Eric Gorski Regular Crew Join Date: Jun 2004 Location: Western Oregon Posts: 138	that looks tight obin. now we just need 24fps :)

March 21st, 2005, 08:21 AM	#2663
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	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...

March 21st, 2005, 09:14 AM	#2664
Kyle Granger Regular Crew Join Date: Feb 2005 Location: . Posts: 52	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...

March 21st, 2005, 04:06 PM	#2665
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	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%

March 21st, 2005, 04:35 PM	#2666
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	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

March 21st, 2005, 05:00 PM	#2667
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	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.

March 21st, 2005, 05:08 PM	#2668
Kyle Granger Regular Crew Join Date: Feb 2005 Location: . Posts: 52	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.

March 21st, 2005, 05:10 PM	#2669
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	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.

March 21st, 2005, 05:17 PM	#2670
Kyle Granger Regular Crew Join Date: Feb 2005 Location: . Posts: 52	> 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!