Hi Developers, I've been roughing out a code path to read the new fujifilm "x-trans" sensors, mindful of http://www.darktable.org/2012/12/released-1-1-1/comment-page-1/#comment-8531. At this point I've dealt with the first step on that list only.
Notes so far: - LibRaw < 0.15 as shipped with darktable hangs in packed_load_raw() when reading x-trans files (at least those from fuji x100s). Newer LibRaw versions don't have this problem. But LibRaw >= 0.15.0 loses the "document mode" by which dt_imageio_open_raw() loads grayscale uninterpolated data (hence http://sourceforge.net/p/darktable/mailman/message/31719896/). I switched to LibRaw 0.16.0, and use rawdata.raw_image[] rather than libraw_dcraw_make_mem_image() in document mode to get equivalent data. This works for x-trans, but perhaps breaks/alters behavior with other cameras. - The dt_image_t struct needs a 6x6 lookup for x-trans filters. There also needs to be a way to detect when to use this -- I'm using an ugly hack for now. - I made a naive proof-of-concept demosaic function which just produces grayscale from x-trans sensors. A sane route may be to adapt dcraw >= 9.19's xtrans_interpolate() code to handle float data. - In develop/imageop.c, there should be x-trans-specific quick clip/zoom routines. I sketched out a bad one (which doesn't get the color right). This code will presumably not make a half-size image but a 1/3-size one (or maybe even 1/6), due to the sensor. For both this and demosaicing, I can't match DT developers' image processing skills, much less their fluency with SIMD and OpenMP. I don't think I'd touch OpenCL. To do would be: - Fix things already broken by work above. - Deal with all the other modules which touch raw data - Add per-camera support Questions for DT developers: - Do you have interest in such an x-trans sensor patch? - A potential patch could be pretty invasive -- not just requiring the LibRaw upgrade but also touching at least one data structure (dt_image_t) and requiring alternate code paths in a lot of key operations. Do you feel OK about that and/or do you have thoughts on how to mitigate this? For example, I noticed the AMaZE demosaic algorithm ended up in a separate file. I don't think the x-trans code would be that lengthy, but it's also not localized. - Are there exemplary non-x-trans raw files read via LibRaw? I should verify that they still work as before. - Advice would be great. So far I'm keeping everything in a local branch, but am happy to make a fork via github. I'm not sure if this is worth pursuing -- or if I'm the one to do so. I'm also happy to talk on #darktable IRC. Thanks, Dan ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ darktable-devel mailing list darktable-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-devel
