There it goes, some agresive channel leveling and now color can be noticed. The grass is green, the windshield has a blue tint. It has that purplish color of the Kodak sensors.
Interestingly enough i can see more green than on the original JPG generated with the PS plugin, I have the theory that is not using much the green channel as green channel and considering it more like a luma channel.
Did you use the pixel calculations that are in the patent? I'm not sure, when they say R or B to add or subtract whether that is the previous R or B, or the next R or B. Maybe just whichever one is closest.
Anyway, it's coming along.
I didn't. I just made each R G B layer using pixels accordingly, colored and added an adjustment level layer that with the eyedropper picked a white and a black using the same shadow or light spot for every adjustment layer.
Somewhat a proof of concept, bluring the blue and red layers I guess might help to reduce the zipper effect, also using split frequency layers and recycling the high freq layer of the G over the blurred R and B might also help to define some finer detail but that's a lot of processing for a vintage camera.
Hi,
Yes, the color was brand-new back then. The previous Kodak CCDs were all monochrome. And,.also a mono variant of this one. And several after the 100 of course. So,.while I was using Kodak CCDs in cameras at IBM back then, they were all mono. So I never had to deal with the color aspect.
This is a really cool project, BTW.
And, I know first hand about Argentine customs. I had to go there once for Ericsson to sort out cell system issues. Got tossed into jail at the airport for all those cell phones I was smuggling into the country. In a very large suitcase. Which I happily opened for the inspector. My jail time lasted a half an hour before a government higher-up came along to yank me out. I was there at their request because all the systems are government owned. The boss of airport customs couldn't understand why I just sat there reading my book. I wasn't worried because the other engineers went thru to meet the government folks meeting us. It was simply a matter of time before someone with a greater number of stars on their shoulders showed up. Ha!
Stan
Wow quite a story, and it doesn't surprise me at all knowing how everything works over here. Now i'm curious, what Ericsson stuff were you smuggling at that time? I worked till last year repairing the backhaul of a carrier and most systems were Nokia and Ericsson plus some chinese ZTE and Huawei.
Also curious... IBM used regular DCS100 mono or they had some specialty Kodaks?
If it were me, I think I would try to write a custom 3G RGB demosiacing algorithm for RawTherapee... that way you could take advantage of all the other processing options there, and not have to write any extra code.
I'm still a few steps from that, I need the camera producing a proper file first.
Still... since it's only 8 bits colors I could make some routine to create an uncompressed TIF directly from camera, some sort of lookup table I guess...
Haven't posted in a while.
I hadn't much upgrades on the last month, life got quite busy but I put some testing time on the DCS and to build an internal cache correctly in sync with the camera so I can retransmit the cached data to other device at any speed the other device needs.
To my surprise this was not an easy task and threw me on a rabbit hole chasing jittery signals.
On the journey i discovered that my wiring was a disaster and that the clock signal from the camera is extremely sensitive to noise.
On my best shot i could get a somewhat steady at start clock but rapidly decaying.
This is with the much improved wiring going over micro coax but is obvious that needs more improving.
Well this is more confusing even... the microcoax I used was completely shorted... somehow it was working without a clock signal.
How is coded it shouldn't work, it uses that clock to count horizontal pixels and when it reaches certain number the FPGA sends the required signaling to request the next line and counts up till it reach certain number and finishes and resets everything.
It is resetting with a shorted clock signal which means it is counting something from another place...
Using an internally divided clock from the FPGA works quite fine, which means the code should work...
Can be my FPGA input pin damaged?...
Aha! it was the FPGA, but it wasn't damaged, I suppose I found some weird behavior on how it handles clock signals. the trick that fixed it was to use the clock signal as a regular signal and copy that pin to an internal register of the FPGA on every clock cycle of the FPGA main clock and then use that register as the clock signal.
Time to take back where I left the code
Well my cache is now working fine but clock is still quite fiddly
The black bars should be solid, with an internally divided clock on the FPGA they are, it is good enough to know that my cache is working.
By deleting all the black in the image i can joint back the cache chunks and see that my cache is actually ok, it looks very jittery because deleting the black also deletes some of the actual pixels thus shifting the picture a little.
Oh, i've also started to learn 3d modeling to build a case for all the electronics starting with my missing shutter button.
Nice 👍
Well this 3d printing thing went really good, only needed some minor adjustments and is ergonomically a pain (a must on a DCS).
I've also managed to fix the clock issue with a not so regular approach but hey, it works now.
I have to polish my cache and is ready to the next part, the RAM.
It seems that nothing is insurmountable for you.
Bravo again!
Progress!
Looks a bit like the view from my old apartment in Brussels.
Hi everyone, I owe you an update on the state of this project.
It's actually on pause, life got quite busy and the DSU came to a difficult moment (at least for me).
The way I was caching data on the FPGA proved to be very jittery and ends up corrupting the image, so this was discarded.
I wanted to use an SPI SPRAM but this was also quite hard to implement on the FPGA. I believe the FPGA side went as far as it can, now is time for another device to take place on the data bus and store the data from the ADC.
This presents a new challenge since a new device means a new programming language, i'm moving overseas in two months so I don't have the time to learn that.
I've decided to pass the project, at least for now, to a friend.
He's more skilled on the coding stuff than me and is very passionated about the Kodaks, you can read about him on my PSA post about the caps on the NC2000 on NikonWeb.
I've also acquired another DC3 digital back that was orphaned, this is very useful since I suspect mine has a problem, the image presents a white vertical stripe and 2 of the 4 ISO settings gave me only white images. The newly acquired DC3 works even worse, it makes the camera go crazy and no image can be obtained, I suspect it needs a recap, those tantalums die quite easily.
So, right now the DCS sits dormant on a box, but when advances are made on it i'll be posting it over here.
Stay tuned
Great to hear from you, and good luck for the future. 👍