Wrap a tutorial around a G'MIC command and share with it the community.
Tutorials are written in G'MIC-Markdown
; use your favorite text editor.
In tutorials, include the reference summary of the command in markdown. Here is the inclusion format:
gmic -h < *gmic command* >
Omit the angle brackets; just write the command name. The angle brackets are meta-notation.
Please include this reference summary instead of writing a summary by hand. This future-proofs the tutorial from changes in command syntax. The inclusion always tracks the command in its current form, following the G'MIC Reference
The tutorial probably involves a string of G'MIC commands. Instead of manipulating the image elsewhere and including the results in markdown, Old School style, use this notation instead:
%% sample < *a sample name* >,< *_height* >,< *gmic commands* > %%
If the commands generate the whole image procedurally, in the manner of turbulence
. < *math script* >
%% < *gmic commands* > %%
Here's a canonical example:
%% sample gmicky,220 deform 30 blur_radial 2% frame 1,1,0 %%
Which produces this:
Working with the gmicky sample image is good tutorial practice because the unadorned image is widely disseminated; people only passingly familar with G'MIC have seen it in a form unaltered by tutorial commands. This helps make obvious what a tutorial script does. This doesn't mean that a sample image must
be used. Deploy the best image that serves the tutorial. If such an image doesn't suggest itself, use gmicky or any of the other samples in sample
1. For infrequent writers
, PM grosgood
. He'll happily commit your tutorial - eventually. (He tends to drop out of sight frequently). He may also edit your tutorial for style and consistency - but just a bit. Your tutorial will
get up there. And you will be famous!
2. For more frequent writers
with a little git
savvy, clone gmic-community
and start in. From time to time make pull requests.
3. For regular contributors
Just commit. People become regular contributors when enough pull requests demonstrate they know what they're doing. That will happen sooner than not.
Command style: Terse? Full form?
Many G'MIC commands have terse forms. production scripts tend to use terse forms because script writers familiar with the language hate characters getting in the way of form. Understandable: as skills progress, abbreviation becomes the norm. However, to newcomers, production scripts look like line noise from a dropping link. Spell out the commands. Even input
, the one command with an invisible abbreviation. It may be useful to give a long form/short form on first mention:
...Use ''sample'' (sp) to insert standard sample images...
Commands have an optional hyphen -
prefix. People experienced with G'MIC hardly ever use them, but try to use them in tutorials. Newcomers are just feeling their way and this visual cue can help them read examples. Soon enough they will drop leading hyphens and nothing terrible will happen. Above all, be kind to newcomers. Remember, they need training wheels. Everyone was a newcomer once upon a time.
G'MIC is an open-source software distributed under the
CeCILL free software licenses (LGPL-like and/or
Copyrights (C) Since July 2008,
David Tschumperlé - GREYC UMR CNRS 6072, Image Team.