Hi.
On Mon, Nov 27, 2017 at 1:22 AM, Robert Bieber <[email protected]>
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
$ unzip centerfold_raw.zip
Archive: centerfold_raw.zip
inflating: 0047_23_46.IIQ.xmp
linking: 0047_23_46.IIQ ->
../../../.git/annex/objects/03/Gw/SHA256E-s40513597--1ef92618cc8c9c90a6c82762be3e8c66023ee8013db9551b64760d41c53fc273.IIQ/SHA256E-s40513597--1ef92618cc8c9c90a6c82762be3e8c66023ee8013db9551b64760d41c53fc273.IIQ
finishing deferred symbolic links:
0047_23_46.IIQ
Somehow i don't think that is what you wanted to upload.
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.
I'll defer from any speculations until i actually see the sample.
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?
dcraw was never ever supported/integrated.
libraw fallback was disabled for quite some time and dropped some time
ago
too.
So nope. RawSpeed is the only raw loader.
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.
On Mon, Nov 27, 2017 at 1:58 AM, Robert Bieber <[email protected]>
wrote:
I just uploaded a shot of a color chart a little while ago, not sure
how
long it'll take them to add it to the archive
Usually the time it takes me to notice the new upload, so between 10
minutes and a day :)
Validated, thanks!
On Mon, Nov 27, 2017 at 4:41 AM, Robert Bieber <[email protected]>
wrote:
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
Thanks. Should be fixed now.
This is why we have RPU :)
See https://discuss.pixls.us/t/raw-samples-wanted/5420?u=lebedevri
Roman.
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to
[email protected]
