I’m just porting dual(double) demosaic to librtprocess. To do that correctly I also have to port dcb, rcd, vng4 and xtransfast demosaic to librtprocess. Any objections?
For sure not from my side!!!
No objections from me.
I am preparing some submissions for LGM, and one of them is a BOF for the community here. Do you want me to also request a BOF for a continuing face-to-face on this topic for you all?
For information: I added vng4, rcd, dcb and xtrans fast demosaic
Additional information: For vng4, the cfarray must have 4 distinct colours. Feeding 1 for both greens will fail.
I don’t see why not.
BOF: Oh very good idea yes please!
···
On Fri, 11 Jan 2019, 18:07 CarVac, noreply@discuss.pixls.us wrote:
January 11I don’t see why not.
Visit Message or reply to this email to respond to darix, patdavid, Carmelo_DrRaw, Morgan_Hardwood, CarVac, houz, heckflosse, hanatos, agriggio.
In Reply To
January 11I am preparing some submissions for LGM, and one of them is a BOF for the community here. Do you want me to also request a BOF for a continuing face-to-face on this topic for you all?
Visit Message or reply to this email to respond to darix, patdavid, Carmelo_DrRaw, Morgan_Hardwood, CarVac, houz, heckflosse, hanatos, agriggio.
To unsubscribe from these emails, click here.
1 Like
I need two things to submit:
- A good title?
- librtprocess - combining early raw processing functionality
No idea here, but just taking a sort of stab at something
- A short summary (<200 words)
- A discussion on the possibility of sharing resources between projects to provide a library system for common raw processing functionality that can help to lower the barrier of entry for participating in development of tools.
Again, just taking a stab in the dark. 
Can anyone help shed some light? I’ll do the submission from there.
How about…
Title:
librtprocess: combining efforts for early raw processing functionality
Summary:
By sharing existing code and future developer effort to create a library for common raw processing functionality, we can improve performance for all and lower the barrier of entry for developers of new raw editing tools.
1 Like
Do you mind if I put you down as a presenter or co-presenter? @heckflosse you as well? (I’m going to add @hanatos anyway because I can… 
)
I’m fine with it.
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…