Check out my
new book!
HTML5 Games book
Photo editing in the browser with Pixastic - revisited A bit delayed, some progress has been made on the new Pixastic powered photo editor which will eventually find its way into the Mozilla Labs Ubiquity project. Here's a first preview of how the editor is going to look. It's still very alpha-ish and in a stage where I'm just trying to get something up and running, so wear your hard hats.


In very few words, the current situation is that I have an editor application running on the Pixastic library (the one featured on the Pixastic site doesn't actually use the library). There's no Ubiquity version yet (or rather, there is but it blows up every other time I run it), but I've made a test page with a few images that you can play around with.

In a lot more words, the main goals for this editor are:

Embeddable

I want it to be as easy as possible to embed into an existing page. This ties in with the goal to make accessible it via a Ubiquity command since this also means that it has to be all ninja like and there shouldn't be any trace of it post-edit. On the other hand, I'd also like it to replace the editor on http://www.pixastic.com/ so it should also run as a stand-alone app, but that shouldn't be a problem if the aforementioned criteria is met.

Some JavaScript files obviously need to be included (in Ubiquity's case, they're injected when the command is triggered) and in its current form the application is then loaded in an iframe where the DOM is filled and all the necessary CSS is loaded, keeping the editor separated from the page from which it was loaded.

Extendable

Well, it's based on Pixastic which is itself pretty easy to extend with new actions. Even though the internal API has a few flaws, it's easy and flexible enough that adding new actions and effects requires very little effort besides the actual image processing code. I'd like it to be just as easy to add new functionality to the editor so I'm working on a format that allows adding the most basic controls (text inputs, sliders, etc) with very little code but at the same is also flexible enough that you can create something like the cropping tool.

Load and save from/to anywhere?

Loading images is done programmatically at the moment but is as simple as calling loadImage(image) where image is an HTML img element. It would be great if it was possible to load up images from anywhere (other websites, Flickr albums, local images, etc), but same-origin security restrictions limit us to accessing images from the same host. There should be more freedom when running from Ubiquity and that feature would be more useful to have in the general case.

When it comes to saving, there are a few different options. The first - and most obvious when editing an in-page image - is to simply save the image back to the page. This is done by generating a data: URI and setting the src on the original image element. Second option is to save the image to the user's computer. This can be done by either making a link with the data: URI for the user to right click or by triggering a download dialog. The last option would seem like the best but in order to do that, the mime type of the data: URI has to be altered and it seems that Firefox is then unable to figure out the actual format of the image and defaults to giving it a .png extension, so that's only good for saving PNG images. I'd like to also take advantage of some browsers' ability to generate both PNG and JPG data: URI's so at the moment I'm not sure what to do. Any suggestions?

But with the cross-domain XHR abilities available from Ubiquity it should also be possible to post the image to something like Flickr or maybe Facebook. I've only just started looking at Flickr integration and I don't actually know if the Flickr API will even accept the image data - the data: URI is base64 encoded and it would be nice to not have to mess around too much with it since it can be quite big. I'll also have to look into what other online photo services are accessible.

Skinnable

To some extent the editor should be skinnable but I'm not going out of my way to make every detail customizable. In terms of layout I'm sort of going with Aza Raskin's Lightroom inspired proposal, at least for now. I'm using jQuery UI as a base for the UI elements, so all the theming that comes with that should apply here as well. It will likely end with a compromise with a somewhat fixed layout but color schemes and so on can be changed via CSS and jQuery UI themes if need be.

Feedback

At this point I'm very much looking for feedback on just about every aspect (features, UI, usability issues, etc.), but a couple of specific things I'm thinking about/that were brought to my attention are:

  • The undo feature: How does it work for you with the vertical bar? Is it in the right place? Should it stay hidden until there's actually something to undo?
  • Preview: On or off by default? I've hesitated turning preview on by default since JavaScript image processing can still be a CPU intensive task (especially with large images), even with today's fast JS engines. If processing was instant, I would have no problem making "on" the default state. Maybe turning it on/off once should toggle it for all actions (ie. globally)?
  • Apply: You have to actively click "Apply" before anything actually happens to the image. If you select another action/tab without clicking "Apply", your changes are lost, followed by much frustration. It's been suggested that all changes are applied right away (since you can just undo them). I'm not sure if that's the right thing to do due to the way the UI works right now, but that might just be me being used to the extra layer of confirmation. Perhaps it would be better if the button was highlighted in some way as soon as there are any changes that would be lost?

So many words

Ok, go on and play with the preview. When you're done, please let me know what you think.

At the moment it only works in Firefox but the aim is to have it working in all appropriate browsers. That means Opera 9.5+, Safari 4 (and Chrome once it gets [get|put]ImageData support in stable.

⇓ 15 comments Dark

That is EPIC. I especially love the glow effect - looks like Garry's Mod with the bloom lighting turned way up :D

Any chance of imgkk.com integration? Setting up the backend to accept base64 encoded images etc. won't be a problem :)


Also feedback:

- Keep the vertical bar, but have the original image state there when the editor opens.
- Disabled by default, but like you said, make it global. Also make it persistent if possible. :)
- Two possibilities I can think of there other than applying it by default - firstly you could highlight the apply button in some way on the first attempt to leave the tab by the user, but if they click again without hitting apply, let them leave the tab. Alternatively, you could reverse the changes but offer a sort of redo state in the undo column, if that's not too hard to implement :P

Also in the Pointillize thing, maybe the first slider should start from 1.5 or 2? Setting it to 1 seems to leave you with the original image :P

May 19, 2009 at 12:58 PM
Maurice

So far, the only way to load an external image is to use a proxy. I've made a trivial one for my canvas anaglyph generator: http://svay.com/blog/index/post/2009/04/03/Générer-des-anaglyphes-avec-javascript-et-canvas

May 20, 2009 at 2:25 AM
Jacob Seidelin

@Darkimmortal: Thanks for the feedback. I don't know if it makes sense to have the original state already there. Clicking it would do nothing and the original state is added to list when you perform the first action anyway.

@Maurice: Yes, and a proxy is how I'm able to load external images in the old editor. The Ubiquity version would be more privileged and not suffer from the same cross domain restrictions.

May 20, 2009 at 4:03 AM
Unknown

I really like the design of the new one compared to the old one. Have you thought about making it an AIR app?

May 20, 2009 at 7:41 AM
Dark

Yeah but having the first state there lets users instantly understand why the bar is there, and makes it seem more like Photoshop :P

May 20, 2009 at 8:15 AM
klmdb

love the post! this is why I keep checking this blog out.

feedback:
- I'm all for default preview. I can't really imagine why someone wouldn't turn it on.
- as for autoapplying changes; I was thinking to turn it on, but after reading DarkImmortal's comment I think his idea is better: when a first click wants to leave the edit function and changes would be lost, have the apply button flash up. If the user clicks to leave the edit function again, changes can be lost.
- as for the save function that seems to be worked out?
- to load an image from an external source, my first thought was a php script to load it through (like the proxy script suggested). An alternative might be a silverlight script. I must admit I practically dont know anything about this language but I've seen demo's and it can handle uploads etc splendidly.

May 22, 2009 at 2:49 PM
klmdb

ps: have you thought about layer support? I know it'd be much heavyer on the system, but still...

May 22, 2009 at 2:55 PM
Lex

There is a problem with the UI in the "reshape" tab.
If you enter a non-number string in a numerical input field(e.g. the "Angle" field), the UI Library will convert it to NaN. Your code doesn't seem to handle that possibility, and consequently, freezes reproducably (on the "Reshape" tab only).

I realize this isn't a high priority problem, but I suppose you would like to know.

It's a really nice javascript app though.

May 23, 2009 at 8:53 AM
Jacob Seidelin

Thanks for the feedback.

@klmdb: I think layers would be pushing it. Not that it's impossible but you gotta draw a line somewhere. The goal is a light weight photo editor and something like layers belong in full fledged apps like Photoshop.

@Lex: Thanks. There are a lot error handling and input checking issues that still needs to be fixed.

May 23, 2009 at 9:05 AM
stephenmorphey

But what do you do with the image after you’ve altered it? Is there a server-side component as well so that you can actually write the changes to disk? If not, this is just a toy, no matter how slick.

hard drive

September 26, 2009 at 3:32 AM
Dark

I'd imagine you grab the bitmap data, perhaps convert it to PNG or something in Javascript and fire it back to the server, perhaps with Base64 encoding.

September 26, 2009 at 6:25 AM
Anonymous

Awesome! This would be a great tool for CMS if you build in the opportunity to save on server or do I miss something and this is already possible?

October 30, 2009 at 6:52 AM
Jacob Seidelin

The plan is to have some sort of function that either returns the final image or posts it to a given URL. The rest would be a matter for whoever is implementing the image editor. So yes, eventually it will be possible to use it in such a context but development has slowed down somewhat due to me having to focus on other things.

October 30, 2009 at 6:58 AM
Anonymous

the download has no demo. . . kinda weird. ..

February 20, 2011 at 10:27 AM
Chibueze

So this doesn't work on Chrome/IE?

March 9, 2013 at 3:08 AM
Post a Comment