[gmic]-0./ *** Warning *** File ‘/home/davido/.config/gmic/cli_update173.gmic’ is not a valid G’MIC command file.
I think you should try $ gmic -update again, this is the ‘good’ way to update. Then, check if the file $HOME/.config/gmic/cli_update173.gmic is a plain text file, and contains the string morph_stream.
If it doesn’t then it means you didn’t get the latest updates, for some strange reasons (maybe web caching…).
@David_Tschumperle found a pretty cool use for this. It works quite well for interpolating in between the frames of precipitation radar sequences. Not yet sure if I can move this into production but I’ll let you know if I can.
I don’t notice much difference in smoothness between the two in this case; I suspect greater movement between each exposure and/or a slower playback speed would show more of a difference. I’ll experiment with this further.
By adjusting the smoothing value I got much, much less unwanted star movement than when using slowmoVideo. (I was using the CPU option with slowmoVideo, not the GPU option which doesn’t seem to be available in my current system setup.)
There is one point in the morph version, shortly after 1:10, where the middle of the horizon twitches; I think this was triggered by inconsistent colours of three dodgy exposures where someone (possibly me) was shining a torch where they shouldn’t have been. For series such as this where crossfading is sufficient I’ll probably stick with the crossfading to avoid unwanted movement, but will try morphing when the combination of exposure time and playback speed result in substantial movement between “keyframes”.
With my 796 source images, using the morph option with 7 intra-frames resulted in more images (6,361) than using the crossfade option with 7 intra-frames (5,565). I’ll do some experimenting with this on a smaller number of images to see if this is consistently the case.