Actually, scratch that, I somehow screwed up the first bisect. I went
back and took another crack at it and found that the offending revision
is actually c8d47ad9c466e6469f518f6826f18b1d9941c65e, which makes sense
because it updates the Rawspeed version. Then I went back and tested
different revisions in the RawSpeed repo with that same DT rev, and it
looks like the revision that broke Credo 40 reading is
65cc3c5e0ccce9bc87c3e80703c7c55e8466c587. I'm not sure exactly how,
because all it seems to have done is split the IIQ decoder out into a
separate module, but the one before that is the last one that will read
my RAW files. I'll add a bug to the RawSpeed tracker for that one
On 11/26/2017 06:42 PM, Robert Bieber wrote:
On that second point, I went ahead and git bisected and it seems like
the problem revision was ff4e77b0ad6e81ca1ced129b465d14730b5338fa. As
near as I can tell this has absolutely nothing to do with anything
that should affect camera support, so I'm assuming that the actual
problem is the revision of rawspeed that it uses, but I'm not really
familiar enough with git submodules to be able to figure out which
rawspeed revision that corresponds to. Hopefully folks more familiar
with the project can figure that out.
On 11/26/2017 05:22 PM, Robert Bieber wrote:
I got my hands on a Leaf Credo 40 digital back a few weeks ago, and
so far it's mostly worked stunningly with Darktable. I have noticed,
however, that in some images, particularly those with bright skies in
the background, I'm getting a noticeable centerfold effect between
the left and right half of the sensor. Here's an example of a RAW
file and XMP file that produce the effect in both the build of
Darktable I've been using (2.3.0+455~g55904ce36) as well as the
current release version 2.2.5:
https://drive.google.com/open?id=1LfP5rGfFkBBPuolZ1NzivgnbhUNX0RI0
At first I assumed this was just an artifact of the sensor and I'd
simply have to avoid those situations, but I tried processing the
same RAW file in UFRaw and couldn't get the centerfold to appear, no
matter what contortions I put the image through. So I guess this is
actually an artifact of the RAW processing, presumably a difference
between RawSpeed and DCRaw.
Does anyone have an idea what might be responsible for the
difference, and if it's something that might be easily fixable in
RawSpeed, or alternatively if there's some way I can force DT to use
dcraw as a fallback for a given image instead of RawSpeed? Or maybe
I'm just missing something and it's my own image settings that are
responsible for the seam showing up.
I also wanted to test the latest trunk build of DT to see if this had
been fixed since then, but the latest version actually seems to be
missing support for the Credo 40 (trying to click through to darkroom
mode on one of my images got me the "Couldn't read white balance
information" message that you always get with unsupported cameras).
If I get a chance in the next couple days I'll try to use git bisect
to figure out which revision broke support for it.
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to
[email protected]
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to
[email protected]
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to [email protected]
