M Monochrom (CCD) version- how many have sent the camera in for remapping?

M Monochrom (CCD) version- how many have sent the camera in for remapping?

  • I have an original M Monochrom

    Votes: 3 50.0%

  • My M Monochrom has Never had a Bad Line

    Votes: 3 50.0%

  • I sent my M Monochrom to Leica for Remapping

    Votes: 1 16.7%

  • My M Monochrom has Bad Line(s)

    Votes: 2 33.3%

  • I Found or Wrote my Own Software to Fix the Problem

    Votes: 1 16.7%
  • Total voters
    6
Sonnar Brian

Sonnar Brian

Product of the Fifties
Staff member
Local time
4:59 AM
Joined
Jan 12, 2004
Messages
19,780
View My Gallery
My M Monochrom with the new sensor developed an "underperforming line" evident at ISO 10,000. Well that was annoying. It took me one morning to write code to correct the error. I "hardwired" the code to my camera, meaning "Column 3203 row 3105", found by looking at the image in Photoshop. I'm playing with the code, want to make it find errors by itself, than apply the correction.

Sensor remapping normally means a bad line is "averaged over" by its neighbors. You lose information. If a line is completely dead, it's better than nothing. If the pixels get shifted through a "leaky cell", the values in the line are dragged down to a lower voltage, but detail is still present.

The Fortran code is written for the Open-Watcom F77 compiler, released in 2017. No Assembly required- I rewrote all of the assembly language routines to use Watcom routines. Always happy to give out source code.
 
Brian Sweeney said:
My M Monochrom with the new sensor developed an "underperforming line" evident at ISO 10,000. Well that was annoying. It took me one morning to write code to correct the error. I "hardwired" the code to my camera, meaning "Column 3203 row 3105", found by looking at the image in Photoshop. I'm playing with the code, want to make it find errors by itself, than apply the correction.

Sensor remapping normally means a bad line is "averaged over" by its neighbors. You lose information. If a line is completely dead, it's better than nothing. If the pixels get shifted through a "leaky cell", the values in the line are dragged down to a lower voltage, but detail is still present.

The Fortran code is written for the Open-Watcom F77 compiler, released in 2017. No Assembly required- I rewrote all of the assembly language routines to use Watcom routines. Always happy to give out source code.
Click to expand...


That's interesting.
By "hardwiring" you mean that you were able to upload your code to the camera itself and run it there, or does it mean something else?
 
pyeh said:
I ticked one and two, but wasn't quite sure what one meant, in that I have a M9M but it has the rustproof sensor. Does that make it original or not?
Click to expand...

I meant the CCD version, either version of the sensor. The main difference is the cover glass used, which makes no difference to the electronics.
 
rangefinderlove123 said:
That's interesting.
By "hardwiring" you mean that you were able to upload your code to the camera itself and run it there, or does it mean something else?
Click to expand...

"Hardwiring"- an old term that we old programmers use- just means the current version of my code is dedicated to my camera, will not work on others. I spent 4 hours writing code to solve the problem- and just used the address of the bad pixel as a constant. The goal is to make the program find all bad lines, write a ".inf" file, then use it to correct files afterwards. I set a threshold for changing values, so for low-ISO images- it leaves the values alone. I actually worked with a computer that had to be hardwired to solve problems, it was an Analog computer in the 1970s.

https://cameraderie.org/threads/leica-m-monochrom.37659/page-37#post-343526

New version: writing a routine to average values on each side of a column and then subtract the pixel value from this average of two pixels. You should get a bright line to locate the underperforming pixels. I use a threshold to determine if the fix needs to be applied.

I run the present version of code on the SD card when I put into the computer. At present, my code also adds a Gamma curve and translates the 14-bit values to 16-bits. Lightroom and Photoshop work with it. I fix up the DNG header and write the file with a "G" prefix, do not currently rewrite the original files. With a "just line fix", would probably give the option to fix the original file.

Had not thought of Github. The M Monochrom community is so small, I'm was planning to use Dropbox and send for the asking.

https://cameraderie.org/threads/add...mage-thinking-out-loud-and-experiments.38778/

I need to port my M8 processing code to Windows. I use an Orange filter to block blue light, leaving that channel IR only. Then boost the values to equal visible light, gives an IR Ektachrome look. The M8- no bad lines.
 
Output of "MONO1FIX.FOR", corrected bad column.

attachment.php
 

Attachments

  • C1018787.jpg
    C1018787.jpg
    157.7 KB · Views: 0
attachment.php


This is a 100% crop of the bad column. The column is not dead, but has some type of defect that caused part of the readout to be "hot" and other section to be "cold", with good pixels in between. There is structure in the bad column, it is just not uniform.

The algorithm computes a local Offset for the bad column compared with its two neighboring columns. If the offset exceeds a threshold, then the local DC offset is applied to the bad pixels. This is different from averaging over the dead line in that an attempt is made to restore uniformity to the image.

The program reads in a file "C:\MONOFIX\BADLINE.DAT". My CCD has one bad line, but I wrote the code to handle more- artificially capped at 200.

If anyone is interested, let me know. The Bad Column location has to be determined beforehand, I used Photoshop to get the column number. The program "batch processes" all files in a directory, or just one file. The Code will also convert the 14-bit DNG values to 16-bits using a Gamma curve, this is optional. "Windows Console Program".

The code works with DNG files as output by the camera, knows how to parse all the fields and preserve important information. It will not process DNG files output by Photoshop. They stuck extra stuff into the file.

At present, the program creates a new file- leaves the original DNG intact and creates a new file starting with a "C" (corrected) or "G" (Gamma corrected).

If you use "DROPBOX" or other method to let me download a DNG output by the M Monochrom, I can test the code with it- and ID the bad location.
 
"Sonnar Brian" -- we know who you are! 🙂 Apt handle though. I am truly impressed you were able to write code to correct this error. That's so far beyond my ken, I can't begin to express it.
 
KoNickon said:
"Sonnar Brian" -- we know who you are! 🙂 Apt handle though. I am truly impressed you were able to write code to correct this error. That's so far beyond my ken, I can't begin to express it.
Click to expand...

Yes same here. And 15,000 posts!

I work in hi-tech and work with hardware/software people and could never get the knack for writing code - although I can read music and follow orchestral scores. Computer code just gets too abstract for me and I get lost.

Best I can do is edit a UNIX shell .cshrc file and do minor customizations. 😎

Really impressed with your skills Brian and willingness to share. Thank you.
 
You are welcome!

I had to bring Nina's car into the shop today, I always get some great code written while waiting for the car to be serviced. This was a fun code to write, I spent the 1980s doing image processing. I started with code written in 1982.
 
ISO 10,000- full res uploaded, the "non-uniform" column shows up.

Original: Bad Column by fiftyonepointsix, on Flickr

Using program "MONO1FIX" to correct the non-uniform column.

Restored Column by fiftyonepointsix, on Flickr

ISO 5000- problem is there.

Original: Bad Column by fiftyonepointsix, on Flickr

Restored image.

Restored Column by fiftyonepointsix, on Flickr

The algorithm uses a threshold test to change the pixels that are non-uniform. Lower ISO images without the non-uniformity issue get left alone. The problem seems to disappear at lower ISO as the charge per pixel is greater, not dealing with such low values- I'm guessing. I've looked for it at low-ISO, see nothing. This is not "just averaging" over a dead column, it restores the column to be uniform with the rest of the image.
 
If it is "truly dead"- probably best to just replace it with the average of the nearest neighbors. If it electronically noisy- probably the same.

If the Pixel value is "corrupt" digitally, meaning a bit got stuck or set to zero, you can go into the image, determine that the value exceeds the point source response of the system, then flip bits to determine the best fit to the image. At that point: the image is restored. That is what my code did in 1982 for a custom made digital IR sensor. I've seen some images coming out of cameras with similar errors.
 
GAMMA by fiftyonepointsix, on Flickr

The second function the code does is to optionally add a Gamma curve, using a generated lookup table. I use "Curve 3" normally.

100% crop of the original image, shadow area:

L1005046_100crop by fiftyonepointsix, on Flickr

Output after applying a Gamma curve to boost shadow. I also change the "Black Level" value of the DNG file, and set white to 65535, use all the bits- not just 14-bits.

G5046_100crop by fiftyonepointsix, on Flickr

L1005046 by fiftyonepointsix, on Flickr

G5046 by fiftyonepointsix, on Flickr
 
You must log in or register to reply here.
Back
Top Bottom