Merge "Dusty Ink" and "Ink Blobs" into Single "Letterpress" Augmentation

[jboarman]

Old printing methods transfer ink from a press onto paper, essentially like a rubber stamp. The intent of 2 of our existing augmentations ("Dusty Ink" and "Ink Blobs") is to collectively create that "Letterpress" ink effect as seen in this sample image:

There are tons of potential implementations possible, so I think we should reduce the number of augmentations where it's possible to combine them around a particular intent. It also helps to name them after some well known effects such is the case for a "Letterpress" type effect.

The number and significance of the parameters passed to this combined augmentations should also be improved. There's currently more params than is rational for the typical user. Instead, we should aim to make parameters that abstract away these underlying parameters into something more user friendly.

With time, it would be nice to see other competing implementations that are more advanced and improve upon this implementation. For example, with more realistic implementations, the texturization tends to appear more in the center of letters than the edges. Instead of having a separate augmentation, however, this could be managed via a parameter that could be varied within the same augmentation at a later point in time.

TODO

• Merge "Dusty Ink" and "Ink Blobs" into a new "Letterpress" augmentation
• Make the combined augmentation parameters more user friendly

[kwcckw]

I think this should be related to generalize the function? So combining "Dusty Ink" and "Ink Blobs" to mimic the Letterpress augmentation may be actually one of them. And eventually it will be easier for the user , they may just selecting some predefined style instead of creating their own pipeline.

[kwcckw]

If we merge these 2 operations, it should be a new augmentation? Or for now we will make it a new augmentation first until we finalized on composability of the code?

[jboarman]

It might be best to wait on the composabilty refactoring that @proofconstruction is working on first. This should be a trivial change once that is completed.

[proofconstruction]

The solution to the composability problem for augmentations was staring me in the face the whole time: if you want Augmentation3 to be the composition of Augmentation1 and Augmentation2, you just need to set
Augmentation3 = AugmentationSequence([Augmentation1(), Augmentation2()])
and call Augmentation3 in the pipeline. Easy!

@jboarman Is the intent of this issue to create a new augmentation which combines Dusty Ink and Ink Blobs, and then remove those as separate augmentations?

[kwcckw]

The solution to the composability problem for augmentations was staring me in the face the whole time: if you want Augmentation3 to be the composition of Augmentation1 and Augmentation2, you just need to set
Augmentation3 = AugmentationSequence([Augmentation1(), Augmentation2()])
and call Augmentation3 in the pipeline. Easy!

Is it possible t import those augmentation in another augmentation?

For example, i need dustyink and lowinkblob in bleedthrough augmentation. What would be the best approach to do so? Import them and use them individually?

[proofconstruction]

Currently the library is not set up for augmentations to be used as normal functions in other augmentations.

The best way to use these right now is to import them, create the augmentation object, apply it with DustyInkAugmentation(p=1)(image), then get the result back from data[layer][-1].result and use that in the next augmentation. You can do this several times, and then maybe at the end of Bleedthrough you can return the AugmentationResult with metadata, maybe a string saying you used DustyInk and LowInkBlob as part of Bleedthrough. Right now we don’t use the metadata field of AugmentationResult, and I expect it will mostly be used for debugging in the future, so this should be fine.

[jboarman]

My preference is to focus our library of named augmentations around effects associated with printing, scanning, copying, faxing, etc that are more easily and naturally expressed by business people that might describe the effect they wish to see represented.

This allows us to use recognizable metaphors representing the digital effects being applied. For example, "dirty rollers" is a metaphor (or is it a metonymy? 🤔) for the effect you see when scanning a document using a well-worn scanner that has those dirty roller lines that appear on the scanned image. This effect was derived from scanned images observed in various scanned document collections.

We may indeed end up with different classes of effects that have little or no relationship to a real-world and nameable effect like "Letterpress". If we end up with such augmentations that can only yield desired metaphor-driven effects after combining with other augmentations, then we are more closely aligning ourselves with base-level "Photoshop effects" instead of higher-order real-world effects. Such lower-order effects would need a different way of organizing, such as using categories more closely resembling imgaug's use of categories, like meta, arithmetic, artistic, blend, blur, color, contrast, convolutional, geometric, etc.

So, instead of creating a catalog of lower-order effects as augmentations, I'd rather see us create a shared library of functions that can be internally applied through that common library of micro effects as pure vector functions (image vector in -> image vector out). This further reduces the ceremony and overhead of calling them when an augmentation is composed of these library functions.

Where this gets tricky is getting stuck in an analysis-paralysis loop when assessing whether an effect belongs in the shared lib or as a proper augmentation. I propose that DustyInk and LowInkBlob are not effect seen in the wild on their own and will always be combined in some fashion with each other and / or other effects to be useful.

Further, if asking a business person to describe an issue, they might say a particular problem with a document was that the printer was running low on ink. So, then, we should have an augmentation in sync with that language called a "LowInk" augmentation. From there, we could have options for printer type (inkjet, laser, etc) and options to override any defaults such as controlling whether low ink lines are randomly included or not, etc.

But, before taking on that scope of revamping all the low-ink related augmentations, I figure we should get it right with this simpler issue by first setting up a common, shared library of lower-order effects that can be internally composed within augmentations to build a more business-friendly set of higher-order augmentations.

[proofconstruction]

#31 addresses most of this issue, but I haven't done anything about the parameters yet.

To make parameters more friendly, we could refactor everything to accept keyword args, so all the optional arguments could be safely ignored in any function or augmentation call, but this is a significant undertaking. If we want to go that direction - and I think we should - I'd like to do it now before the project grows further. There is precedent for doing this in the ecosystem: Albumentations already does this.

[proofconstruction]

Letterpress is now in augraphy.augmentations and has replaced calls to Dusty Ink and Low Ink Blobs in the default pipeline.

[proofconstruction]

Finally removed Dusty Ink and Ink Blobs