1. In a previous post, I has mentioned the existence of a "new product". Well, AccuRaw is now in a closed beta. AccuRaw isn't of course aimed at the X-Pro specifically. AccuRaw is, as its name suggests, intended to deliver technically accurate raw conversion rather than the "Hollywood colors" conversions that most current raw developers deliver by default. But one part of what AccuRaw does to to give very fined grained control over the internal operation of the demosaic process. Specifically, it has sliders that control artifact suppression in luminance and chrominance, and post-demosaic chroma filtration. So you can tune the demosaic to suit your camera, the nature of the subject, etc, rather than have the one-size-fits-all of the mainstream raw developers.

    Of course, this makes AccuRaw potentially useful to owners of camera with X-Trans sensors. So here's a quick comparison showing AccuRaw vs the other guys:

    ACR and SILKYPIX versus AccuRaw

    Just for reference, here are the various contenders from previous posts:


    Adobe Camera Raw V7.1 beta

    ACR beta 7.1  - Lots of chroma smearing, and the letters are quite desaturated.


    SILKYPIX conversion

    SILKYPIX - best of the breed so far, some chroma smearing, saturation down, resolution appears slightly reduced


    AccuRaw Beta 5: Maximum resolution settings, 400% crop


    AccuRaw Beta 5: 60% luma and chroma artifact suppression, 
    20% post demosaic filtering, 400% crop


    In the first crop, set for maximum resolution, AccuRaw gives very good results on the red letters, but has some artifacts. However, with AccuRaw, you can tune the result to what you want. The second crop shows moderate artifact suppression settings - still nowhere near as much chroma smearing as the other raw developers, but much reduced artifacts.


    31

    View comments

  2. PhotoRaw was one of the apps mentioned in an article in the New York Time's Personal Tech column entitled "The iPad as a Hand-Held Darkroom". Sadly, they didn't provide a direct link to PhotoRaw, but hey, it's still good.
    0

    Add a comment

  3. dcpTool V1.4 is out, with support for the DNG 1.4 specification, and Adobe's "V4" profiles.

    When Adobe's V4 DNG Camera Profiles (DCP files) came out, I blogged about the new fields in this post. Well, the good news is that Adobe did eventually document the new fields, and now dcpTool is updated to support them.

    For reference, the three new fields are:
    1. Exif 0xc7a4 : ProfileLookTableEncoding, which defines whether the LookTables are in linear or sRGB encoding, 
    2. Exif 0xc7a5 : BaselineExposureOffset, which allows the profile to specify an exposure offset, and
    3. Exif 0xc7a6 : DefaultBlackRender, which is a "hint" to the raw converter as to whether or not to perform black level subtraction. (Black level subtraction can interfere with LookTable operation. Not that I think that a "hint" has any place in a specification, but the Adobe folks don't agree with me on that.)
    3

    View comments


  4. Well, I wasn't expecting to come back to the topic of Fuji, the X-Pro1 and its X-Trans sensor. However, I have been putting a lot of work into the suppression of artifacts when demosaicing. A lot more work than I had intended to, but that's another story. This is for a new product that I hope to release in a few weeks time (several months later than I'd hoped). But I did stumble into a better understanding of the nature of the chroma smearing (or watercolor effect, as it has also become known). The previous posts about Demosaicing the Fuji X-Pro1 are herehere and here.

    In previous posts, I compared renderings from Adobe Camera Raw, SILKYPIX and Fuji's in-camera JPEG processing, as well as DCRAW and RPP. Finally, I compared those renderings to renderings from PhotoRaw, both in its "retail" configuration, and in modified form with post demosaic filtering. Practically, DCRAW and RPP were pretty much outclassed -- they use VNG algorithms that generate substantial zipper effects.

    In post three, I hypothesized that the chroma smearing effect that you see very visibly in the ACR conversion, and to a lesser extent in the SILKYPIX conversion, was due to filtering, possibly mean filtering post demosaic. I now think that I was probably wrong, or at least partially wrong - the effect is due to filtering, but not mean filtering post demosaic. Rather, it's as a result of filtering during the demosaic process itself.

    PhotoRaw, ACR and SILKYPIX

    Just for reference, here are the various contenders from previous posts:

    PhotoRaw 3.5.4, 400% crop

    PhotoRaw does pretty well, but has those pesky artifacts on the paperclips.....

    Adobe Camera Raw V7.1 beta

    ACR beta 7.1  - Lots of chroma smearing, and the letters are quite desaturated.


    SILKYPIX conversion

    SILKYPIX - some chroma smearing, saturation down, resolution appears slightly lower than PhotoRaw or ACR


    PhotoRaw 3.5.4 plus mean filter, 5 pass, 400% crop

    The "PhotoRaw plus mean filter" showed a similar pattern of chroma smearing to SILKYPIX and ACR, but some parts didn't quite match. For both SILKYPIX and ACR, the chroma smearing is more pronounced in specific areas, e.g., in between the upper parts of the "Y", and inside the "A".


    Multipass Demosaic Algorithms

    As mentioned in the introduction, I've been working on artifact suppression for another product. Now the easiest way to suppress artifacts is not to generate them in the first place, so one of the things I looked at are demosaicing methods that have inherently low levels of chroma artifacts. There are a number of demosaicing algorithms that I'll call "multipass", for lack of a better term. The best known of these is LMMSE (see reference 1 below). LMMSE works, in simplified form, by first performing an initial demosaic in both vertical and horizontal directions, then filtering in the chroma domain, then using the filtered chromas to perform what is in effect a second higher quality demosaic. In this case, higher quality in the sense of fewer visible chroma errors, as the second demosaic is partially based on filtered chroma.

    The results of using such a algorithm in a beta version of the new product are shown below. The first crop shows the algorithm using a filter width as it would be for a conventional two by two Bayer array. The second uses exactly the same algorithm, but with double the filter width. Note that unlike the crops above, these two are unsharpened, due to limitations of the beta.



    "New Product" beta, multipass demosaic, single filter width, 400% crop, unsharpened



    "New Product" beta, multipass demosaic, double filter width, 400% crop, unsharpened

    Several thing stand out here (note - you may want to double-click on the crops to get a better view):
    • The multipass algorithm shows fewer artifacts than the "AHD class" algorithm, even with a "normal Bayer" filter width.
    • However, with a wider filter two things happen. Firstly, artifacts are reduced, as we'd expect - the X-Trans sensor has sparse colored photo sites, so its logical that we'd have to filter more heavily to get this particular algorithm to perform. Secondly, the crop starts to show the characteristic chroma smear pattern that the SILKYPIX conversion shows, as well as the slight loss of resolution and saturation that the SILKYPIX conversion shows.  In fact, the conversion starts to look uncannily like SILKYPIX, a lot more so that was the case for the mean filter I originally suspected was involved.
    • Extrapolating, you can easily see how, with an ever wider filter, ACR would generate the rendering it does.


    Conclusion

    It's highly likely that both SILKYPIX and ACR use some form of multipass algorithm, and that the chroma smearing is as a result of the need to adapt the algorithm to the sparse colored photo sites in the X-Trans sensor. ACR appears to be using a very wide filter, probably indication the whatever methods are being used in the initial and secondary demosaic are not well suited to the X-Trans sensor. Note that it's highly unlikely that either ACR or SILKYPIX are using LMMSE in anywhere near it's text book form (neither is the "New Product" beta used above, btw). The text book form depends on using color data to improve the initial green demosaic; given the X-Trans sensors relatively large number of green photo sites and low number of red or blue photo sites, that would not work well.



    References:

    1. L. Zhang and X. Wu, Color demosaicking via directional linear minimum mean square estimation, IEEE Trans. on Image Processing, vol. 14, pp. 2167-2178, Dec. 2005.
    8

    View comments

  5. Just took a look at Fuji X-Pro files using Lightroom 4.3 release candidate.

    In short, same chroma smearing problem as the previous versions. Oh dear. Again(!)

    Updated: Adobe now have improved support.


    2

    View comments

  6. Not, you're not seeing double. There was indeed a previous post titled "Lightroom 4.1 and the Fuji X-Pro - oh dear.....".  I just downloaded the latest version of Lightroom, LR 4.2 in its final release form. The chroma smearing in V4.1 is still there. No doubt the latest release of Camera Raw will be the same.

    Looks like fixing that issue didn't make it onto Adobe's priority list.

    Did I mention several posts ago that the Fuji X-Trans sensor really wasn't a good idea? Or at a minimum, that Fuji's handling of the X-Trans sensor's introduction has been abysmal?

    And no, really, you shouldn't be blaming Adobe for this. They have limited resources, and you can't expect Adobe to throw huge amounts of R&D time at solving a problem that Fuji created and have taken no action to resolve.  The situation may yet improve in LR 4.3; the issue may still get to the top of Adobe's priority list. But don't count on it.

    Updated: Adobe now have improved support.
    8

    View comments

  7. I haven't posted for a while - I've been busy coding. Something new in the works that should be available in a month or two.

    But I do want to quickly publish something I haven't seen documented before, which is how you can do RGB to HSV conversions in a CIFilter. HSV (Hue, Saturation, Value) representations are useful in a number of image manipulations, and CIFilters are part of Apple's image processing in OS X and iOS, and use a reduced version of the OpenGL shader language.

    In general, HSV conversion in OpenGL shader language are a problem, because of the conditionals, which shader language aren't good at. Some RGB<->HSV conversions in Open GL shader language have been published before, but all the ones I've seen use functions that aren't available in the subset of the shader language that is available in a CIFilter.

    This implementation takes some ideas about the use of the "step" function from Ian Taylor's "normal" shader language implementation.

    The CIFilter below adjusts exposure and saturation by converting to HSV, adjusting S and V, and converting back to RGB. You can test this by just pasting it into Quartz Composer. Of course, if all you want to do is to adjust exposure and saturation, there are easier ways than HSV - this is just a demo!

    Anyway, without more talk:


    /*
    A Core Image kernel routine that computes RGB<->HSV.
    As a demo, this just adjusts exposure and saturation by multiplying.
    H range is 0-6, S and V 0-1
    Alpha is preserved unchanged
    */


    vec4 HSVtoRGB(vec4 HSV)
    {
    vec4 hue;
    hue.x = abs(HSV.x - 3.0) - 1.0;
    hue.y = 2.0 - abs(HSV.x - 2.0);
    hue.z = 2.0 - abs(HSV.x - 4.0);
    return ((clamp(hue,0.0,1.0) - 1.0) * HSV.y + 1.0) * HSV.z;
    }


    vec4 RGBtoHSV(vec4 RGB)
    {
    vec4 HSV;
    float maxV = max(RGB.r, max(RGB.g, RGB.b));
    float C = maxV - min(RGB.r, min(RGB.g, RGB.b));
    float D = step(0.0, -C);

    HSV.z = maxV;
    HSV.y = C / (maxV + D);
    vec4 Delta = (maxV - RGB) / (C + D);
    Delta -= Delta.brga;
    Delta += vec4(2.0,4.0,6.0,0.0);
    Delta *= step(maxV, RGB.gbra);
    HSV.x = fract(max(Delta.r, max(Delta.g, Delta.b)) / 6.0)*6.0;
    return HSV;
    }




    kernel vec4 coreImageKernel(sampler image, float exposure, float saturation)
    {
    vec4 i;
    vec4 o;
    vec4 hsv;
    i = unpremultiply(sample(image, samplerCoord(image)));
    hsv = RGBtoHSV(i);
    // Whatever processing is required here……
    hsv.z *= exposure;
    hsv.y *= saturation;
    o = HSVtoRGB(hsv);

    // Maintain alpha
    o.a = i.a;
    return premultiply(o);
    }
    0

    Add a comment

  8. PhotoRaw 3.6 is now available on the app store. It's a big upgrade; import speeds are about twice as fast. So, for example, on an iPad 2 the image on the first page of the PhotoRaw website loads in 13 seconds, versus 26 seconds for the previous version. For those curious, the image in question was shot in a train yard close to Port Hedland, Australia.

    And no, there's no change to image quality. In fact, the demosaicing engine is exactly the same as in the previous versions, so you still get the image quality that has distinguished PhotoRaw from day one. For those interested, the changes that give the improved speed are mostly in making a lot more operations occur in parallel.

    V3.6 also brings support for the Nikon D3200.
    0

    Add a comment

  9. After my series of blog posts on the Fuji X-Pro1's sensor (here, here, here and here), Sean Reid of Reid Reviews contacted me about the posts. I've known Sean since 2007, when I was developing CornerFix at the same time that he was investigating the IR issues on the Leica M8. At the time, Sean was very helpful, supplying a number of test images for CornerFix.

    Unknown to me when I wrote the original X-Pro1 posts, Sean had been busy on an extensive comparative review of the Leica M9, Leica M Monochrom, Fuji X100 and Fuji X-Pro1 for an article called "Four Window Finder Cameras". As part of his review, Sean independently discovered a number of anomalies in the rendering of X-Pro1 images using SILKYPIX and Lightroom. After seeing my posts, Sean contacted me with some queries about my results. Following on from subsequent discussions, I've processed several of Sean's test images through PhotoRaw and various versions of "PhotoRaw Plus" for comparison purposes.

    Sean has taken those results, and put together a really comprehensive comparison of how Lightroom, SILKYPIX and PhotoRaw each render X-Pro1 images. The result is fascinating, even for me. Sean's results cover both high and low ISO images, and, among other things, delve deeply into how each program processes noise and chroma. His results confirm several of my guesses about how SILKYPIX and Lightroom are processing X-Pro1 files, but also significantly extend what we know about getting the best from the X-Pro1. (Spoiler alert: SILKYPIX isn't as good at processing X-Pro1 images as you might think!).

    Sean's site is a subscription site - Sean doesn't take advertising from anyone, and so is completely independent - but if you're thinking of buying an X-Pro1, X100, Leica M9 or Leica M Monochrom, or you already have an X-Pro1 and want to know how to get the most out of it, Sean's article is a "must read".
    14

    View comments

  10. Jason Howe has a great new article on his work with a Leica M9 and a 15mm Voigtlander Super Wide Heliar f/4.5 Aspherical. It includes his "Bridge Dynamic" image that has been selected by the Editors as a Leica Fotografie International (LFI) Master Shot, as well as full description of how he uses CornerFix.

    It's a great read with stunning images. You can find it here.
    0

    Add a comment

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