DV Info Net

DV Info Net (https://www.dvinfo.net/forum/)
-   Alternative Imaging Methods (https://www.dvinfo.net/forum/alternative-imaging-methods/)
-   -   4:4:4 10bit single CMOS HD project (https://www.dvinfo.net/forum/alternative-imaging-methods/25808-4-4-4-10bit-single-cmos-hd-project.html)

Jason Rodriguez June 20th, 2004 03:47 PM

Hey Steve,

Quick question here on the rolling shutter (again :-)

Okay, please tell me if I have this straight. Right now the shutter is working like this:

line 1: Read, output, reset
line 2: Read, output, reset
line 3: Read, output, reset
. . . .
line 32 : Read, output, reset

so in other words, each line has to read, output its stuff, and then reset before it gets to the next line.

Can the camera work like this?:

line 1: Read
line 2: Read
line 3: Read
. . .
line 32: Read

and then say after getting to line 32, or line 102, or line whatever, then it starts to "roll up" going like this:

line 1:Output, reset
line 2: Output, reset
line 3: Output, reset
. . .
line 32: Output, reset

If the shutter could work in this manner, then it'd be the exact same thing as a film camera's curtain shutter, or the mechanical shutter in film, and that should reduce any problems with the "rolling shutter" artifacts we're having, if I'm getting it straight.

Les Dit June 20th, 2004 07:17 PM

The horror of rolling shutter explained ;)
 
Jason,
The following doc has a great write up on the whole rolling shutter issue. Check out the picture of the school bus, it's what I meant by having each scan line moved over by a pixel or so.
( not interlacing artifact, which is every other line moved over )

http://www.kodak.com/global/plugins/...Operations.pdf

-Les

Obin Olson June 20th, 2004 08:27 PM

perfect! that schoolbus is what my camera looks like when you pan fast with the mhz on the camera set low - like 27mhz

Steve Nordhauser June 20th, 2004 09:10 PM

Jason on RS readout:
When a line is read, the charge is moved to a one line shift register and shifted out. There is no room for another read until that line goes through the shift register one pixel at a time (2x for double tap) to the A/D.

Wayne:
Camera link does not limit the max clock rate - the on-board A/D and shift register do. This means a local buffer won't speed up the readout.

Jason Rodriguez June 21st, 2004 12:32 AM

Okay, I read the Kodak paper, and everything makes sense, rolling shutters work the way I though, that is like a focal plane shutter on a still camera.

So the question is, how come there's so much distortion in the image without motion blur? I think the real problem here is that you're getting this "slant" because there's no motion blur. That image of the bus, if it's really moving that fast, or the camera is moving that fast, should be very blurred in a traditional camera-with the rolling shutter in this camera, how come it's not?

I really think that's our problem, we should be getting some good motion blur here when we're panning around real fast or when something's moving through the frame quickly, and we're not. For instance, on a still camera, 1/48 of a second can produce a lot of blur if you're whipping the camera around. I haven't noticed any amount of blur like that on any of the rolling shuttered cameras I've seen so far from this thread.

Rob Scott June 21st, 2004 06:49 AM

Quote:

Jim Lafferty wrote:
Write even and odd frames to separate disks
That's a good idea, and I'm not sure why I didn't think of it :-)

In addition, to get the most performance out of the Capture phase, I've been thinking about "pre-allocating" large chunks of disk space before capturing.


I'm thinking most people using this system would want to dedicate a drive (or two) to capture anyway. So here's how I'm thinking it might work...
  • Format the drives to eliminate any possibility of fragmentation
  • Configure the Capture software to pre-allocate, say, 100 GB on each drive
    (The amount of space on each drive would need to be equal, even if the drives are not the same size).
  • Capture would pre-create files in 256MB chunks up to 100 GB.
  • Capture would take note of how long each file took to write and keep a catalog of this information.
My thinking is that this would help determine how many fps could be captured at any time. Toward the end of the drive we might not be able to handle higher frame rates, so we'd be able to warn the user.

Using a scheme like this, we should be able to support as many drives as practical without requiring RAID configuration.

The "Convert" software would recognize the scheme and automatically recombine the frames appropriately when doing its processing.

Obin Olson June 21st, 2004 09:58 AM

Ok I have 2 frames uploaded in 16bit tiff files :

www.dv3productions.com/test_images/studio095.tif
www.dv3productions.com/test_images/studio096.tif
5.2megs each

Rob S, have you found a good bayer filter yet?

Les Dit June 21st, 2004 10:41 AM

Obin, Nice images, can you upload the pre-bayer ones that those came from? ( B&W )
I'd like to look at the raw pixels from the camera for noise. The Bayer smears it all out...
It's Monday, I know!

edited: Actually , there seems to be an image pan on those.
Oh well.


-Les

Obin Olson June 21st, 2004 11:09 AM

maybe..I am not sure I have the pre-bayer file I will check

I am uploading a 180meg 8bit SHeervideo codec quicktime file full on native HD resolution, it has some over exposure in the image but I think some people would like take a look

Obin Olson June 21st, 2004 11:26 AM

Ok Les, I have 2 images the camera was not moving at all it's flowers outside I will upload as soon as the big 180meg file is done

Rob Scott June 21st, 2004 11:38 AM

Quote:

Obin wrote
have you found a good bayer filter yet?
I have several algorithms, but I haven't yet attempted to implement any in C/C++ yet. I'll be doing that soon.

I was going to start here: http://www-ise.stanford.edu/~tingchen/
... and implement a few of the better-performing algorithms such as "Linear Interpolation with Laplacian 2nd order color correction terms I" and "Pattern Recognition". If anyone has any better suggestions, please let me know.

Obin Olson June 21st, 2004 01:39 PM

It's a big one!

http://www.dv3productions.com/video ...0bit-4-2-2.mov

180megs

Les for you:
www.dv3productions.com/test_images/flowers1.tif
www.dv3productions.com/test_images/flowers2.tif

flowers with no over exposure! ;)

http://www.dv3productions.com/test_i...flowersRAW.jpg
http://www.dv3productions.com/test_i...DflowersCC.jpg
from 8bit

Jason Rodriguez June 21st, 2004 03:47 PM

I'm getting a "page cannot be found" error on the movie file.

Les Dit June 21st, 2004 10:56 PM

Thanks Obin
 
Well, those have less motion in them.
Let me explain what I wanted to do:


Here is how you separate noise from image:
You take two images of a static scene. You difference them.
What is left over is just the camera noise.
Now, if something moved in the frame on one of the images, what you see in the diff is primarily the edges, with the rest being mostly black.
In order for this to work, there can be no motion between the two frames. Otherwise you have no way of telling if it's noise or just image detail being different on the two frames!

I know it's hard to not move the camera a few microns, so that is why I previously recommended a slightly out of focus setup. That way fine detail is gone, so it's not as sensitive to a very slight positional shift.

Shooting frames to look for noise will result in very crappy looking images, artistically and compositionally, but they fit the need for studying if the camera will fall apart on moderate color grading or trying to get good pictures of a dark scene.

How about an indoor windless locked off setup, throwing it so far out of focus that details are blurred to 10% of the image width ?

No priority for me, but others may be interested in the results, especially if they may be getting the camera for a project or whatever. I did notice that one pair you posted had some broad noise bars new the top of the frame, almost like hum bars on a TV. Anyone see those?

-L


<<<-- Originally posted by Obin Olson : Les for you:
www.dv3productions.com/test_images/flowers1.tif
www.dv3productions.com/test_images/flowers2.tif -->>>

Rob Lohman June 22nd, 2004 05:03 AM

Les: I'm not seeing those noise bars.

What I'm seeing on those studio*.tif files however is some very
apparent blocking on the red spots on the bottle.

Do you happen to have the original bayer file on that Obin?

I'm wondering if that is due to a low quality bayer conversion or not

Thanks for posting the pictures Obin. I'll see if I can run some
test on those regarding our software.


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

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