On Mon, Nov 27, 2017 at 8:44 PM, Robert Bieber <[email protected]> wrote: > Whoops, I forgot about git annex. Let's try this again: > https://drive.google.com/open?id=14hjQuEqpvSEC2EDI0Fqv_Vo4qEr-Hnd8 Yep, that downloaded. However i don't know what i need to look for, so i don't see anything.
> I also skimmed through the dcraw source a bit, and I found a function called > phase_one_correct, which I suspect addresses this issue. I'm way out of my > depth trying to interpret it, but I _think_ what it's doing is applying some > correction factor(s) embedded in the file for the different separate > sections of the sensor. Yep, sounds plausible. "RobbieAB" in #darktable was looking into that, and had some success, but i did not hear back from him for some time. Roman. > On 11/27/2017 11:51 AM, Roman Lebedev wrote: >> >> 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] > ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
