imgfiddle is an image modification playground with liberal inspiration from jsfiddle.

I'm not even bothering going into what's already done, this is primarily to track what's left:

  • Persistence of the web UI URLs. The changes made to an image are represented in JSON which can be part of the URI hash, but it looks like it'll become unwieldy quickly. I have to decide if a URL shortener will be built-in, or if I'll be using some other way, like, say, having the URL shortened through an API call from the client's side to some URL shortener.
  • Performance.
** Needs some kind of timeout when generating the image (for
charcoal=40 pathological cases)

** Needs some limit on the file size

** I kind of doubt that the file IO on the tempfiles will become an
issue, but if it does, symlink to /dev/shm and see what happens.
  • On the subject of compositing images... I have to figure out how to indicate a step that applies to an image source before the compose/multi-image-input step. There's an imgname option to load-image steps, so maybe that should just become an optional option for all steps. in _run_conjure, then, we'd have to split out the steps by which input file they apply to. I don't think there'll be any ambiguity, though, since we can make sure that all input-image-processing things must be applied before any multi-image-input steps (like composite, compare, etc).
  • And, of course, the age-old question: how do I get the files in the first place? I have urllib.urlopen() with a hardcoded whitelist ATM, but that hardly seems OK. Neither does any alternative. Do I accept file uploads? I guess. Meh, that's always ugly code. For now, I'm making it a standalone app so it can be install within an existing project, which should at least provide access to on-disk images on the server. I just need a load-image with "file-path" instead of url.
  • Indicating the returned file's mimetype. Always PNG right now.
  • On the UI side:
** maybe reorderable steps. But steps can't be in arbitrary order;
load-image has to be first, for example.

** Sliders for numeric opts.

** In the interests of insanity, grouping would be nice
too. Enable/disable/reorder a sub-pipeline.
** In the interests of further insanity... those sub-pipelines could
be named/urled. But I think I'm out-of-scope now though.