Next-Generation Image Machine

[joshpappas]

I discovered an incredibly cool service today that made me think of Image Machine called Cloudinary: http://cloudinary.com/

However, it seems like it's really a next-generation implementation of the idea, and I'd love to see these types of on-the-fly image manipulation features available in Image Machine. Literally, they allow just calling via URL any image at any size with various cropping methods, overlays, and effects. I see no reason why Image Machine couldn't allow us the same thing. I think this would be an awesome feature set moving forward.

[Dan - Glendale Designs]

Prior to the Image Machine, a lot of us in the Miva community relied on phpThumb which offered similar functionality and also used the GD Library. Definitely not as robust as the Cloudinary service by any means, but I remember a lot of us hoping the Image Machine would offer similar capabilities. The ability to call in specific image sizes and/or manipulations by simply specifying certain parameters in the url would solve so many pain points with Miva's overall image handling, I remember a certain level of disappointment when it was revealed that the Image Machine didn't go in this direction when it was introduced.

[joshpappas]

That's interesting. Doing a little more digging today, I discovered an open-source ASP.NET package called ImageResizer - http://imageresizing.net/. It seems to include a lot of similar functionality. I really wish we had this in Miva. I think it would really help with responsive layouts and ensuring visitors are only loading as much image data as they need for their screen.

I would also want this combined with a new way to classify and reference product image data. We currently use a main product image and alternate images, then featured customer images that are displayed on a different part of the page. This required some coding acrobatics that I know must impact the performance of the page. Heck, just moving the whole image-processing workflow server-side instead of requiring all the javascript would be nice.

[Brennan]

I've actually been playing around with the functionality internally for a few days. There are actually 2 ways to do this now with existing functionality. Depending on how this gets used, it may be something we build in and make easier to implement.

At a high level though here are some general thoughts. On any List view page (CTGY, SRCH, PLST, Related Product) the built in calls to image machine return the correct image size (based on what you specify) and should be used. The same goes on the PROD page. The only case (I can think) of where you would want different sized images than what Miva outputs would be if you wanted true responsive images where on mobile you get an optimized image just for mobile. This is functionality we do plan to support by building it into the Product List Component.

The other need for functionality like this would be to pull in a resized image in a 3rd party module such as toolkit, powersearch, etc. In these cases the need for something like this is evident, however in the long term, our goal is to build those features into Miva, so you don't need those type of modules and the ability to load the correct image size is built in.

That being said, having played around with the functionality it is pretty slick and i'm sure there are going to be very varied uses for it i'm not thinking of here.

Below is the code I used to set it up. It attempts to load the image at the dimensions you pass in. If the image exists on the server it returns it. If not, it dynamically generates it and returns it. Used incorrectly this has the ability to eat a lot of disk space, or if a spider/bot indexed the image URL and change the dimensions, it could create hundreds or thousands of images. I'll have to do some digging on how others get around these potential issues.

https://gist.github.com/bheyde/26d12...165a6bc182a79a

Also there is a JavaScript method to pull any image you want with any dimensions:

Make a call to json.mvc with the following parameters:

Session_Type=runtime
Function=Runtime_ProductImageList_Load_Product_Var iant
Product_Code=<whatever>
Variant_ID=<whatever>
Image_Sizes=pipe separated lists of dimensions, either the string “original” or WIDTHxHEIGHT

The output will be a JSON array containing URLs to the generated product images.

You would then read in the JSON and update the page accordingly.

[joshpappas]

Thanks, Brennan. That's a very interesting solution that I will save for future use.

I still think this functionality would be great as a built-in alternative to the current image machine. It could allow Miva to easily manage any image on the server (or in Miva's assigned graphics folder, at least). Even if I bulk upload via FTP, I could just call any image in the code and Miva would add it to the database and return whatever images are needed.

Plus, list view pages currently return all images assigned to products at the same dimensions. If we want to separate images by type and display them in different places at different sizes, we currently have to assign variables with the desired image sizes and call image machine again for each variation. I know we've talked about this before and it's probably not a widespread use case, but maybe more people would use that type of functionality if it were more readily available. We've seen great feedback about the way we display featured customer images on our product pages. I could see expanding on this concept to assign a "feature" image for a product that feeds a homepage hero slider for featured products or bestsellers.

Then, of course, we both already mentioned using this for responsive image dimensions. This could allow 2x sizes for high-res displays in addition to scaling back for phones, all without anything complicated in the template code. It could then be used for things like banners, hero images, and logos as well.

I think it could be extremely powerful, flexible, and user-friendly all at the same time.

[eldon99]

This looks very promising, although a little over my head as far as coding is concerned. We have a bunch of sites with the same products. We would want to use this where we can have a single graphics folder to be shared across all the stores. We are doing this now using the resize.php script and it works very well. However, we need to be able to show several images on the product page and toggle through them. The only way to do that now is to use the Image Machine, but we cannot share the images across stores. Any thoughts?

[joshpappas]

Brennan,
Sorry to resurrect a fairly old thread, but I wanted to update you on my recent working with the code you provided.

I played with that GitHub code a month or two ago and had to make a change. When loading an image into an html page I think it worked fine, but if I wanted to access an image directly, it dumped the image data as text onto the screen. To fix this, I added an HTTP header to declare the content type:

<mvt:if expr="ISNULL l.settings:productimagedatalist[1]:generatedimages[1]:image">
    <mvt:do file="g.Module_Library_DB" name="l.ok" value="GeneratedImage_FindOrInsert_Image_Dimensions( l.settings:productimagedatalist[1]:image, l.constraints[1]:width, l.constraints[1]:height, l.settings:generatedimage )" />

    <mvt:assign name="l.ok" value="file_read( '/'  $ g.Domain:mod_root $ l.settings:generatedimage:image, 'script', g.image_data )" />
<mvt:else>
        <mvt:assign name="l.ok" value="file_read( '/' $ g.Domain:mod_root $ l.settings:productimagedatalist[1]:generatedimages[1]:image, 'script', g.image_data)" />
</mvt:if>
<mvt:assign name="g.header" value="miva_output_header( 'Content-type', 'image/jpeg' )"/>
<mvt:eval expr="g.image_data" />

I had to get rid of some excess spaces as well so that wouldn't mess up the browser reading everything correctly. Took a bit of time in Fiddler to track that down.

I also don't want every image to have the same name, so I'm going to create my own rewrites to allow dynamic names and file paths that set all the parameters. This is going to be very useful in an upcoming website redesign. I'm going to try to avoid using Image Machine at all for the entire site, which should be fun.

I still think something like this should be baked into a future release. Maybe V10, since it sounds like that's where all the CMS stuff is happening.

Thanks again for the code!

Josh