Since 5.x all images used in website scope are not binary nodes, but links to dam:assets form the assets app. The upload possibility was removed.

Problem:
If referencing images not stored in assets there is no possibility to get image variations through the stk imaging generator of non assets.

See:
The contact component doesn't get image variations anymore, as the image is not stored in the assets workspace but directly on the contact itself (mgnl:resource sub node).

Use case:
Any content app deciding to use the DamUploadFieldDefinition in its editor (as the Contacts app does) will not be retrievable when linked to it by the image variations. The imaging model would provide according methods, but this is in many cases not applicable as you might need to extend other model classes as super.

Solution:
Add general functionality to the STKTemplatingFunction providing alike methods as the ImageModel

I added a patch, which works well.
Usage in the component script:

//Possibility 1
[#assign link = stkfn.getImageVariationLinkFromBinary(binaryNode, model)]
<img src=${link!}>

//Possibility 2
[#assign renditionName = stkfn.getRenditionName(model)]
[#assign link2 = stkfn.getImageVariationLinkFromBinary(binaryNode, renditionName)]
<img src=${link2!}>

In order for the image/binary to be resolved, the according workspace has to be added to the URI2RepositoryMapping in the server configuration (see print screen "URI2RepositoryMapping.jpg".
The mapping in the "URI2RepositoryMapping.jpg" is just an example, where I placed an image into the user node (coming from MGNLUI-3124).

Open work:

• Test cases
• Java doc