If you wish to request a new feature, please add it to the bug tracker. If there is a feature listed here with an accompanying bug number, please add your vote of support so it may get done sooner. Or better yet, undertake it yourself. :)

If you really want a certain feature implemented, you may need to scratch our back a bit to bump it higher on the priority list..

These features currently exist only in the development tree. As they are backported, they will disappear from this list and appear on the Stable Changelog page, where they will accumulate until the next release. If there is something you wish to get backported sooner rather than later, leave comments in the appropriate bug ticket or on the mailing list.

A demo site running the latest -devel code can be found at http://po.shaftnet.org/po-devel-demo/. This is not considered stable enough for production, and as such may have unknown bugs and incomplete features. That said, the maintainer runs his personal site (http://www.shaftnet.org/po/) on the same code, so any problems get sorted out quickly.

The main focus of the upcoming release is a revamped import pipeline, capable of scaling to an arbitrary number of processors. Additional image sizes (full-res, and two more “preview”) are now generated by default. The secondary focus of this release is improving performance through better use of memcache. Several database bottlenecks (mostly search-related) were identified and sped up considerably. Finally, the usual smattering of minor features, tweaks, and of course, bugfixes make their usual appearance.

This list consists of longer-term projects/goals which are generally made up of sub-tasks. All of these tasks are listed individually in the bug tracker. Please make new feature requests there.

This list also reflects the personal interests of the developers. There is no set schedule or roadmap for feature implementation, but incentives are certainly appreciated.

We have the original Aqua and a dark derivative (Blackwater) of it, but more, different, themes would be nice. And while we're dreaming, it would be quite nice to move to a proper templating system (such as Smarty), but that is quite a lot of work for lil' ol me to do.

There are lots of little enhancements to the UI I'd like to make, including the use of DHTML to speed up page loads (for the photo page tabs in particular), easy selection between multiple photo versions and image sizes, a scrollable list of images on the photo display page, “what's new” lists, a better system for bulk-tagging images, nicer photo slide frames, etc, etc…

Ideally we could adjust the RAW settings on a per-image basis, and allow regeneration based on the stored settings. There's actually a lot of work involved here. 6 It would also be nice to allow users to add custom image processing pipelines. (eg sharpen,crop,add a custom border,shadow,user-specified text…).

There are many ways we can improve both the speed and functionality of Photo Organizer's searching features, including caching of results, allowing searches of every stored field, and sub-searches. 89 239

Allow users to create 'virtual' albums that are tied to a particular search query. Any searchable field should be allowed. An example of how this would work is the current browsing by tags.

Specifically, integrate PO with PostGIS, and use it to add a whole bevy of features – “locations” can be polygons and location/distance/area-based searching becomes nearly trivial. Additionally, integrating with additional Geospatial applications would be much easier.

Theoretically, Photo Organizer supports bits of this already, but lacks a search backend (and integration instructions) to actually perform “find images like this one” searches. 100

We already have the means to pull up images between arbitrary date ranges, so all that's left is building cool features on top of this – RSS feeds and pseudo-albums based on date ranges come to mind. 176

Implement some sort of RPC mechanism (XMLRPC/SOAP/JSONRPC/whatever) that allows third-party software to call into PO's backend. There's a lot one can do with this sort of API. (“Give me ten random highly-rated images from user X's collection” “give me all the technical info about this photo” “give me an embedable image+url that I can inline into some CMS system”)

The current permission model is insufficient for many use cases. 8 245 Ideally, we'd be able to specify access rights on a per-user basis, not the current “public,clients-only,private”. This not particularly important for a single-user system, but makes a huge difference for larger deployments that have well-defined roles. (See New Permission Model)

While Photo Organizer will most likely remain PostgreSQL-dependent, we need to migrate to an abstraction layer (eg PHP:PDO) so that we are not tied to using PostgreSQL's bindings. In the process, we will rewrite all transactions using lazily-bound parameters to completely eliminate any possiblilty of future SQL injection problems. 11 Additionally, there are other database-level cleanups that need performing. 201 204 210. This will require PHP 5.1.0 or newer.

We have the means to authenticate against an external system, and sample LDAP and external database support. Down the line, we should look into tying into a single-sign-on solution like OpenID and/or integration into CMS systems (eg Drupal).