A black and white dog resting beneath a blooming bush.

87/365 (or: could someone please fix Sigma Foveon DNG handling in darktable?)

—

by

stephan
in ,

Yesterday I decided to take my criminally neglected Sigma SD Quattro for a spin again. The camera and its sensor may have their share of quirks, but the results still blow me away completely.

There is really nothing comparable out there, and I sincerely hope that Sigma finds a way to resurrect the technology.

two runner ducks in a garden in front of a cottage

Unfortunately the moment I picked it up I remembered that has an annoying bug which makes handling Sigma DNG files a somewhat frustrating and needlessly complicated affair.

I have opened up an issue at the darktable issue tracker, identifying the source of the problem back when darktable was at version 4.7, roughly a year ago, but so far nothing has happened.

Screenshot of darktable showing a lot of Sigma DNG picture thumbnails in ugly yellow colour.
Sigma Foveon DNG files, as seen by darktable

So I thought, yeah, well, maybe I’ll give Sigma’s own Sigma Photo Pro another chance and simply export TIFF files which I then can continue to process in darktable.

The result of the experiment in short: No, never again.

It took me an hour to process the three images that are presented in this post.

I have seldom encountered a more sluggish, unintuitive and incompetent image processing application in all my life. Sigma Photo Pro is a cross platform nightmare. It even manages the feat of looking worse on Windows (yeah, I tried) than on a Mac despite using Microsoft’s shitty Xamarin platform (which is as I understand it now called Mono cross-platform or some shit like that).

It simply should go away and Sigma should have open-sourced the algorithms 10 years ago, which would have made their cameras a favourite amongst the OSS crowd. That’s *SO* many wasted opportunities, it could drive a man insane!

Anyway. Enough ranting.

So, erm, please, if anyone from the good darktable folks is reading this… could you maybe, well, you know, fix the bug?

Because Sigma Photo Pro is torture and I swear I’m never going to touch it again.

a man and a black and white dog sitting in front of a cottage door
Photography by Katja Kleinert

Kommentare

5 responses to “87/365 (or: could someone please fix Sigma Foveon DNG handling in darktable?)”

  1. Nielso avatar
    Nielso

    @Stephan

    Could it be a workaround to throw AdobeDNG converter at them? I'm not sure if converts from DNG to DNG though.

    My GH6 produces RW2 RAW that cannot be read by almost anything but Adobe products.

    The Windows application recommended by Panasonic is “SILKYPIX Developer Studio” and it is bad. Very bad.

    I don't understand why these camera manufacturers don't contribute to dcraw or libraw.

    1. stephan avatar
      stephan

      I’m not sure if that can work; Sigma’s DNGs are linear DNGs (because Foveon sensors have no bayer matrix; they derive colours through the different depths in which colour wavelengths penetrate the silicon).

      I’ll give it a try though. But really the simplest solution would be to fix #darktable. The source of the problem is kind of obvious. If I didn’t already have three different lives at the same time, I’d tackle it myself, but I can’t possibly make time for yet another project.

      The problem with Japanese companies is patents upon patents upon patents. I know because I worked for one. It’s hell on earth. They patent just about anything, so it’s a complicated and tangled mess to make something open source or even contribute to open source.

      (Fun fact: I once had to remove a feature from a photobook editor where we read the preview JPEG thumbnail that’s embedded in EXIF data in order to faster display it it in a grid view. And our Japanese mother company was adamant that we remove the feature because someone has a patent for reading the preview JPEG thumbnail that’s embedded in EXIF data in order to display it to the user in a grid view. That’s the extent of how bad it is. It’s a wonder that nobody has patented breathing in Japan yet)

      I’m sure there are people at Sigma who would be very much in favor of contributing to dcraw or libraw, but it’s most certainly not possible because 12 different parties have some kind of stake in the way the technology works.

      Reply
      1. Nielso avatar
        Nielso

        @Stephan

        Ah, sad story. But interesting sensor concept by Sigma/Foveon.

        Another such story is raw video data, which is basically blocked by the American company RED holding a patent on compressing raw video data that has not been debayered. The compression algorithms they use are standard, they developed none of them. So the invention in their patent is: „take sensor readout, throw standard compression at it.” Video pixel peepers go crazy at them in regular intervals.

        Apple tried to sue RED for this BS, but were not successful .

        I also should be more involved in open source contributions. Can't do the programming, but I should interact more with my Pipewire bug reports, creating the information they say they need… but I just don't find the time and energy, even though I'd like to.

        Having spent around 70 hrs on editing/mixing an album lately, I can't imagine to interweave this process with chasing bugs in audio device support. I'd just go nuts with it.

      2. Nielso avatar
        Nielso

        @Stephan

        Ah, sad story. But interesting sensor concept by Sigma/Foveon.

        Another such story is raw video data, which is basically blocked by the American company RED holding a patent on compressing raw video data that has not been debayered. The compression algorithms they use are standard, they developed none of them. So the invention in their patent is: „take sensor readout, throw standard compression at it.” Video pixel peepers go crazy at them in regular intervals.

        Apple tried to sue RED for this BS, but were not successful .

        I also should be more involved in open source contributions. Can't do the programming, but I should interact more with my Pipewire bug reports, creating the information they say they need… but I just don't find the time and energy, even though I'd like to.

        Having spent around 70 hrs on editing/mixing an album lately, I can't imagine to interweave this process with chasing bugs in audio device support. I'd just go (even more) nuts with it.

  2. 88/365 – Schall und Stille

    […] another bug in darktable 😉 But hey before anyone gets worked up about it, please please look at this first, […]

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *