Oh and as an addendum, one other thing to do:
- include dcraw's "mid-range quality" VNG demosaic (currently only have
fast but adequate bilinear and slow but good Markesteijn algorithm)
On Sat, May 3, 2014, at 02:05 PM, Dan Torop 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
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel
