Hi Dan, thanks for the clarification -- I've changed darktable's configuration and that did indeed enable Markesteijn in darkroom mode. My reading of this configuration option was that the setting chosen there doesn't apply in 1:1 (i.e. not zoomed out) view and would use the chosen demosaic algorithm. Is that incorrect?
Cheers, Lars On Mon, 05 May 2014 13:54:20 -0500 Dan Torop <d...@pnym.net> wrote: > Hi Lars, > > Very glad to hear it's working for X-T1 files! Definitely let me know > about other problems. > > The darkroom view not using Markesteijn interpolate may result from > Darktable's default configuration? In the name of speed, darkroom view > defaults to not using the slower demosaic algorithms (e.g. Markesteijn), > though they will still run on export. This can change via adjusting the > "demosaicing for zoomed out darkroom mode" preferences in the "core > options" tab. Choosing "full (possibly slow)" will use Markesteijn (nice > at 1:1, but really slow when zoomed out). > > I just updated the xtrans2 branch to use (and set as default) dcraw's > VNG interpolation algorithm. The prior default, bilinear, is blindingly > fast but produces lots of color artifacts. VNG will be noticeably slower > (at least for now). In preferences, the middle demosaicing option, "at > most PPG" will use bilinear or VNG but never Markesteijn. Choosing > "always bilinear (fast)" is helpful for coping if the new VNG > interpolate is too slow. > > Dan > > > > On Mon, May 5, 2014, at 10:59 AM, Lars Kotthoff wrote: > > Hi Dan, > > > > first of all, thanks very much for doing this. I got an X-T1 last week > > and it's > > working beautifully with your branch! Let me know if I can be of any help > > with > > testing etc. > > > > One thing I've noticed is that changing the demosaic algorithm doesn't > > seem to > > update the image in darktable. That is, zoomed in 100%, I see the same > > kind of > > "blocky" image after switching to Markesteijn as with the fast bilinear > > algorithm. Exporting works fine (and the result looks actually the same > > as the > > OOC JPEG as far as demosaic is concerned), but the image in darktable > > doesn't > > get updated even after restarting. > > > > Cheers, > > > > Lars > > > > > > On Sat, 03 May 2014 14:05:39 -0500 > > Dan Torop <d...@pnym.net> wrote: > > > > > Hi All, > > > > > > > > > Apologies for a hiatus on x-trans work.The good news is the x-trans > > > branch works pretty well. Perhaps all too well, as I've not had urgency > > > to get back to work on it. But there are a bunch of things which still > > > need work: > > > > > > > > > > > > - the code should handle images taken with Fuji's "Dynamic Range" > > > feature -- these now come out too dark- handle the new "reconstruct > > > color" highlights algorithm > > > > > > - have heard bug reports from others, not least including issues with > > > 32 bit builds and rotated X-Pro 1 files -- am now looking into these, > > > and would be happy to hear more > > > > > > - Markesteijn demosaic operates on integer, not float, data (as it is > > > directly lifted from dcraw) -- though converting it to float would make > > > it harder to keep it in sync with any future dcraw development > > > > > > - Markesteijn demosaic also has lots of extra code from dcraw to make a > > > mid-processing conversion to Lab -- it may be possible to use extant > > > Darktable code here. > > > > > > - more optimizations (OpenMP, SSE, OpenCL) > > > > > > - cacorrect module still is disabled for x-trans sensors > > > > > > - design decisions I made may be flawed, especially setting up the > > > UI/parameters for x-trans in the demosaic iop > > > > > > > > > If there's a good time to catch any Darktable developers on IRC, it > > > would be great -- for thoughts on implementation and ideally what it > > > would take to get them useful/usable code. > > > > > > > > > If the update to LibRaw v. 0.16.0 would be of separate interest, I'm > > > happy to put it into a pull request without any x-trans code. I've > > > tested that code with both x-trans and Bayer files. The down side is > > > that to use LibRaw's new API, the code temporarily allocates 4x more > > > data per image (four uint16_t per pixel as opposed to only one in > > > current set-up). There may be a way around this, but it would require > > > either using LibRaw's C++ API or copying in and modifying a bunch of > > > LibRaw's code. As most images don't come in through LibRaw, perhaps > > > this is still a worthwhile change, and could lay the groundwork for > > > potential x-trans code? > > > > > > > > > Best, > > > > > > Dan > > > > > > > > > > > > On Wed, Feb 12, 2014, at 03:21 PM, johannes hanika wrote: > > > > > > nice! > > > > > > > > > > > > On Thu, Feb 13, 2014 at 8:54 AM, Dan Torop <[1]d...@pnym.net> wrote: > > > > > > One last commit, which drops in Frank Markesteijn's demosaic algorithm > > > > > > for x-trans sensors, as taken from dcraw. This needs much more work: > > > > > > it's just a wrapper for dcraw and does the processing via integers (not > > > > > > floats), plus it uses a local RGB->Lab conversion with a hard-coded > > > > > > camera matrix (rather than dt's colorspaces API). And it integrates > > > > > > awkwardly with the existing module parameters & GUI. That said, it > > > seems > > > > > > to work and produce good results (albeit very slowly). > > > > > > > > > As mentioned, I have to slow down on this for a couple weeks, but > > > wanted > > > > > > to put out there everything which I had. The commits before this one on > > > > > > the xtrans2 branch are more polished. > > > > > > > > > Best, > > > > > > Dan > > > > > > > > > > > > > > > On Tue, Feb 11, 2014, at 02:26 PM, Dan Torop wrote: > > > > Belated greetings! > > > > > > > > Things which now seem to work for x-trans images: > > > > > > > > - loading (via LibRaw 0.16.0) > > > > - bilinear demosaicing and quick downsampling > > > > - all raw-dependent modules except cacorrect (that is, highlight, > > > > temperature, hotpixels, and rawdenoise) > > > > - recognizing cameras with these sensors (and limited basecurve > > > support) > > > > > > > > To make this good: > > > > > > > > - a good demosaicing algorithm, probably a float adaptation of "Frank > > > > Markesteijn's algorithm for Fuji X-Trans sensors" from dcraw, maybe > > > VNG > > > > (which is much faster, but noticeably worse) > > > > - some code optimization (OpenMP certainly, maybe SSE, perhaps > > > OpenCL) > > > > - find if there are any more Bayer-specific paths to work around > > > (though > > > > have already pored through the code for these) > > > > - more testing/bugfixes > > > > - possibly enable cacorrect module -- if its algorithm works with > > > > non-Bayer sensor patterns > > > > - using RawSpeed to load images when that code is ready > > > > - misc. tuning (things are good enough now, but could generalize > > > > histogram_step_raw and demosaic & temperature tile alignments, for > > > > example) > > > > > > > > I may be short of time until late February, but am very excited to do > > > > the rest. Meantime, the code seems surprisingly workable (even with > > > only > > > > bilinear demosaic) for viewing/processing images. > > > > > > > > As this becomes more usable, would it be helpful to consolidate these > > > > changes into a few big commits, rather than a chain of small > > > revisions? > > > > (I will be rebasing this to the current upstream master regardless.) > > > > > > > > Revised code is in the xtrans2 branch at > > > > [2]https://github.com/dtorop/darktable. > > > > > > > > It's been exciting to see some of the workings of the dt code! And to > > > > realize the wisdom of the dt developers in not rashly embarking on > > > > support for new sensors... > > > > > > > > Dan > > > > > > > > > > References > > > > > > 1. mailto:d...@pnym.net > > > 2. https://github.com/dtorop/darktable ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ darktable-devel mailing list darktable-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-devel
