I was thinking about taking a different approach to publishing images uploaded through our image content type. Currently we require that an image be uploaded with the correct dimensions for the page you wish to use the image and the file gets published as-is to the server via the binary template.
I was wondering if instead of publishing the raw binary file, if it would be a better approach to have our users upload the largest version of the image and only publish specific re-sized versions of that image. For instance, we use a specific image size for our right slot, landing page, and slide-show images, therefore we would publish those sizes instead of the full size image. The larger image would be available in the database in-case we need any larger sizes in the future.
Obviously this approach would require more storage space on the web server due to the increased number of photos created on the filesystem and would also increase the size of the items stored in the binary database. This image management approach seems more versatile than creating specific content types for each type of image but what are the impacts to Rhythmyx when having to index these larger images within the system?
We had a Percussion Partner (Odin Solutions) write an extension to do this for us on 6.5.2. Every image uploaded gets resized into several different width versions, with heights in proportion.
This does take up a lot of space in the backend database, especially as every new revision of an image content item, even if just the description is modified, results in a new row, containing new copies of each BLOB holding the images. And every time we modify the content type, an _BAK table is created.
Every image size has to be published, taking up space on the web server and slowing down the publishing. There is an option for the user uploading the image to not generate certain size versions, but that supposes they can know ahead of time all the contexts the images might be used in. It also means our templates have to have horrendous amounts of logic to decide what to do if the size called for in a certain context isn’t available. Even if they opt out of generating a certain size, it is still published, just a 0 byte file is created.
If you want authors of pages to be able to decide which size version to use, say inline in an Ephox EditLive field, the only interface Rhythmyx provides is to show the same image multiple times in the search results for the sys_inline_variant slot, each hardcoding into the relationship a different template, representing a different size version. This is so un-user-friendly, and so un-future-proof, that we decide not to allow our users to pick sizes. Which of course they complain about, frequently.
Another approach is to publish the original image and use one of the dynamic-resizing image servers, getting Rhythmyx to publish img tags with URLs that specify the height and width. This is most versatile, but could only be simulated in preview, and adds a lot of load to your web server.
I hadn’t really considered the _BAK tables and updates to the image that would produce another version in the database, however I have not seen any of our images get updated after they are submitted. Maybe this problem could be midigated with limiting the number of revisions for the image content type to 2.
Do you know if the larger file size in the database would affect search results within the system? I wouldn’t imagine the search engine would select the binary field within the database when querying the content type.
This is a big concern for us as we are expanding the system to publish multiple sites. Currently we publish incrementally every 10 minutes and a full publish once an hour. The full publish once an hour will be the biggest problem with implementing this type of image management, like you said each size of the image would be re-published. I am wondering if anyone else does a full site publish every hour, I thought I remembered hearing in training that some customers do a full site publish once a day. I am thinking about changing our publishing to incrementally every 10 minutes using a query from nt:base, incrementally every hour using a full content type query, and a full publish once a day. I’m not exactly sure if this is possible, I might need to open up a new thread on the specifics of publishing as there are many questions I would like to know about the different options.
I was thinking this would be available to the users by creating a snippet template for each size (right-slot, landing-page, and slide-show), the template would be named the same as the image appended file name (sample.jpg would be published as: right-slot-sample.jpg, landing-page-sample.jpg, and slide-show-sample.jpg) to enable binding variable logic to pull the correct picture size for each image. I think this would work in our situation where all sizes would be created and available but I can see how your implementation would not allow for this type of operation.
I am not familiar with a dynamic-resizing image server, I found some PHP scripts that talk about it but it is an interesting idea.
We have done some image manipulation routines for customers in the past.
There are 2 basic approaches: generate the image sizes on upload, or generate the image sizes at assembly time (e.g. publication or preview).
Generating the images at upload time gives you a bit more control. You can select which sizes are generated, and perhaps even crop the images while you resize them. However, you have to store all of the images, and they can take up lots of space (as Andrew points out). We have a few customers who are doing this: if you want particulars, send me a email.
The other alternative is to resize the image as you preview or publish it. This can be done in a Java extension. The main drawbacks are that it will take time to resize the image (so publishing will run more slowly) and that you don’t have any interactive way to control what the image looks like. If you scale an image up or down by too large a factor, it can look grainy. I don’t know of anybody actively using this approach, but it seems like it would work.
I believe re-sizing the pictures upon upload is the process I was describing earlier in the thread with one difference, not publishing the original size image to the filesystem, just keeping it in the database for future needs.
So if an image were uploaded that was 2000px by 2000px, it would be stored in the database without a binary template to publish the original, the upload transform extension would create a re-sized entry for the various sizes needed (currently 3) and be published through a binary template for each size.
We are currently using an upload resizing extension used within the EI and CI implementations that creates a basic thumbnail re-sized image from the original.
Sorry, I misunderstood. You can choose not to publish the original, if you never want to have “click to view full size version” links on your web site. What I was talking about was there is no way that you could only publish size versions as and when you need them. The pages or snippets that include the img tags can generate a location dynamically for the src attribute but, except in preview, that does not trigger the assembly of images in the required size. Each size version of each image has to be assembled and published in case it is needed somewhere. But you could generate size versions you think you may need in the future, and choose not to publish them for the time being.
You might want to investigate using JMagick, the Java interface to ImageMagick, for better quality results when resizing.