1. In a previous post I talked about Leica's delay in delivering revised firmware for the M9. Subsequent to that post, there have been some conversations both on the Leica User Forum and off of it. Here's a summary of the new information:

    Firstly, a "usually very well informed source" tell me that the reason, or at least a part of the reason, for the delay to the firmware is an entirely unrelated bug in some new functionality. Apparently this bug has been intermittent, and hard to track down, but has now been fixed.

    Separately, Daniel Kennedy ("thrice" on the LUF) is quoting Stephan Daniel as giving a delivery date in late march. The post is here.

    Finally, I think there's now a growing consensus the the root cause of the red edges is probably the sensor itself, rather than over-correction in the firmware, or lens issues, although it seems clear that lens de-centering makes the red edges worse. My guess, but it is only a guess, is that there is some kind of a problem with the registration between the microlenses, the Bayer array and the photosites themselves - remember that each of those layers is in effect a separate process step.

    But whatever the root cause is, just knowing (or assuming) that it is a sensor problem tells us that the problem won't be able to be completely solved in firmware. Some people are probably assuming that because CornerFix can effectively 100% correct the problem (given a good reference image), Leica will also be able to 100% correct the problem in firmware. Not the case, unfortunately. CornerFix solves the problem for the combination of a specific lens and camera, while Leica's firmware will have to solve the problem for any combination of lens and camera. Realistically, if this is a sensor issue, Leica is going to be able to improve situation, but not solve it entirely.  So probably for a lot of users, hopefully the majority, the new firmware will reduce the problem to the point that it effectively is solved. But probably there will still be some users that have to resort the CornerFix.

    Two questions come up. The first is whether Leica will replace the sensors in the cameras that are particularly badly affected. Predicting the future is a notoriously chancy business, but my guess is that they will try to avoid sensor replacements at all costs - "recalling" even a small number of M9s, financial impact aside, would be a blow to their ambitions in the pro market with the S2.

    The second question is whether there will be a M9.2 with a revised sensor. I would guess probably yes. I think that Leica would like the M9 platform to have as long life as possible. When will that happen? Well, redoing a sensor will take a minimum of three months, then it has to be tested, etc, etc. So I'd think late this year, early 2010.

    And then course there's the "out of left field" possibility - remember that the X1's sensor isn't from Kodak.  "Mysteriously" the X1 sensor happens to have essentially exactly the same characteristics as Nikon's D300 sensor. So an M10 with a D3x sensor? Don't count it out.......but that would require a very substantial rewrite of the M9 firmware, probably not something  Leica would like to do now. So unless Kodak can't or won't fix their current sensor, I'd expect an M9.2 with a revised Kodak sensor in the not to distant future.
    3

    View comments

  2. pcdMagic is an OS X application for converting Kodak Photo CD image files. Kodak abandonned the Photo CD format many years ago, and since then most solutions for converting the files have been just terrible - blown highlights, bad color, etc

    Last year I published pcdtojpeg, which performs basic conversion from the command line and fixes the blown highlights, etc. But pcdMagic is a different animal entirely:
    • No blown highlights - most Photo CD conversion software blows highlights. pcdMagic just doesn't.
    • Specific color profiles by film type and scanner model - e.g., Kodachome scanned by a Kodak 4000 series scanner versus color negative on a Kodak 2000 series scanner.
    • Image sharpening that's specific to Photo CD images
    • Adaptive interpolation - conventional interpolation can result in unsightly artifacts in your images; pcdMagic's adaptive interpolation avoids this.
    • Output to JPEG, TIFF or DNG. pcdMagic converts to your choice of output format, even archival level DNG files. And of course, properly color managed, so you get exactly the right color rendition when you view converted files in other applications.
    • Converts any Photo CD file. pcdMagic handles all Photo CD files at maximum resolution, even 4096 × 6144 "64Base" Photo CD Pro files and the rare "Class three compression" files that other conversion program can't convert at full resolution.
    If you have PCD format files and you want to see them looking the way they did when you took the photo, you need pcdMagic. pcdMagic doesn't convert hundreds or thousands of different image formats - it converts just one format, the Kodak Photo CD format, exactly right, giving you your images back, just like you remember them.

    You can get the details here: pcdMagic web site
    1

    View comments

  3. In some posts dating back to last year I discussed the Leica M9's by now notorious red edges problem, starting with this post. At the time, I thought, and commented to that effect on the Leica User Forum, that while Leica wouldn't be able to 100% solve the problem given manufacturing variations in both lenses and the M9, they would be able to make substantial improvements by tweaking the M9's firmware corrections. However, there's been a deafening silence out of Solms, and the silence is growing more deafening by the day - no firmware update, no statement about what the issue actually is.

    What's concerning is that its now been quite a while. CornerFix V1.3.0.0, which was capable of correcting the red edges in most cases, shipped in early Novemeber last year. CornerFixV1.3.0.4, which fixed some early bugs, and extended "most cases" to "pretty much all cases", shipped in late November. So its now nearly three months since a version of CornerFix that unambiguously nails the problem shipped, but Leica haven't got anything out of the door.

    The question is, why haven't Leica shipped a new firmware version? This is actually a major issue, and it's not as if it just impacts 50 year old lenses, or lenses from other manufacturers - it impacts the vast majority of Leica's own 18mm lens, which was introduced in past few years, as well as a good number of examples of other lenses, e.g., the 21 mm and the WATE.

    Well, I can only speculate, although it's somewhat informed speculation in the sense that I know exactly how CornerFix solves the problem. It seems to me that there are only a limited number of possible explanations:

    Explanation 1: Leica's just busy with the S2, etc.  Well, maybe. The S2 is probably Leica's view of its future. But the M9 is today's cash cow. Neglecting getting it right seems like a big risk, even if production hasn't yet caught up with demand.

    Explanation 2: The red edges just can't be fixed much better than they are now. This is the "doomsday scenario", and not a pleasant one, and certainly not one that I had considered up till recently. But there is some evidence that supports it:
    • The Kodak DCS PRO 14n suffered from what was known as the "Italian Flag" problem (green on the left, red on the right!) with some lenses. That was never solved in firmware - it took a next generation Kodak DCS with a revised sensor to solve the problem. And the M9 uses a Kodak sensor.....
    • Stephan Daniel referred in a recent interview to vignetting correction as being "more of an art than a science", which discourages me. I'd be a lot more confident if this was being described as an engineering problem. In my opinion, Leica should be viewing this as a matter of science, and statistical variations in production. Trying to make corrections by "feel" seems unlikely to result in an optimal solution, and will maybe result in no solution at all.
    • I'm starting to have a lot of trouble believing that Leica didn't know about the red edges before the M9 shipped, which in turn implies that they had ample opportunity to find a fix, if they could. What we know today, and didn't know three months ago, is that nearly all 18mm lenses show red edges. In fact, every one that I'm aware of does, and I know of at least one M9 user that tried all three that his local dealer had available. And when I specifically asked in a post on the Leica User Forum a few days ago whether anyone knew of an 18mm that didn't have red edges on the M9, nobody responded. So to believe that Leica didn't know about this, we need to believe that either the 18mm wasn't tested for vignetting, or the test was so hopeless incompetent as to miss the problem.
    Explanation 3: Red edges are a lot more difficult to fix in firmware than anyone thought. This is a more hopeful scenario, and fortunately one that we have some reason to believe might be true. The reason is the following. If you consider what computations CornerFix has to do in order to correct an image as a proxy for what the M9 firmware might have to do, the answer is very different for the M8 and M9:
    • For the M8,  a simple symmetrical radial devignette, centered on the physical center of the sensor is sufficient for CornerFix to correct any lens, up to and including the CV12 and CV15. That amounts to what is in effect a "half of a radius computation" and a look-up for every pixel.
    • For the M9,  an offset asymmetrical correction is required. What that amounts to is an (a) offset computation, (b) a full radius calculation, (c) multiple look-ups, and (d) a complex interpolation process for each pixel.
    Now Leica may be able to do something clever to simplify that process - they have the advantage of presumably knowing in detail what the root cause of the problem is, and thus having a mathematical description of what's going on, which I don't. However, two things are near certain - firstly, the M9's vignetting correction code will need a total rewrite, and secondly it will absorb far more processing power than the M8's algorithm, which also appears to be the current M9 algorithm. However, we know that the M9's processor is already heavily loaded, so unless some really efficient code gets written, the M9 may be slowed to a crawl. And writing really efficient code takes time. And there's a complication - the original code was written by Jenoptik for the M8, so its likely they will have to create any new code, or a new set of programmers will have to understand the old code.

    What happens if the M9's processor just can's handle the load, no matter how efficient the code is? Well, there a solution to that, but a solution that will be very unpopular in many quarters. Leica could simply give up on doing the corrections in-camera, and embed correction op-codes into the DNG image, using the DNG 1.3 specification. That means no processing the image pixel by pixel. However, there are two problems with that. That means the in-camera JPEGs aren't fully corrected, and that DNGs can only be processed in Adobe Lightroom or ACR. No other raw developer implements DNG 1.3 opcodes. Which will drive the Capture One enthusiast crazy, and could seriously cut into the "rich snapshot" market. And given the somewhat strained relationship between Phase One and Leica at the moment, it's not clear that Phase One would go to the trouble of writing correction code.

    So we live in hope.......

    UPDATE: Part 2 here.
    3

    View comments

  4. A very common way of providing a semi-automated method of installing Mac OS X programs is a DMG that gives the user a easy way to install your program by just dragging the application into a shortcut to the Applications folder. Below is the KeyChainDD version. The advantage of this is that once the user downloads the DMG, it will automatically open, and what to do is graphically pretty obvious.
    The problem is that actually building such a DMG isn't too obvious. Notably, it's very difficult to get the DMG configured in such a way that it always opens to the right size, and showing its icons, not a list of files. There a number of methods on the web showing various ways of doing this, but most of them are very complex. This is my (fairly) simple way, without using any exotic tools:
    1. This assumes you have an application, and a background (in e.g., PNG form) that you want displayed when your DMG is mounted. I used InkScape to build this one, based on the FireFox one.
    2. Create a new image using Disk Utility, leaving all the options at their defaults, sized such that it will contain all your files.
    3. Create a folder inside the mounted DMG and name it “background”. Drop the background PNG into this.
    4. Hide the background folder (aka rename with a leading .) - I use X-Folders to this, but you can do it from the command line as well.
    5. Drop your app into the root of the DMG.
    6. From the View menu of Finder, choose Show View Options, and customize the view to show icons only, no sideview, etc. Also switch off the toolbar in the view menu.
    7. Set the window background to picture, and use Cmd-Shift-G in combination with the full path (e.g. /Volumes/MyDisk/.background) to set your background PNG as the background for the view.
    8. Move the app icon into the right place versus the background image, changing the font size and the dimensions of the icons.
    9. Now just add a shortcut to the Application Folder, place it inside the DMG, and then position the shortcut.
    10. Do a final resize on the Window such that it is the same size of your background. Your DMG should now look as you expect.
    11. Eject the DMG, then go to Disk Utilities, select the DMG and choose “convert“, then “compression” and save again. Now the DMG is compressed (as small as possible) and made unwritable. Note that's its a really good idea to save to a different name, so that you can use the uncompressed DMG as a template for future releases, and not have to go through this whole process again.
    12. That's it

    NOTE: Unless the DMG is compressed, it will revert to the default format on opening. But in order to edit it, you have to convert it back to read/write, else changes won't stick. Keep track of what state its in, because there's no obvious way to tell.....

    If you need to create a new DMG for a subsequent release, you can just delete the old application from the uncompressed DNG, and then copy the new version of the application to the DMG.  Warning: you MUST use either command line, or something like X-Folders to delete the file, rather than move it to the trash as the Mac OS X finder will do. Using Finder will create a trash folder inside the DMG. Once you have a trash in a DMG, it's nearly impossible to get rid of, and you'll have to rebuild the whole DMG.
    14

    View comments

  5. For KeyChainDD, which is hosted on SourceForge, I'm using GIT as a repository for source code, rather than distributing the source code via distribution files, as I usually do. This post briefly documents the process I used to get GIT on SourceForge working.

    Note that this assumes that you have GIT installed on your system, and will be using the standard GIT command line, and are in your project directory.

    Here are the steps:

    Step 1: Before creating any commits,  need to identify yourself, using your SourceForge identity. The easiest way to do so is to make sure the following lines appear in a file named .gitconfig in your home directory:

    [user]
            name = Your Name Comes Here
            email = you@users.sourceforge.net



    Step 2: Tell GIT what files not to transfer into the repository - by default, every thing gets transferred. The easiest way to do this is to create a file named .gitignore in your home directory. In my case, this has the lines:

    # excludes for xCode and VC++
    build/
    Unused/
    Site/
    ScreenShots/



    Step 3.  Initialize GIT - Then you actually need to create a local repository (note that the -a in the commit isn't really necessary)

    git init
    git add .
    git status
    git commit -a -m "KeyChainDD 0.9.0.0 Initial commit"



    Step 4. Check that you now have a local repository by asking for a log:

    git log


    Step 5. Push your local repository to the SourceForge GIT repository:

    git remote add origin ssh://sandymcg@keychaindd.git.sourceforge.net/gitroot/keychaindd
    git config branch.master.remote origin
    git config branch.master.merge refs/heads/master
    git push origin master


    Step 6. Create an archive (optional):

    git archive --format=zip --prefix=KeyChainDD/ HEAD | gzip >KeyChainDD_0_9_0_0.zip
    4

    View comments

Popular Posts
Blog Archive
About Me
About Me
My Photo
Author of AccuRaw, PhotoRaw, CornerFix, pcdMagic, pcdtojpeg, dcpTool, WinDat Opener and occasional photographer....
Loading