...while I'd like to add, that this whole "offline" - "online" distinction seems to become more and more an obsolete style of thinking. In a similar way, as the distinction between "editing" and "compositing", or "editing" and "vfx" became more and more blurry and artificial and besides the point.

In T609#9032, @BAndiT1983 wrote:

It takes 60-70ms to decode raw array at the moment (source: https://www.apertus.org/axiom-beta-hello-world-article-may-2015).

In T609#9017, @BAndiT1983 wrote:

By the way, what's Lumiera's point of view on OpenCL or similar things? Maybe also on OpenMP?

In T609#9017, @BAndiT1983 wrote:

... there are a couple of questions that bother me for some days.

• How would Lumiera display 16bit per channel images (48bit ones)?

In T609#9017, @BAndiT1983 wrote:

...and thought about multithreaded processing and almost slapped myself on the forehead as i remembered my former processing attempt for Bayer images. I used multiple arrays, one of them was for RGGB (or similar patterns) and have done complex modulo calculations, awkward iteration and so on. But then i remembered that every thread could process a row of RG or GB (or every other combination), which would be controlled by a couple of parameters and write it to an output array. I see no problem as the threads would never write to the same position, at least if there is no mistake in the code.

...if there is some overarching state you need for processing a frame (or even multiple frames), we could go the old and proven "Handle / PImpl" route. As you probably know, you can build very nice opaque handle types on top of shared_ptr. On the API, we'd only expose the processing-Interface for the user. Thus, in order to do anything, the client needs to get such a handle instance from the OC library. Which then, opaquely, points to the state data you need internally to keep track of some stuff. And since the handle is ref-counting, clean-up works magically and airtight.

In T609#8994, @BAndiT1983 wrote:

What granularity is on your mind for the interaction between OC and Lumiera?

In T609#8994, @BAndiT1983 wrote:

I've played with Docker some time ago, but don't know how it helps to stay "portable" between Linux versions. How would it benefit Lumiera or OC?

In T599#8979, @BAndiT1983 wrote:

I would suggest that we start from a very simple base to evaluate which direction to take. Lumiera should be the master and responsible for the session, at least for now.

In T599#8979, @BAndiT1983 wrote:

• What about some sort of event system to signalize that processing is finished or would you just wait till the processing thread is done?

In T609#8980, @BAndiT1983 wrote:

I will answer on the other topic as soon as i have reflected on it. But here are two things which i would use for memory mapped IO...

In T609#8980, @BAndiT1983 wrote:

DEB packaging will be an important point, so i appreciate your offer and will refer to it some time in the future.

incidentally, while we're just at that topic: I have figured out quite well how DEB packaging works meanwhile. So I offer to help with that task, i.e. I can help with or care for getting either just that lib or OpenCine as a whole packed in a proper way for Debian and derivatives (Ubuntu, Mint, SteamOS :-D ), and I'll show you how to keep that stuff manageable.

fully agreed.

Workflow-A is a must, but is trivially suported: all it needs on the side of OpenCine is to provide some kind of "Project" or persistent "Session", i.e. something to store

• all the shots belonging together
• the settings for these shots, so they can be reproduced / tweaked later.

some notes at what IMHO would be the next steps...

to summarise some of the previous discussion: we propose the following ideal-typical workflows as point of reference for detailed analysis and planing.

Hello all!