dcraw 9.17 behaviour inside and outside LZ

Posting rules: It shouldn't need saying, but... play nice. Please keep your discussions civil. You can disagree, just don't be disagreeable. And, of course, all of the usual stuff like no spamming. Tex adds: I'll be rigorously enforcing this as we go along. We're probably going to be a small community in a little lifeboat, so we can't have members at each others' throats. This is for the sake of the project as a whole. So when you post, pretend you're speaking in person with your very wealthy auntie who has always treated you wonderfully and currently lists you prominently in her will. I won't be tossing anyone out of the forums because we are all in this together (except spammers: immediate membership cancelation), but I'll delete suspect posts right away.

1 post / 0 new
dcraw 9.17 behaviour inside and outside LZ

Hi there,
Doug, you sent me a build of dcraw 9.17 to handle the RAF files from my X-E1, and the most cases, it works. But for a particular RAF files, it doesn't work, there is no crash of exception raised, but the image shown by LZ is like LZ tries to decode a standard Bayer matrix and not the specific Fujic x-trans.

So I made some additionnal testing. I tries to decode this RAF file by using your dcraw build, but outside LZ. I used the commande line found on the darktable web site: dcraw -v -w -o 1 -f -T DSCF2079.RAF

And, it works, the TIFF generated is correct. Finally, I came back to the RAF files LZ correctly decodes, and tries this dcraw call in a terminal and it also works. That means with your dcraw build I can succesfully decode all my RAF files, but within LZ, there is specific one which is not correctly decoded.

So, I guess this comes the way LZ uses dcraw, I can't explain why LZ works with most RAF files and not with some others.