Adding augmentations for primitive geometric operations? about augraphy

[jboarman]

This gets to the heart of how we formulate our philosophical approach to composing augmentation functionality. I believe @kwcckw had some comments that similarly touch on how we compose some fundamental augmentations.

For example, issue #11 aims to combine two fundamental augmentations into a single augmentation that has an identifiable purpose and effect. The aim of #11 is to make augmentations more user friendly to the casual user.

But, what if we want to re-use that "dusty ink" effect in some other way on another augmentation?

I propose that composition occurs in (at least) 3 different levels:

1. library of utility python functions that can be re-used between various augmentations
2. augmentations
3. pipelines

The casual Augraphy user will leverage the default pipeline. A slightly more advanced user will compose their own pipeline from available augmentations. The most advanced user will create custom augmentations in their own code that is added to a custom pipeline.

I believe there is an additional level of composability that I don't think we have approached, which is to compose pipelines using other pipelines. So, for example, perhaps there is a "Letterpress" pipeline (instead of a "Letterpress" augmentation). That pipeline might leverage dusty ink and ink blobs augmentations. Then, a pipeline might pull in the "Letterpress" pipeline as a OneOf sequence that is invoked from their own custom pipeline.

Anyhow, before we get too much further, we need to formulate a consensus opinion on how we can balance having a set of user-friendly and easily-identifiable purpose-driven augmentations vs micro augmentations that must be mixed and matched to compose a particular effect.

[kwcckw]

I propose that composition occurs in (at least) 3 different levels:

1. library of utility python functions that can be re-used between various augmentations

2. augmentations

3. pipelines

Yes, i think this is important since some augmentations may redundant to each other. Additionally, is there a better way to avoid those same redundant augmentation?
For example, in #11 , we are merging dusty ink and ink blob in ink phase, so there shouldn't be anymore dusty ink and ink blob augmentation in ink phase.

[proofconstruction]

I wrote some thoughts on future directions in #22 - in short, I think we should end up with a small set of useful augmentations to show the utility of the package (things like paper fold, ink bleed, scanner lines, etc.), but also provide easier ways to combine and extend existing features (at the different levels mentioned above), and to add new features where desired.

[jboarman]

I'm closing this issue since #25 covers at least half of the concern raised here. Topics of composition are being adequately discussed elsewhere. The mechanical deformations proposed are good ones that should be independently proposed on a per-transform basis along with examples of the expected output.