Problems with G'MIC cauldron tutorial

(Jean Pierre “Xaos52” De Schacht) #1

I am referring to this page of the tutorial

I am on Debian/sid, using latest G’MIC version from github.

Here are the results and the conclusion I have reached.
This command failed for me in the past too, which held me back then from looking into g’mic any further. Perhaps you have lost more people interested into this in the past.

Here is a detailed list of what I found.
The file is an emacs org file with the org extension replaced with txt to make the upload possible.

gmic.txt (4.1 KB)

(David Tschumperlé) #2

Yes, this is clearly related to a video output issue. I’ve tested the same script here on my Ubuntu 16.04, and it works as expected: it produces a .mov file that I can read with mplayer.
To read/write video files, G’MIC relies on OpenCV’s routines, and it seems that in your case the codec ‘MP4V’ is undefined, and unfortunately, this is the default video codec used in G’MIC.
Maybe you can try changing the codec, like this:

$ gmic 360,240,90,3 -noise[-1] 0.2,2 -bandpass 0.005,0.02 -normalize 0,255 -split z -o toto.mpg,20,MPEG 


$ file toto.mpg
toto.mpg: MPEG sequence, v1, system multiplex

(Jean Pierre “Xaos52” De Schacht) #3

Ah. Yes indeed.
The command you suggested does work for me. Thanks :slight_smile:

Perhaps you should change the command on the tutorial page to the one above, to not scare off unknowing passers by?
Up to you.


(Jean Pierre “Xaos52” De Schacht) #4

BTW running your gmic command, but with the 100x1x1x1 image as the first in the pipeline still causes a crash

me:medion:tmp/ |detached: ✓|$ gmic 100 360,240,90,3 -noise[-1] 0.2,2 -bandpass 0.005,0.02 -normalize 0,255 -split z -o toto.mpg,20,MPEG
[gmic]-0./ Start G’MIC interpreter.
[gmic]-0./ Input black image at position 0 (1 image 100x1x1x1).
[gmic]-1./ Input black image at position 1 (1 image 360x240x90x3).
[gmic]-2./ Add salt&pepper noise to image [1], with standard deviation 0.2.
[gmic]-2./ Apply bandpass filter [0.005,0.02] to images [0,1].
[gmic]-2./ Normalize images [0,1] in range [0,255].
[gmic]-2./ Split images [0,1] along the ‘z’-axis.
[gmic]-91./ Output images [0,1,2,(…),88,89,90] as mpg file ‘toto.mpg’, with 20 fps and MPEG codec.
[gmic]-91./ *** Warning *** Command ‘-output’: Cannot encode file ‘toto.mpg’ natively ([instance(91,128,0x561963c048c8)] CImgList::save_video(): File ‘toto.mpg’, unable to initialize video writer with codec ‘MPEG’.). Trying fallback function.
[gmic]-91./ *** Error *** Command ‘-o’: [instance(91,128,0x561963c048c8)] CImgList::save_ffmpeg_external(): Invalid instance dimensions for file ‘toto.mpg’.
[gmic] Command ‘-o’ has the following description:

-o: Equivalent to '-output'.

-output (+):

    Output selected images as one or several numbered file(s).
    (eq. to '-o').

    Default value: 'format_options'=(undefined).

(David Tschumperlé) #5

Ah yes, I wonder why there is the first 100 in the command line, I have to fix this :slight_smile:

(Jean Pierre “Xaos52” De Schacht) #6

Could it be that the video output takes the dimensions of the first image in the pipeline, but borks on 100x1?
Because if I place the 100 at the end of the pipeline, it works OK.

In fact, the 100 is indeed obsolete to demonstrate the cauldron effect.

(David Tschumperlé) #7

Yes, the 100 is a bug, I don’t know why it has been put here :slight_smile:

(Jean Pierre “Xaos52” De Schacht) #8

While you are at it, I recommend replacing the 900 slices by a more modest number.
In my case (a meagre 4 GB RAM), my system locks up with the 900 slices, trashing like mad. :slight_smile: