Hello,
With current LibRaw, custom IOs can be implemented by subclassing
LibRaw_abstract_datastream. But this is only available with the C++ API, the
C API only alows to open_file() or open_buffer(). In order to give the C API
more flexibility regarding IOs, I've started working on a LibRaw_proxy_datastream
class that would do IOs by calling a simple set of C callbacks provided by caller.
Initial code is here:
https://gitlab.com/tchaik/LibRaw/tree/tchaik/wip/c-datastream
I'd be happy to get your feedbacks regarding this work, and I'm especilly
intereted in knowing if you would be willing to add this to upstream LibRaw.
Thank you very much!
Martin.
Looks interesting in general,
Looks interesting in general, although I cannot imagine C-API user with own IO-callback written (usual C-API usage is embedding into other programming environment such as Python or Matlab or Delphi).
Is there a way to see diff against master branch in gitlab without logging in? Cannot find this button in 30-sec look.....
If your changes do not require patching main Libraw code, the best place to store it is Libraw-contrib repo, not the upstream (we're very careful with upstream, because after upstream import we need to support imported code; it is much better to keep it separately without any warranties)
-- Alex Tutubalin @LibRaw LLC
Thanks for your feedback.
Thanks for your feedback. Think you can access the diff here, even without being logged in:
https://gitlab.com/tchaik/LibRaw/commit/0e83b1278d8794513949ffed3f7de4a7...
My goal is to implement custom IO (using GIO, Gnome/GLib IO stack) for the RAW file loader of GEGL (Gimp new engine, which is C code). As of today, the only possibility is to use open_buffer() on a piece of memory previously populated by GIO machinery, but this requires the entire file/steam to be buffered... I can share a diff showing how the proposed LibRaw_proxy_datastream is intended to be used in my work in progress RAW loader if you want.
Thanks for the diff link.
Thanks for the diff link.
It looks like no Libraw patching required, so entire project may exists separated from libraw upstream.
So, please separate your changes from libraw source and we'll put it into https://github.com/LibRaw/LibRaw-contrib repo (contact us when you're ready)
-- Alex Tutubalin @LibRaw LLC