contribute

Contribute!

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.

See the Pixls discussion: Instructions to help writing reference documentation for background. Writing tutorials operates in the same vein.

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, plasma or fill. < *math script* > then:

%% < *gmic commands* > %%

suffices.

Here's a canonical example:

%% sample gmicky,220 deform 30 blur_radial 2% frame 1,1,0 %%

Which produces this:

sample gmicky,220 deform 30 blur_radial 2% frame 1,1,0

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.

Share? How?

1. For infrequent writers, PM grosgood at pixls.us. 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.

A Full-Featured Open-Source Framework for Image Processing

Latest stable version: 3.4.3 Current pre-release: 3.5.0 (2024/12/20)

Contribute!

Share? How?

Command style: Terse? Full form?