Yes, glad for progress as well!
That makes sense about white balance. The Fuji basecurve compresses the
highlights so much that I wasn't noticing the magenta. Tobias clued me
in that setting -1EV in exposure module is a good way to demonstrate it
again. For now the x-trans branch implements highlight clipping and
Lch. I'll look at inpaint and see if there's a good way to bring that
in as well.
On Sat, May 10, 2014, at 02:04 AM, johannes hanika wrote:
heya,
nice to see your good progress :)
one comment on highlight reconstruction. this is necessary because
sensor values are saturated at some same level and then white balance
is applied. so with wb coeffs of (2, 1, 1.8) you would get some magenta
highlight instead of white, in clipped regions. this has nothing to do
with bayer patterns at all.
-jo
On Fri, May 9, 2014 at 6:27 AM, Dan Torop <[1]d...@pnym.net> wrote:
Hello,
The X-Trans sensor branch [2]https://github.com/dtorop/darktable is
coming
along. Lots of work on demosaicing the past few days:
- Markesteijn (high quality) interpolation is better integrated and
faster. Thanks to pmjdebruijn's suggestion it now uses a Yuv-ish
perceptual colorspace rather than CIELab, which eliminates a bunch of
code. Markesteijn comes from dcraw (equivalent to '-q 2' or '-q 3'
parameters), and does seem to be a modified AHD.
- Added VNG interpolation as the standard x-trans demosaic algorithm
(it's ok quality and decent speed) -- this is also from dcraw, and the
same as dcraw's "-q 1" parameter.
Both VNG and Markesteijn now operate on floats (rather than 16-bit ints
as in the dcraw version) and use OpenMP.
Highlight reconstruction on X-Trans seems unnecessary? Regardless,
"Reconstruct in Lch" mode does now use OpenMP. The new "reconstruct
color" mode is disabled for now, though, as it's Bayer dependent.
In off-list exchanges I've heard the branch has worked with files from
X100S, X-E1, X-T1, and (after a bug fix) X-Pro 1 models. It'd be
interesting to try it on others.
An open question is whether/how to support Fuji's "Dynamic Range"
feature, and there are a bunch of ancillary things (UI/config choices,
optimizations, cacorrect module, etc.).
I'll work on waking up in time to find Darktable developesr on IRC...
Best,
Dan
On Mon, May 5, 2014, at 01:54 PM, Dan Torop wrote:
> Very glad to communicate on IRC a bit. Writing out some other
standing
> issues, but happy to bring questions back to #darktable.
>
> On Mon, May 5, 2014, at 08:28 AM, Tobias Ellinghaus wrote:
> > > - design decisions I made may be flawed, especially setting up
the
> > > UI/parameters for x-trans in the demosaic iop
> >
> > We will see ...
>
> In iop/demosaic.c, there needs to be a way to shoehorn separate Bayer
&
> X-Trans demosaic methods into dt_iop_demosaic_method_t and the UI.
For
> now Bayer methods (as always) are numbered 0 (PPG) or 1 (AMaZE) while
> X-Trans methods get a mask of 1024 and hence are 1024 (linear), 1025
> (VNG), 1026 (Markesteijn 1 pass) or 1027 (Markesteijn 3 pass). Also
for
> now in the UI there are two different comboboxes, one for Bayer, one
for
> X-Trans demosaic methods. Depending on the raw file mosaic, the
> appropriate widget gets shown.
>
> One big catch here is that in darktableconfig.xml, option
> plugins/darkroom/demosaic/quality currently defaults to "at most PPG
> (reasonable)". To be correct for X-Trans, this should say something
more
> like, "at most PPG/VNG (reasonable)". Is it worth altering something
> across all configurations just for pedantry, though?
>
> > So you based your work on libraw? I guess for the moment that is
ok. Most
> > work
> > probably went into our code I guess, so changing the input over to
> > rawspeed
> > once that supports X-Trans shouldn't be much work?
>
> Am based off of libraw for now as it can read the x-trans format (via
> its dcraw code) in recent versions. This is great, but also means a
huge
> part of the x-trans branch is an update to LibRaw 0.16.0, as the
0.14.7
> version in Darktable can't deal with x-trans. It sounds as the
rawspeed
> is working on x-trans support but it's not yet released? It should be
> easy to switch over when that happens.
>
>
-----------------------------------------------------------------------
-------
> 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
> [3]http://p.sf.net/sfu/perforce
> _______________________________________________
> darktable-devel mailing list
> [4]darktable-devel@lists.sourceforge.net
> [5]https://lists.sourceforge.net/lists/listinfo/darktable-devel
-----------------------------------------------------------------------
-------
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
[6]http://p.sf.net/sfu/perforce
_______________________________________________
darktable-devel mailing list
[7]darktable-devel@lists.sourceforge.net
[8]https://lists.sourceforge.net/lists/listinfo/darktable-devel
References
1. mailto:d...@pnym.net
2. https://github.com/dtorop/darktable
3. http://p.sf.net/sfu/perforce
4. mailto:darktable-devel@lists.sourceforge.net
5. https://lists.sourceforge.net/lists/listinfo/darktable-devel
6. http://p.sf.net/sfu/perforce
7. mailto:darktable-devel@lists.sourceforge.net
8. https://lists.sourceforge.net/lists/listinfo/darktable-devel
------------------------------------------------------------------------------
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
