MLV-App icon indicating copy to clipboard operation
MLV-App copied to clipboard

Make automation of some basic processing parameters by key frames.

Open bouncyball-git opened this issue 5 years ago • 9 comments

I thought about this long while ago. What if make in time automation of some basic processing parameters like exposure, light/dark range (maybe gradient stuff also) by interpolating value between keyframes (over actual frames).

I know it won't be easy but we could try :)

bouncyball-git avatar Oct 23 '18 08:10 bouncyball-git

I also thought about that. But this is indeed a monster task. First we need a kind of keyframe editor, then we need a data structure to save all those keyframes. Keyframes may be different for each parameter... and so on... One little thing could make it a little easier: there is a Qt Automation class, which does linear interpolation between 2 values on one parameter. But I think, this is the easiest thing in this task. For linear gradient this would be sooo cool 😄

masc4ii avatar Oct 23 '18 08:10 masc4ii

Yea, we could start with one parameter without key frame editor only with simple structure for now to test.

bouncyball-git avatar Oct 23 '18 08:10 bouncyball-git

It will also dramatically drop framerate. Because all matrices will be calculated for each frame within the animation. In ReceiptSettings.cpp all members should be QVector<....> and all public functions should get a frame parameter. Oh man... but then we should get the same problem as with the "Save on Quit" thing: if the code changes a parameter, it is the same as the user changes it (with the current strategy) -> nobody nows the reason for a parameter change. We would have to invent a completely new parameter input and update strategy... sh**. And if doing so, we should first implement Undo and Redo. I saw some examples in Qt which I did not understand at all... hahaha.

masc4ii avatar Oct 23 '18 08:10 masc4ii

Yeah... u r absolutely right. At least we could do key frame processing optional during playback.

bouncyball-git avatar Oct 23 '18 08:10 bouncyball-git

QVector type array also quite slow right?

bouncyball-git avatar Oct 23 '18 08:10 bouncyball-git

I really think this would be MLVApp 2.0 - This should not really be possible with current archtecture and strategy. When I started I did not think about something like this could ever happen 😄

Really better would be here to start at zero - with all our knowledge we got in the last months. Edit: and someone who really knows creating good software objects architecture...

QVector should not be slower then something else - I don't expect a problem there.

masc4ii avatar Oct 23 '18 08:10 masc4ii

and someone who really knows creating good software objects architecture...

Think it's all said already. We so many times told people on forum to join us but, alas... If someone wants job to be done he/she should do it him/herself ;)

bouncyball-git avatar Oct 23 '18 09:10 bouncyball-git

I remember dreaming of this about a year ago. Maybe for 2.0 then ;)

ilia3101 avatar Oct 23 '18 21:10 ilia3101

Nice to hear that we all have the same vision and desires :grinning:

bouncyball-git avatar Oct 24 '18 06:10 bouncyball-git