rawspeed: update to current develop branch
Merge branch 'master' of https://github.com/darktable-org/darktable
Fix typo.
Rename module to module_version which is clearer.
dt_image_t & filter flipping deal w/x-trans raws

- storage for the x-trans 6x6 pattern in dt_image_t as well the Bayer
  pattern
- if dt_image_t.filters (the Bayer demosaic pattern) is 9, should use
  dt_image_t.xtrans (the X-Trans demosaic pattern) instead
- dt_image_flipped_filter() is a nop for X-Trans raw files, as the
  x-trans filter will be flipped on image load
fast downsampling to demosaic x-trans images
linear demosaic for x-trans files
highlights module for x-trans
temperature iop for x-trans
hotpixels for xtrans
raw denoise for x-trans

Use per-channel nearest-neighbor interpolation rather than downsizing
the channel.
invert module for x-trans

Also flip roi_in x/y for some bayer cases and don't divide by
0xffff in bayer float case (typos?).
disable ca correct module for x-trans
x-trans camera data

- white balance presets for x100s
- measured fujifilm x100s basecurve
more demosaic tuning for x-trans

- for x-trans don't downsample if scale > 33.3%
- don't use Bayer-only edge-aware median for < 1/3 scaled exports
- hide Bayer-only options in GUI
- use OpenMP for bilinear demosaic
- disable green-matching in demosaic for x-trans
- s/xtrans_lin_interpolate_f/xtrans_lin_interpolate/
- use a bitmask to show difference between Bayer and xtrans
  dt_iop_demosaic_method_t's
- default to X-Trans or Bayer demosaicer depending on image type

Regarding the first change: for Bayer don't downsample if scale > 50%.
For x-trans, the fast down-sample works off of 3x3 sensor matrix (which
is 1/4 of whole sensor pattern), rather than 2x2 as with Bayer.
first pass at Markesteijn demosaic for x-trans

Not ready for use! For now this is pretty much the dcraw code wrapped
to work w/in demosaic module. The demosaic pipeline data is converted
to dcraw-friendly format for processing, then converted back
post-processing. The dcraw code is 16-bit integer, rather than
floating point. Provisional and slow, but still noticeably better than
bilinear. Many other pieces need clean-up (c.f. the RGB to LAB
conversion).
first pass VNG interpolate

works on ints, not floats, and no optimization, but is better default
than linear, if much slower
VNG demosaic uses floats and openmp

the dcraw code uses 16-bit ints, convert to using floats;
OpenMP makes VNG much less sluggish
Markesteijn demosaic: floats, OpenMP, & misc fixes

- use floats instead of 16-bit integers
- use OpenMP
- give up interpolation on failed malloc
- use dt's CLAMPS

Note uses OpenMP in outer loop of tile processing rather than many
nested loops. This use NUM_CPUS times more memory, but tiles are small
so this should be OK. Also use OpenMP for cielab_init (though that is
temporary code) and for expanding raw mosaic into rgb buffer.

It's possible there's a race in demosaicing on tile overlaps which would
produce noise at tile edges, but haven't observed this.
use Yuv rather than Lab in Markesteijn demosaic

Thanks to advice from Pascal de Bruijn that this will be nearly
equivalent with much less code, as the colorspace conversion is only
for determining homogenity of image across luminance and chroma.

- try ITU-R BT.2020 YPbPr conversion instead of ITU-R BT.601 as seems
  to do slightly better on specular highlights plus it's so hip and
  cutting edge
- remove spurious luminance added in when doing chroma differential,
  which was a mystery residue of CIELab
- don't need anything from common/colorspaces.h any more