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] > ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
