raf format causes crash, quickraw panic

[Stoppedpuma]

Test file can be found here.

thread '<unnamed>' panicked at /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/quickraw-0.1.6/src/raw/renderer.rs:60:58:
not implemented
stack backtrace:
   0:     0x55da206f6294 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h7767b02c5430d02b
   1:     0x55da1fdcd7b3 - core::fmt::write::hd9cf23088539bf85
   2:     0x55da206b5c72 - std::io::Write::write_fmt::h516df85bf7181425
   3:     0x55da206f76e2 - std::sys::backtrace::BacktraceLock::print::h5907c3622e037863
   4:     0x55da206f7542 - std::panicking::default_hook::{{closure}}::h13cd352e0714d74b
   5:     0x55da206f7c14 - std::panicking::rust_panic_with_hook::ha12d21b564771d78
   6:     0x55da206f7785 - std::panicking::begin_panic_handler::{{closure}}::h29f91f01f78dfedc
   7:     0x55da206f7719 - std::sys::backtrace::__rust_end_short_backtrace::h1e39edc6648a642b
   8:     0x55da206f770e - rust_begin_unwind
   9:     0x55da1fdcb8df - core::panicking::panic_fmt::hea12f2402e677eaa
  10:     0x55da1fdcd444 - core::panicking::panic::h1582cd2b219d28d1
  11:     0x55da20353c56 - quickraw::export::Export::export_image_data::h9a32d84f5864e212
  12:     0x55da1fc4d468 - oculante::image_loader::load_raw::h6707aa610581fe8e
  13:     0x55da1fc40754 - oculante::image_loader::open_image::h840fa31c209bf6e5
  14:     0x55da1fa6c2c7 - std::sys::backtrace::__rust_begin_short_backtrace::h77549a260b7311fc
  15:     0x55da1fa9f09b - core::ops::function::FnOnce::call_once{{vtable.shim}}::h42f95e06196e431d
  16:     0x55da206f996b - std::sys::pal::unix::thread::Thread::new::thread_start::hbed294d48a38d6d6
  17:     0x734cd94a339d - <unknown>
  18:     0x734cd952849c - <unknown>
  19:                0x0 - <unknown>
fish: Job 1, 'oculante raw-stairway.raf' terminated by signal SIGABRT (Abort)

[woelper]

This looks like it is directly coming from quickraw:

quickraw-0.1.6/src/raw/renderer.rs:60:58:
not implemented

I think this should be reported upstream. If you want to be sure, I've made a repo here which you can fork and test in isolation:
https://github.com/woelper/dng-load-error

[Stoppedpuma]

This seems to be a issue with quickraw. I'm guessing that it's due to an unsupported shooting mode, but it probably shouldn't flatout throw a panic and crash. Is this the same library that caused issues with dng being read as tiff? Because I'm able to reproduce that behaviour on the repo you linked with the file linked in the issue. I would suggest looking into rawloader to see if it can handle the majority of formats found in quickraw as a replacement (or maybe to be ran side-by-side and exclude those from quickraw which don't have complete support but do in rawloader) since quickraw doesn't seem to be maintained? At least actively that is. I'll report upstream and see if I can manage a reply as the maintainer doesn't seem to have been on GitHub in months.

[woelper]

I tried rawloader in the past, but ended up with the task of having to demosaic the image, which is not trivial. Unless we simplify that or find a different library to do that, there is significant work to do that quickraw already does. There is also more complexity such as varying bit depths and little details / quirks that each camera manufacturer does differently.