I would like to invite @patdavid to this thread. Though he most likely won’t be able to contribute to the tech details of this thread, he might be able to tell us his perspective from a completely different point of view which is also very important.
are any or all of you coming to LGM next year? i think these issues here would be a perfect candidate for a face to face meeting. i think there’s very important stuff in all of this, but i’d hate to make a mess of it or do a half-arsed job of it such that in the end projects will not pick it up for a reason or another (having to include many dependencies for simple things that aren’t quite adapted to the requirements etc).
I was going to post in the general forum about the CFP for LGM coming up.
At the same time I was hoping to reserve some BoF discussions for the PIXLS folks in general (aside from a possible photography workshop from Stefan Schmitz, I think).
Should I try to reserve some BoF discussions on the LGM website for us to discuss in more detail?
“Birds of a Feather” meeting - usually a few hours breakout in our own space separate from the main events (for people coming together around a similar thing).
In Leipzig I think it was pretty awesome to be able to share a flat with everyone. It’d be awesome to do this again if everyone was willing. We should also get a head count on folks attending so we can start fundraising asap after the new year (I’ll post something about this on the general forum as well).
On this note - do you think this is something that might be a good candidate for presenting at LGM this year? @heckflosse or @hanatos have any thoughts on this?
I’m joining again the party here after the Christmas break… in fact, with the new year I would really like to make some good contribution to librtprocess. I already have a PhotoFlow branch that uses the Amaze demosaicing from librtprocess, so I can easily do tests and develop stuff.
From my point of view, a C interface would be perfectly fine. I think PhF has requirements very similar to DT, the most important one being that the library should allow to apply any provided filter to a small window in the image. Moreover, for a given destination RoI it should provide a way to compute the required input RoI. This might also depend on the filter parameters (like the radius of a gaussian blur, that determines how much border pixels are needed to compute a given RoI).
Pixel buffers can be passed as simple pointers, to avoid having complex intermediate structures. I think that a float*** (i.e. a vector of 2D matrices) could be the best way to represent all possible encodings (RGB, Lab, Grayscale, CMYK…).
Concerning the filters that I would like to see implemented, there are many, but those seem to be really important (also as building blocks for more complex ones):
Regarding the LGM meeting, since this year it will not be far from where I leave I’d really like to come, if there is some hope for funding. And having a lighting talk on PhotoFlow would be even better!