Closed gennyble closed 3 years ago
Ah, well, it seems that the other D3400%20(3:2).NEF) image works with rawlaoder
. I now see that https://raw.pixls.us/#repo with the search query being "d3400" has both a split and non-split example. While I don't exactly know what that means, it seems that the split file make rawloader angry.
How are you compiling rawloader? Panics are caught and turned into errors. If you are doing panic=abort
that's not a supported configuration. The file should probably be made to work though, unless there's something actually broken with it.
I did cargo run
and passed in the file name. The driving program I used was just the Usage example from the README.md. When I use the library for real (great library by the way! Thank you.), I'll better handle the decoding errors. I just thought I'd report the decode fail in case it was something you were trying to support.
I did some initial investigation yesterday and the error that produced the trace above is because clampbits
(might've been called clamp_bits
, I don't know) in decode/basics.rs was returning -1, but then gets cast to a u16. When I "fix" that- by making it return 0 if negative- more errors pop-up further into the decode. Don't know if this information is helpful, but I hope it's semi-useful at least.
If there are split and non-split files it's probably a different decode method that needs to be detected. I'll have a look.
If you're doing raw decoding you may also be interested in imagepipe and chimper for a raw processing pipeline and a GUI for it:
https://github.com/pedrocr/imagepipe https://github.com/pedrocr/chimper
Master should now work for you hopefully. I still need to do some regression testing to make sure I didn't break anything and then some performance work to get back what was almost certainly lost with this.
Hello! I tried the sample usage on in the readme with this%20(3:2).NEF) file from raw.pixls.us and got a panic on decode. Here's the backtrace from rawloader which looks suspiciously like an underflow: