Thanks Rob! I meant to do it but totally forgot, will do it next time.

I'm in the process of moving the camera right now...

I managed to move the entire thing, computer and all to my sliding door window, but i got done pretty late last night...it's a nice day out today so i should have a clip soon.

I'm also taking a stab at reseating the probe to see if the speckles are related to the connections. As far as i can tell there are two bits one in the green an another in the red which somewhat randomly goes to zero and sets the pixels to a dark color...

if someone can take a stab at looking at the speckles and seeing if they agree, and which bits are causing the problem, i'd appreciate it just to have some other insight. I checked them by looking at adjacent pixel values around the speckles and then seeing what was missing from the speckled value...think about it in binary numbers, and if a single bit is causing the problem all over an area....

Thanks
Juan

Ok, i have a couple of clips. Not much just a car driving by my house and a friend of mine waving. I also have DV counterparts. Like the previous frames, the difference in latitude is obvious. In one shot, the sky, concrete road, and several other areas of the scene are just straight out white on the DV footage, while nothing clips in the RAW footage, and even captures the different tones in the sky.

However, a 3 second clip is well over 100MB, and I do not have the web space. What does everyone suggest? Also, i have a stream of frames which i can use as an animation in Shake, or FCP but does anyone have any suggestions as to what video format to use? The best I can do with what I have is 4:2:2 uncompressed 10-bit MOV i think.

I've got all 30-bits, but the speckled noise is still there...my main task now is to try and figure out where it is coming from.

Juan

I've got space but no bandwith left because of my test clips. I know DVInfo does or I could take donations for extra bandwith if they don't have space.

I may have about 4~5 gb bandwidth a day to spare for a while. Let me know if you need it and I can setup an ftp account for you.

-Rodger

I have posted 30-bit RAW and DV versions of the same frame, from a clip i recorded today. Unfortunately, the speckles affected nearly all the fine details in the RAW capture, but nevertheless it is a good example of the added latitude.

The color is waaaaay of(can you guess from the red sky?), but this is because I am posting the unaltered output from the CCD's...if you want to take a crack at doing color correction please do so and email me the result so i can post it.

http://expert.cc.purdue.edu/~pertierr/cap2_DV.tif

http://expert.cc.purdue.edu/~pertierr/cap2_RAW.tif

I am hard at work now trying to figure out where this video-pox is coming from. :)

Juan,

The R,G,B channels in the RAW data don't seem to be lining up.

In Shake view the separate channels of both the DV and the RAW and you can see the shifting in the RAW.

That would explain the colored edge fringing.

Shooting a b&w chart would help figure out the pixel shifting.

Great work. I monitor this thread very closely.

Pete

That's right! Thanks for pointing it out.

It's tricky to find what is the correct alignment, so i decided to post the photoshop file for that frame, with the R,G,B as separate layers. If any of you can take a look and let me know what you think is the correct alignment. I beleive the infamous pink line on the left of the DVX output may be just an artifact of shifting the R,G,B frames for alignment, so it might be a hint as to what is correct. This psd file works well also if any of you want to try to color correct this thing:

http://expert.cc.purdue.edu/~pertierr/cap2_RAW.psd

I'm assuming the color issues is due to the camera not doing the
whitebalancing to after you captured the RAW footage? If so,
some on the fly color shifting (something else than correcting)
might be interesting to have...

I did a little manual color balancing in Vegas (somehow it doesn't
seem to have a whitebalance filter and neither does Paintshop
Pro, weird!) and came up with the following:

manual white balanced cap2_RAW

r, g, b shifting/line-up
 

Here's a first pass at lining up the channels. Using the green channel as the base to match.

red x-shift = -0.7 y-shift = 0.7
grn x-shift = 0.0 y-shift = 0.0
blu x-shift = -1.0 y-shift = -0.5

Unfortunately it's sub-pixel movement. Are you shifting the channels around in your software?

Nope, i'm posting the frames just as i receive them from the A/D's, and just aligning them with 0 offset.

I was afraid that in fact the CCD alignment on the prism is not perfect and fractional pixel offsets would be involved....maybe if we up-res it to HD, and ~then~ overlay them and shift them?

Juan

I also did little manual channels adjusting, color correction, curves and alignining in Photoshop.

Here's the result:

http://www.starzonefinland.net/jarno...W_CC_ALIGN.tif

That's nearly as good as I could get it, unfortunately you still can see some noise in the contrasts. It _looks_ like the channels are still unaligned, but while trying to correct it I found out it's sub-pixel, just like you wrote and mixed with artificial noise.

Oh well, hope this helps. I can see if there is still something i could do with the frame, but for now i'll have to leave it alone and go read some internal medicine... And yeah, you're doing a great job - keep on up with it.

-Jarno

confusion
 

ok, i need some help here.

I'm trying to get rid of the noise, and in examining the raw data files along with the images i'm getting, there is something i don't understand.

I am using only the high 10 bits of 16-bits, there for the highest number that can be represented is 1111111111000000b, and the lowest is 0b.

However when i load the image as a raw file in photoshop or image converter, it reads a 68 decimal value as a grayscale level of ~4. Do paint programs set the black value at 64decimal or so? Like wise, what is considered 'white'? because even though I can reach the full 16-bit range because i'm only using 10-bits, if i overexpose something i still get white in photoshop!

I'm burned out for tonight trying to figure out where these speckles are coming from...please do give this a crack:

if i aim the camera at a light and overexpose the entire frame, i get ALL WHITE, no speckles! What kind of 'noise' is so specific? The whole theory of a high-order bit being intermittent doesn't work because for white all bits have to be active, if any bits where intermittent or badly connected it would surely show up as noise.

It's a brain-frier. I any of you have any theories whatsoever i'd like to hear them.

Juan

Here is the most speckle-free 4:4:4 30-bit frame i've gotten out of it so far. This one was a very dark frame to begin with(ND2), i adjusted the levels a little. I like the way the dark details still showed so i here it is:

http://expert.cc.purdue.edu/~pertierr/cap5_RAW.tif

I ~think~ the noise problem might be a ground problem, but i'm not sure. I did some tests which seemed to reduce the noise but the sun was also setting, so I am not sure if the problem is just with the mid-range luminosity.

Juan the spots are what looks sorta like what is called a dead pixel ...I am guessing it is caused by some sort of bad connection you have on the test bench

Obin,

I doubt it is a dead pixel, or even a hot pixel issue.

Juan pointed out that the noise seemed to go away when he overexposed. If the pixels were dead (no charge) or hot (always charged) they would still show up as noise when over or under exposed.

I don't know enough to know what the problem may be...but I can at least guess at what it isn't
:)

-Luis

I did again some testing with the cap5 frame, and here's what I got:

http://www.starzonefinland.net/jarno/cap5_BMP.bmp

It's just a 24-bit bitmap, but what's essential are the color samples up there; they represent with a ~60 percent accuracy the noise hues, that is, if you in Photoshop select the color samples with a 60% magic wand, you get almost all of the visible noise selected.

What seems to be quite interesting is that the colors seem to line up somehow to represent some kind of a color scale. I didn't have time to do any calculations, but I think they're somewhat connected...

Well, I'll return with this issue later.

-Jarno

PS, does your browser show the tiff images correctly? My computer opens them with a Quicktime extension, and they look false, for example the cap5.tiff seemed okay in PS but in explorer it was all blue? Is it just that QT doesn't support the 16-bit images?

Jarno:

That's right, QT, does not support 16-bit and shows them false in the browser.

Jarno,

That is an interesting point, thanks for noting that...any other relationship you can come up with will greatly help me in figuring this out.

Another interesting point: I am synching up my capture card on the PC with the clock that drives the three A/D's. The images i've shown you so far are capturing using the rising edge of the clock. if I switch to sync with the falling edge of the clock, i get the same images but with ~more~ speckles in the same areas as before. This makes me think that it has something to do with the clock, maybe i am driving too much stuff with it and it is degrading.

Juan

I done calculated the noise colors.... Arrgh. This makes me nuts. I couldn't find any greater correlation between the color values, at least with my math. My friend is studying maths, maybe she could figure something out of the values. That shall be seen tomorrow, now I'll anyway go to sleep, it's 2.00am and my head's spinning around with the values... :)

-Jarno

btw, found out a funny thing. If you convert the picture (cap2_RAW) to lab color and turn off the 'a'-channel, you get a quite nice looking image. Also in CMYK, if you turn off the magenta channel, the image looks quite correct (a bit greenish), without having to do any other color balancing. Anyway, probably this hasn't anything to do with nothing, just a detail...

Wow. This stuff is just...hot DANG, this is cool!

Now, pardon my ignorant question (I'm no electrical engineer), but these speckles we see in the example image...could this be because of what one might consider "broken" CCDs?

I get the image in my head of JVC saying "We've got thousands of these chips sitting around that didn't pass the quality tests for our higher end cameras, why not throw 'em in the DV line?" Seems to me all they'd have to do is interpolate the values of the noisy pixels--selected using those color sample blobs--from the ones around them. I was able to eliminate all the noticeable noise using the simple Color Replacer in Paint Shop Pro, so it must not be THAT hard, right?

The image IS going to be compressed, after all, and recorded at a lower resolution, so imperfections in the initial image might not make it through all the way...

Is this a realistic scenario?

I'm pretty sure it is not broken CCD's because the speckles change locations in every frame, although they are located in the same general area, besides whether i sample on the rising or falling edge of the clock seems to affect the quantity of speckles...so it seems to be clock related.

Juan

Gotcha.

Can't wait to see where this all leads...very exciting concept. Best of luck with your experimentation!

Juan,

Is it possible that Robert is on to something here?

I'm not saying it is bad CCD chips necessarily...

But, you aren't seeing any of this noise on the DV tape are you?
Is it all being filtered out in some way through the DV compression?

Is is possible that the noise is always there, on all DVX100s?
But, as Robert mentioned, it wouldn't matter because it's getting thrown out anyhow?

Probably not...but I figured it was worth mentioning.
You haven't seen any noise on the DV frames, right?

-Luis

I don't think that the noise is supposed to be there. Despite DV's compression ratio, it doesn't turn out a horrible picture, so a dark blue pixel will still be a dark blue pixel. And since there aren't that many extra vertical lines of resolution (what's the full res? 771x492 or something?), it can't all be interpolated away. And finally, the compression itself wouldn't cover for it because such a sharp change in contrast would be expected to be preserved by a compression scheme, not eliminated (imagine what it would do to text otherwise).

My guess is that he's got one of the higher bits loose on the CCDs' connections. If the bit is dead or intermittent then when everything lines up just right and that bit dies, the color value will drop to very low. For instance: if the color of a pixel of the sky is 1000000111 (519 decimal) and bit 10 (assuming big-endian) is flaky and happens to not make the connection on that clock cycle, then the color of the pixel would be returned as 0000000111 (7 decimal) which would return a very very dark pixel compared to what was supposed to be there.

And this makes perfect sense, since from what I have seen from the pictures, it's the very middle of the color range that's having the majority of the noise problem (and 512 is right in the middle of the color space) where you drop one bit and the color is changed dramatically.


Although, to be sure, the best thing to do would be to get another camera and try it on there as well to see if it's Juan's CCDs or if it's his method.

Jon just pointed out what has been my best theory so far...however, i am pretty sure at this point that all the connections are solid and not physically intermittent....so my best guess at this point is that the clock signal which already drives the three A/D's, is degrading because I am also driving the capture card with it...i'm going to try and make a clock-follower that syncs up to the original clock and see if that helps.

Juan

Well, I can see I'm out of my league with the noise theory, but I've got a couple other questions:

1.) Assuming that, once all is said and done, this procedure were possible on other cameras (let's say, the VX2000), how difficult is installation for a layman such as myself? Yes, yes, I know, you could tell me "You've never done anything worthwhile with your STANDARD camera, let alone with one of these fancy mods--focus on your content before you worry about your image", and you'd be right.

But just out of curiosity. Will one need a degree to do this? I mean, I've disassembled my camera several times, and have become familiar with the location of boards, screws, and the like, along with the required order of dis/reassembly, but I couldn't tell ya what chips perform which functions.

2.) What's the legal status of this project? Don't get me wrong, I see no MORAL problem here. I think this is a great idea, and am anxious to see some final results, but I worry about the ramifications of something like this should the companies catch on.

Sorta like the Linux on XBox project. I use this example 'cause I'm a videogame nerd, and I think it's analogous enough to work (keep in mind, however, that I can't remember if this scenario actually happened, or was mere speculation).

The idea was that the XBox, being essentially a mini computer, would make a perfect homegrown Linux platform, especially with its low price point. The fact that it's made by Microsoft was even more incentive for interested parties to get this done. Well, apparently someone figured it out, and in the process of telling others how to do this mod, got a cease-and-desist from MS. The explanation, as I remember it, was that while it was perfectly all right to modify the unit that you paid for, and do whatever you like to the thing, it was against the law to distribute this information to others, in spite of the fact that anyone wanting to do this still had to purchase their product to perform the modification.

Whether this was a rumor, I cannot say for sure, but I think it's worth mentioning, as you seem to be treading similar waters here.

Will this be an issue for your product?

Don't you basically just void your warranty when you open the unit up?

I'm not an expert on the legal ramifications, but this process doesn't seem that different than the BBC modification to the sound units on VX2000 and PD150's. The BBC hasn't been sued for that either. Perhaps because they're a corporation and not an individual. I don't know.

I say worry about it later. Microsoft was probably more concerned that the Xbox was being outfitted with Linux instead of Windows XP. Sort of like setting up the mayor's daughter with a convict.

The most they could conceivable get you on is a DMCA violation to circumvent copy protection (which is what MS used against the XBox Linux project). And since there's no copy protection that you're trying to circumvent, you're free to modify the equipment you legally own.

As for the actual mod... I imagine (although I can't say for certain since it's not even done let alone set in stone) it would be a piggyback chip, which either clips on or solders on. A clip on would be dead simple, you'd just have to know which chip to clip. A soldering would be harder but not impossible.

Juan,

Are you using the camera's clock to drive your chip and the capture card, or are you supplying your own to sync up and drive it? If you have your own, it could be that your clock is *slightly* out of phase and is ending up being systematically off on the important bits that result in the noise, but on in the surrounding bits (which wouldn't be subject to that nonsync).

I am using the clock already on the camera, so i guess either the clock is getting degraded somewhere, or the actual data is. However, since switching the capture card sync from rising to falling edge increases the speckles, i think it's the clock.

Ah, I see, good points. Guess it's not such a big deal after all.

<<<-- Originally posted by Isaac Brody : Don't you basically just void your warranty when you open the unit up?>>>

If you were referring to my fiddling with my camcorder, well, the warranty had expired before I did this disassembly, so there was no worry. Still risky, to be sure, but I have more curiosity than common sense.

Don't worry, though, I wouldn't do this to hardware I hadn't purchased myself; I won't be taking apart anyone else's cameras just to see what's inside. :P

Bayer filter
 

Juan, much respect to what you're doing. Keep it up!
I'm sorry if this comment gets you away from the actual problem, but could it be that the "problem" isn't really present?
The thing is, ccds transfer charges to registers far from the actual sampling locations (pixels). Unlike CCDs, CMOS censors are more suitable for getting values/sampling at each pixels but raw values from these chips still require cunning algorithms to improve the quality of the final image.
My wild guess (I am not a professional) is that Pana encoding chip has additional functionality as "retouching" facility.
Forgive me if I'm off point, just trying to help.

Steve,

Thanks for your input.

I've considered that possibility, and so far the biggest supporting evidence for it is that the speckels are very easy to get rid of with a smart median algorithm...something like using the magic wand in photoshop and then performing median on those specific pixels using the surrounding values(like a mosaic CCD).

However, i think so far there is far much more evidence to support otherwise, like the fact that the noise increases if i change the sync edge of the clock but stays in the same general areas, and the fact that i've seen the noise slightly reduced by using different grounding techhniques.

I'm keeping an open mind however.
-------
Also, to everyone else, i have a test this friday along with a robot vision project so this is why i've been disconnected, once i get done with that next week i'll back to work on this...

Just to put something else out there, i have uploaded the Photoshop CS file for the last low-speckles <g> frame i got. I think it's the best frame so far, because it was very dark to the naked eye yet it captured incredible detail in the sky and the dark areas.

This file is completely raw, i just put the layers in and i think i might've shifted them to where i thought they where aligned. If you guys want to post any of your color corrections that'd be awesome...even though this frame doesn't nearly use all of the dynamic range available.

http://expert.cc.purdue.edu/~pertierr/cap5_RAW.psd

Oh and steve is definitely right in that ~some~ processing is done to the raw frame...i'm not sure if this frame is slightly off focus, but it looks much better if you perform a Sharpen operation in PS...the color came out surprisingly good for a RAW frame.

OMG Juan...I can do stuff with that image in PS that I have only DREAMED of!!!!! PLEASE PLEASE stay on this project...I have CASH in hand waiting for you to finish it!!!



guys you gota download that image and play with it....it's AMAZING how far you can push it!!!!

ut-oh better tell Panasonic they are feeding us BAD chips!
 

Juan!!! got some news for ya! I just went outside and shot a DV test with my dvx100 VERY dark like your test.....guess what? I pushed it really hard in premiere pro color curves and it has the SAME dots yours does!!!

everyone do this and see if some cameras have dots more then others do....I think it's bad ccd's that ONLY show up when you shoot really dark and push it really hard...take a look:

http://www.dv3productions.com/uploads/dv_cap.jpg

BTW, every frame has dots in a new location in the frame....very random sometimes more dots sometimes less

more info...check this out Juan ..BOTH are INVERTED and I took the RGB curve all the way DOWN..ahh BOTH have RED GREEN and BLUE bad pixels..and they look like the same type of pixel....the DV version is just muddy and jaun's is VERY CRISP because he has NO compression....maybe????

http://www.dv3productions.com/upload...nRAW_16bit.jpg

http://www.dv3productions.com/upload...ed_dv_8bit.jpg

I hope this will help you find the answer...can you write some code that will "search and destroy" bad pixels? better yet try and expose your camera with a good light and see if the pixels go away....

here is what we get if Juan can make this MOD for our cameras work:

http://www.dv3productions.com/upload..._colorwork.jpg
http://www.dv3productions.com/upload..._colorwork.jpg

I did the same color work to both pics

here is my original image:

http://www.dv3productions.com/upload...p_original.jpg