@CarVac btw: please don’t merge my PR atm. I’ll add igv and lmmse at the weekend.
Is there any interest in moving my pixelshift code to librtprocess?
I’m interested but how would it it work? Just feed in an ordered sequence of 4 pieces of raw data?
Basically you just feed in 4 raw frames. You can get them from libraw but not from rawspeed.
And then there are also some parameters you need for motion detection.
In case you use libraw, you can have a look at this code to see how to get more than the first frame from a raw file using libraw.
In RawTherapee we use our own code though…
Edit: Using libraw extracting all 4 frames should work for Pentax Pixelshift PEF files at least, as it also works for extracting all 3 frames for Pentax HDR PEF files.
Don’t know, whether libraw supports SONY Pixelshift ARQ files
Should we invite Roman to this thread?
···
On 2019-01-12 00:07, Ingo Weyrich wrote:
Basically you just feed in 4 raw frames. You can get them from libraw
but not from rawspeed.
And then there are also some parameters you need for motion detection.
@CarVac @heckflosse @agriggio
If you agree, I will try to implement RT’s “guided filter” into librtprocess, in a way that is also compatible with PhotoFlow’s chunk-based processing. We could then use it as an example for implementing other similar filters…
hi,
no need to ask for permission from me, happy hacking! 
ps. thanks for the invitation to the thread, but I have no idea whether I’ll be able to come to lgm. there’s a small chance but that’s it…
I’m in favor, but as we start adding things we need to make sure to be documenting them.
Is this a generic guided filter or is it using the image itself as the guidance?
What is it good for? How do you use it (function arguments-wise)? What is it not good for?
With a bit of luck, tomorrow evening there will be also lmmse and dual-demosaic in my pr
Currently there are this new to librtprocess demosaicers in my pr:
igv
dcb
rcd
vng4
xtrans-fast
I also simplified the api a bit, though still not completely C conform as I have some problems to callback from C code to a C++ member function for the progress indicator…
When addition of above mentioned demosaicers is completed, I would like to work on the interface to make a simple C interface before new stuff is added.
One point we should discuss are the push rights for librtprocess. Currently only @CarVac has push rights, though 80% of the contributions are from me. This is not an ideal solution imho. Maybe giving push rights to me and @Carmelo_DrRaw would not be the worst idea…
I don’t mind, but every time before I pull I verify that things are working with Filmulator and RawTherapee still.
We should set up some CI to ensure that things don’t break in the various programs that will depend on it.
I can help on that. The idea would be to build and deploy AppImage and win64 packages, so that people can also easily test the experimental versions. What do you think?
I have everything already set up for RT and PhF…
Great! I woould still work on separate branches then. That would also allow others with push access to make modifcations to that branches.
Ideally, I would create for example dual_demosaic branch, include dual_demosaic, make the modifications for the rt branch and test. Then @Carmelo_DrRaw can integrate the roi stuff he needs and test with photoflow and so on… until it’s ready to merge.
As it’s now, we have to merge stuff before it’s complete or give push access to forks…
we can reuse what we have set up for darktable already. It builds for
multiple distros.
was actually considering also adding builds for exiv2 and lensfun so we
learn early if they break their APIs
(which both just did recently)
should we just have it as one big joint project with all the involved
projects?
···
On 2019-01-13 01:07, CarVac wrote:
I don’t mind, but every time before I pull I verify that things are
working with Filmulator and RawTherapee still.We should set up some CI to ensure that things don’t break in the
various programs that will depend on it.
–
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
I pushed lmmse and a bit more to my pr:
Edit: I removed the librtprocess namespace from the interface, means you have to remove librtprocess:: in the callers
1 Like
Why remove the namespace?
Because there is no namespace support in plain C
One thing I forgot to mention. Currently, lmmse has a silent fallback to igv in case it cant get the memory it needs (lmmse needs a lot of memory). Maybe we should add a flag to control the fallback…
why not bubble up the error to the caller and let it choose the fallback?