Page Images/Renditions about acs-aem-commons

[justinedelson]

If the desired behavior is to have multiple images for a page, then I'd just suggest having multiple tabs in the Page Properties dialog and there's nothing to be done here :)

If, however, the desired behavior is to have a single image with multiple crops defined on it (and to have those crops given semantically meaningful names), then I think the best solution is to have a "MultiCropHtml5SmartImage" (holy long name batman!) widget and then some kind of servlet to handle the image serving, i.e. .widescreen.mimg.png (mimg = multiple image, widescreen = crop name)

[davidjgonzalez]

My real-life use case used the same Image for all representations. The trick w/ the cropping is allowing authors to select crop areas (auto-crop rarely provides the best aesthetic) and to provide them feedback on the "final" resulting image for the rendition (they could crop down smaller than the rendition size uses which causes the image to get stretched). The MultiCropHtml5SmartImage was basically what we did, but ended up creating a dialog with multiple "normal" html5smartimage widgets, each w a preset crop size and they stored their transforms to discrete nodes (whose resource type applied those transforms to the parent jcr:content/image Image).

It felt very "clunky" to setup .. moving to a custom xtype probably would alleviate the configuration pain.

[don-yan]

Seems like cropping should be taken care of at the DAM level, so why not use renditions here?

[davidjgonzalez]

@ykisen DAM rendition cropping is brittle and very hard to maintain the aesthetic. The entire point of the image component is it allows simple, authorable renditions of an Image. To crop images in the DAM, you either crop the source image using the UI tooling (undesirable since now it effects ALL) or you have WF that crops into rendtions but this is difficult since composition is a huge part of cropping and computers are terrible w composition. Transformation (ESP cropping) is really a human activity.

If crops are uploaded AS renditions to the DAM (cropping in Photoshop or something) then the next time the original DAM asset is replaced, all the cropped renditions will either be wiped out with new auto-gen'd OR (if these renditions arent target of auto-gen) some person will have to re-crop and re-upload.

[don-yan]

@davidjgonzalez That makes sense, but I still feel like it would make sense to centrally define asset renditions in the DAM (provided the interface were made nicer through customization). I can't imagine a scenario where an image is shared between pages, but they have different croppings. Also, if the original image asset were to be replaced in the DAM, I don't see how storing the cropping in the image node will help. I'm not saying your reasoning is wrong, just playing devils advocate as I think about this for my own purposes :)

Did you go forward with a custom MultiCropHtml5SmartImage widget approach?

[davidjgonzalez]

@ykisen ive run into this 3 times now, thus this issue :)

IME its pretty common to have a large format image for the actual page, a smaller rendition for a search result, another mid-size rendition for featuring the page, etc. I had a customer that needed up to represent a page using 10 different image aspect ratios across their site (most of the page representations being pulled in "dynamically").

Separating the asset (DAM) from the transformation (Image Component params) is exactly what makes this work. If i have a asset image of a plane and need to remove the logo on the tail due to copyright, i just have to replace my DAM asset and everything "just works" (after i blow the disp cache).

If you're fundamentally changing the image then its probably not the same image (and should be a different resource aka asset); and would require re-cropping anyhow.

Also - if you rendition everything in the DAM, what happens when a new component is added that needs a different crop? You have to re-rendition all the images in the DAM (and re-activating too!). What happens when in 2 years you dont use 4 of the rendition formats anymore .. you have legacy renditions sitting around eating disk.

At some point i really started liking the Image Component; I think its one of the more underrated features of CQ.

And lastly - no i haven't started a new widget as I loathe to write ExtJS :)

Anyhow - always appreciate different points of view! Certainly pros and cons to both!

[justinedelson]

FWIW, I think you're both right. There is both a need for the ability to do multi-cropping in the Page Properties dialog and a need to do multi-cropping (in a non-descructive fashion, although I guess any definition of "multi-cropping" is by definition non-destructive) in the DAM Admin.

@ykisen - would suggest you file a separate issue to discuss the DAM Admin enhancement.

[justinedelson]

I've started an implemenation. It kinda works.

xtype is multicrophtml5smartimage

To use it, create a child node under the cq:Widget node called multiCropConfig (node type is irrelevant, assume nt:unstructured). Under this node, create a child node for each crop you want to have. Each of these nodes needs to have at minimum a property named transferFieldName which is something like ./image/cropName, i.e. the name of the POST parameter which will store the crop name. You can also specify a toolName property to change the label from "Crop" to something more descriptive.

[don-yan]

Alright, cool. I am unable to right now, but I will take a closer look and try to offer an implementation when I have time. Thanks for your work, guys!

[davidjgonzalez]

@ykisen Last thing before we start a new thread ;)

I started on a "Named Transform Image Servlet" impl that sort of handles your use case (except you cant visually author the renditions). What it does let you do though is (HTTP) Request any Image resource (Asset, Rendition, Pages, nt:file/nt:resource, Image Component; its pretty flexible) and apply a pre-defined (or named) transform to it.

For instance you could register in the OSGi Config for the servlet:

small ~> width: 200px, rotate: 36 degrees and Crop: 0,0,100,100
medium ~> width: 500px, rotate: 36 degrees and Crop: 0,0,100,100
super ~> height: 1000px

and then apply those transformations by requesting Images like so:

GET /content/dam/cat.png.transform/medium/image.png
or
GET /content/geometrixx/en/products.transform/small/image.jpg

It doesn't solve my initial issue (authored renditions) .. but its a slightly less brittle way of using programatic renditions of Images.

If in a new design "small image rendition" width's changes to 250px, you update the OSGi Config, clear the cache and youre done. Initially i has the URIs accept the transform params but I think that is too wide open and also brittle (if /width/200px was in URI, when that use case changed youd have to update all code that used 200px to be 250px).

[davidjgonzalez]

Closing due to lack of interest