4:4:4 10bit single CMOS HD project - Page 178 at DVinfo.net

Go Back   DV Info Net > Special Interest Areas > Alternative Imaging Methods

Alternative Imaging Methods
DV Info Net is the birthplace of all 35mm adapters.


Closed Thread
 
Thread Tools Search this Thread
Old March 19th, 2005, 08:43 AM   #2656
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 ...
Obin Olson is offline  
Old March 19th, 2005, 10:22 AM   #2657
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?).
Kyle Granger is offline  
Old March 19th, 2005, 11:03 AM   #2658
Major Player
 
Join Date: Nov 2004
Location: LI, NY
Posts: 274
www.uploadhouse.com or www.imageshack.us
Kyle Edwards is offline  
Old March 19th, 2005, 11:27 AM   #2659
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.
Kyle Granger is offline  
Old March 19th, 2005, 11:38 AM   #2660
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.
Kyle Granger is offline  
Old March 19th, 2005, 03:40 PM   #2661
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
Obin Olson is offline  
Old March 20th, 2005, 12:10 PM   #2662
Regular Crew
 
Join Date: Jun 2004
Location: Western Oregon
Posts: 138
that looks tight obin. now we just need 24fps :)
Eric Gorski is offline  
Old March 21st, 2005, 08:21 AM   #2663
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...
Obin Olson is offline  
Old March 21st, 2005, 09:14 AM   #2664
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...
Kyle Granger is offline  
Old March 21st, 2005, 04:06 PM   #2665
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%
Obin Olson is offline  
Old March 21st, 2005, 04:35 PM   #2666
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
Obin Olson is offline  
Old March 21st, 2005, 05:00 PM   #2667
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.
Obin Olson is offline  
Old March 21st, 2005, 05:08 PM   #2668
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.
Kyle Granger is offline  
Old March 21st, 2005, 05:10 PM   #2669
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.
Obin Olson is offline  
Old March 21st, 2005, 05:17 PM   #2670
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!
Kyle Granger is offline  
Closed Thread

DV Info Net refers all where-to-buy and where-to-rent questions exclusively to these trusted full line dealers and rental houses...

Professional Video
(800) 833-4801
Portland, OR

B&H Photo Video
(866) 521-7381
New York, NY

Z.G.C.
(973) 335-4460
Mountain Lakes, NJ

Abel Cine Tech
(888) 700-4416
N.Y. NY & L.A. CA

Precision Camera
(800) 677-1023
Austin, TX

DV Info Net also encourages you to support local businesses and buy from an authorized dealer in your neighborhood.
  You are here: DV Info Net > Special Interest Areas > Alternative Imaging Methods

Thread Tools Search this Thread
Search this Thread:

Advanced Search

 



Google
 

All times are GMT -6. The time now is 11:27 PM.


DV Info Net -- Real Names, Real People, Real Info!
1998-2017 The Digital Video Information Network