Photo Organizer

1 == thumb == 170x170
2 == preview == 700x700
3 == original == whatever

I want to make things:

1 == thumb == 170x170
2 == size1 == 350x350
3 == size2 == 700x700
4 == size3 == 1050x1050
5 == full == original size (linked or RAW)
99 == original == whatever

Hmm. I wonder how hard this would be to migrate.

Another option would be to simply generate the full-res image.. and import that as an additional version.. much like how duplicate filenames already work.

It gets more complicated; and really should be written to be generic. Each image in the database would need to know its size, transforms, and physical location. The existing "thumb, preview, orig" as stored in the database needs to go away.

So, instead of 'photo_version' --> 'thumb_path, preview_path, orig_path' we'd need something like:

create table files {
identifier integer primary key,
version integer references photo_version(integer)
size integer not null, -- eg '1 == thumb, 2 == preview, 3 == original, etc
x_res integer not null,
y_res integer not null,
path_to_file text not null,
params text not null, -- eg 'decoder=ufraw sharpen=1x5+2+4 watermark=1234'
comments text
};

All queries that get the image paths would need to be updated, of course. Fortunately there aren't many. Once we migrate the existing sizes over, adding additional sizes is something we can think about in more detail.

The table migration was checked in in r1150. Now that the backend supports arbitrary sizes, we need to figure out how to enable this in the UI:

* genericize auto-generated sizes on import, version add/edit, bulk update, and rotate; convert 'thumb' and 'preview' to this mechanism.
* add preferences for auto-generated sizes/parameters
* modify image.display.php to key directly off the size parameter rather than its internal rules. <--- Next up!
* Use size in DB whenever possible (eg slide view, shaded photo view, etc)
* Add "default image size" preference for users.

My initial feeling is to add '4' == 'original size, but sharpened+watermarked+processed' to the list as a "standard" image size.

image_display.php is now fixed up to allow for an arbitrary number of sizes. (r1226)

I need to add a UI blurb at the bottom of the 'photo' page that lists 'available sizes':

For a standard JPEG/GIF/PNG -- images that browsers can display inline:

[X] 150x100
[ ] 600x400
[ ] 3000x2000 (full-res original) [[ download link as well as display link ]]

For any image that isn't JPEG, GIF, or PNG:

[ ] 150x100
[X] 600x400
[ ] 3000x2000 (Full-res, processed) [[ download link as well as display link ]]
[ ] 3000x2000 (Full-res, non-displayable original) [[ download only ]]

We now have the ability to track whether or not a particular image is watermarked.

This way we can give authorized users the ability to download non-watermarked images too.

We now import the preview image embedded in the RAW file, if present, as a secondary version.

It's not the same thing, though.

I'm still working on cleaning up the guts of the import/etc code, refactoring and consolidating the various image/db operations with the eventual goal of having a generic 'generate a scaled-down image with this set of parameters and add it to the database' function. Once that's done, the preference/settings UI needs genericizing.. then we can add more sizes with relative ease.

It's a simple feature request, but to do it right takes a lot of work.

the "original" image is now size code 0, and a lot of the refactoring of the resize/db insert code has now taken place.

Centralized all image scaling code into one place -- that is to say, We call one function and it generates all scaled versions of the image and adds them to the database.

Best of all, the list of scaled versions and their parameters is entirely config-driven! To define a new 'type' all you need to do is add the config keys and it'll be created.

Note that there's no way to find out what additional versions are available as of yet.