Tag Archives: photos

Pixenate as an Extensible photo-editing solution for user-generated photo products.

One of Pixenate’s great strengths is its extensibility and the flexibility it provides to website operators. Pixenate is designed first-and-foremost with photo-merchandising in mind. If you own or operate a photo-merchandising website, you know that the process of acquiring and processing user-submitted photos for use in custom products (T-Shirts, Laser etchings, etc) is fraught with peril. Every step the user takes between uploading the photo/s and turning them into custom products, can be a point at which the user just walks away. This can happen if they find the process too cumbersome or complicated or if there are simply too many steps in the process. This results in lost revenue. Streamlining the process of uploading and editing photos to simplify and reduce the number of steps necessary can really help boost revenue and convert casual visitors to paying customers.

Using Pixenate on your photo-merchandising / custom-product website can streamline the process of uploading and editing photos by combining multiple image-editing operations into a single user action. This was really brought home to me in a recent conversation with a customer who operates an online laser etching service. The customer called to talk about his service and explain what he needed. Specifically he need to be able to allow customers to crop (using a fixed aspect ratio) an uploaded photo and then for the photo to also be automatically…

  1. Re-sized to a height and width specified by the website administrator.
  2. Converted to black and white (for laser etching).
  3. Have a diffuse border added (for blending with the product’s surface).

The key requirement was that these steps should happen automatically once the user had chosen the part of the photo they wished to appear on the product. The customer’s main concern was “Can Pixenate do this?”. Because I know Pixenate like the back of my hand I was able to answer “Absolutely – Yes!”. I’m a developer and I knew Pixenate could do this and I knew how it could be done in Pixenate, but I guess I haven’t done a good job of showing just how beneficial Pixenate can be in this kind of scenario. In a nutshell, the customer wanted the process of turning user-submitted photos into laser-etched products to be as simple as possible for the user…

  1. Choose product.
  2. Upload photo.
  3. Crop photo (using a fixed aspect ratio based on product chosen).
  4. Preview end product.
  5. Purchase product.

The difficulty (as the customer saw it) was the work required for steps 3 + 4 since the photo would need to go through some additional processing (conversion to black & white, resizing, diffuse border added) before it could be previewed. It turns out these are exactly the tasks Pixenate does well.
The number one request I hear from customers is (paraphrasing)

“We’d like to combine many of the tools seen at http://pixenate.com/ into a single user task.”

For photo-merchandisers, simplifying the image-editing process is really important – too many options, too many features and the user might never get to purchasing the product. Streamline the editing process, making most of the editing tasks happen automatically and you end up with happy customers who’ve turned their cherished photos into something tangible – something more than pixels on a screen – without having to spend hours laboring in Photoshop.

I hope I’ve gone some way towards explaing what Pixenate can do. Now here comes the science bit…

Pixenate’s API is well documented. There’s an API Reference and Customization Guide with plenty of example code. I didn’t realise until recently that I didn’t have a working example of how to combine more than one image-editing operation into a single user task so I’ve set about doing just that.
Essentially the customer wanted to know if pixenate could turn the photo on the left into the photo on the right in a single step.
You can see a working example of this functionality by clicking here. (By the way – I strongly encourage you to view the source for that web page – you might be surprised by just how little there is)
This is achieved using the PXN8.tool.startTransaction() and PXN8.tools.endTransaction() methods which allow web developers to easily combine multiple image-editing operations into a single atomic user operation. When the user clicks the ‘Crop & Prepare’ button in that example page a prepareImage() function is called…

function prepareImage()
    // combine more than one image-editing operation into a single user operation.
    // [1] crop (user-selected area)
    // [2] resize
    // [3] convert to grayscale
    // [4] add a nice mask (soft edges - this can be changed by supplying a different mask image)
    PXN8.tools.mask({filepath: "images/overlays/feathered_mask.jpg",background_color: "#ffffff"});
    // complete transaction (commit changes)
    // turn off selection

The above JavaScript function performs 4 different image-editing tasks which are bracketed with by PXN8.tools.startTransaction() and PXN8.tools.endTransaction() methods which form the bookends turning all of the tasks between into a single atomic image-editing task.
It’s all well and good providing an API Reference but sometimes working example code is just what you need to dispel those last lingering doubts about what can and can’t be done with Pixenate.

p.s. If you have suggestions for improving the example please leave a comment.

Tagged , , , , , , , ,

Pixenate, Virtual Directories and Secure websites.

I’ve spent some time recently troubleshooting an issue a customer was having with Pixenate. The problem hadn’t arisen before, but thinking about it, it’s a problem which might arise in the future so I think it’s worth blogging about and documenting in the official documentation.

The customer was using Microsoft’s IIS web server and had setup a virtual directory for all photographic images – a perfectly reasonable and sensible setup. The photos resided on an entirely different machine and used IIS’s virtual directory feature to map from a URL to the remote machine. Everything seemed to work fine until they switched over to their production machine which was using HTTPS instead of HTTP. The images would load OK but when users tried to change the photos, Pixenate would complain with an error. The problem was due to a combination of using HTTPS and Virtual directories. Fortunately there is a workaround. A long time ago I added a facility to Pixenate to allow customers to implement their own custom image-loading (say for loading images from BLOBs stored in a database for example) . It wasn’t until recently that it found a use…

Pixenate’s default behavior assumes that there is a simple mapping of URL to file-system path. E.g. If the IIS DocumentRoot is at


…and if an image can be accessed via the following url…

… then the file resides on the file system at C:\InetPub\wwwroot\images\abc.jpg , and Pixenate can be initialized by calling…



PXN8.initialize( { url: “/images/abc.jpg” } );

…or even…

PXN8.initialize( { url: “/images/abc.jpg” , filepath: “../images/abc.jpg” } );

(this last example assumes pixenate has been installed at C:\InetPub\wwwroot\pixenate – see PXN8.initialize() in the API reference.)

Why would you want to use the last example? Well imagine your photos are served from a secure site ( one which uses https instead of http ). In this scenario, the most common PXN8.initialize(“/images/abc.jpg”); will still work because Pixenate will try to load the C:\InetPub\wwwroot\images\abc.jpg file if it exists.

If a Virtual directory was in use so that /images/ actually pointed to D:\images , Pixenate would no longer work because having tried and failed to read C:\InetPub\wwwroot\images\abc.jpg it would then try to retrieve https://localhost/images/abc.jpg using Perl’s LWP::Simple ( libwww-perl library ) and fail.

In this scenario, Pixenate must be given a back-stage pass so it can bypass https. Just how do you do this? Well the documented ‘filepath’ property won’t work because the image resides in a virtual directory which isn’t accessible from the pixenate directory (in this example, the virtual directory maps to a different disk but it could just as easily map to an entirely different computer).

The standard methods of loading Images in Pixenate (either from the filesystem on which pixenate resides or via LWP::Simple) won’t suffice if HTTPS and virtual directories are in use. This calls for some custom image loading code. Fortunately it’s possible in Pixenate to specify your own custom image loader and use that instead.

In this scenario, the Pixenate server needs to load images from the D:\images directory, and to do this you need to provide a server-side plugin…

use strict;
use Sxoop::PXN8 ':all';
# insert the following new property/line to your pixenate/config.ini file...
# VIRTUAL_IMAGE_ROOT = "D:/images/" ,
sub fetch_from_vpath
	 my ($image, $params) = @_;

		  die "The VIRTUAL_IMAGE_ROOT configuration property has not been set!\n";

	 my $path = $ENV{PIXENATE_VIRTUAL_IMAGE_ROOT} . $params->{virtual_path};

	 unless (-e $path){
		  die "File $path does not exist\n";
	 my $imrc = $image->Read($path);

	 if (is_imagick_error($imrc)){
		  die "ImageMagick cannot open file: $imrc\n";
	 return $image;
AddOperation('vpath', \&fetch_from_vpath);

Save the code above to a filename ending in .pm and copy it to the pixenate/lib/Sxoop/PXN8/plugins directory.
To use the plugin when starting pixenate use the following javascript code …

PXN8.initialize( { url: "/images/abc.jpg" , // for the web client
                   source: "vpath",          // specifies which plugin should be used for loading
                   virtual_path: "abc.jpg"  // the path used by the plugin
                  } );

This will enable you to use Pixenate on a secure server with virtual directories set up for images.
There are many possible ways of storing photos, filesystem (local or remote), database, cloud (S3) but I’m confident Pixenate is flexible enough to cope with whatever exotic permutations of the above can be thrown at it.

Tagged , , , ,