Photo Organizer

Notice: Undefined index: tasklist_type in /var/www/flyspray/includes/class.tpl.php(128) : eval()'d code on line 85 Notice: Undefined index: tasklist_type in /var/www/flyspray/includes/class.tpl.php(128) : eval()'d code on line 90
  • Status Closed
  • Percent Complete
    100%
  • Task Type Feature Request
  • Category Backend / Core
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Normal
  • Reported Version Devel
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: Photo Organizer
Opened by Solomon Peachy (pizza) - 2006-04-25
Last edited by Solomon Peachy (pizza) - 2008-10-27

FS#7 - Generate a hi-res JPEG from RAW images

We generate "thumbnail" and "preview" images for all images we upload, and we can download the original, full-res version. However, with RAW images, this is suboptimal, as we'd then need to process the RAW image into a usable JPEG.

Add the ability to generate a full-res JPEG from RAW images, and make the RAW download itself optional. Perhaps we could implement this using the whole "image version" thing?

This task does not depend on any other tasks.

Closed by  Solomon Peachy (pizza)
Monday, 27 October 2008, 13:23 GMT
Reason for closing:  Implemented
Additional comments about closing:  Finally done. Will be in v2.37
Solomon Peachy (pizza)
Wednesday, 20 December 2006, 15:21 GMT
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.
Solomon Peachy (pizza)
Sunday, 04 March 2007, 17:57 GMT
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.
Solomon Peachy (pizza)
Sunday, 25 March 2007, 12:56 GMT
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.
Solomon Peachy (pizza)
Tuesday, 27 March 2007, 03:37 GMT
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.
Solomon Peachy (pizza)
Wednesday, 18 April 2007, 23:29 GMT
image_display.php is now fixed up to allow for an arbitrary number of sizes. (r1226)
Solomon Peachy (pizza)
Monday, 23 April 2007, 21:31 GMT
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 ]]

Solomon Peachy (pizza)
Thursday, 26 April 2007, 02:58 GMT
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.
Solomon Peachy (pizza)
Tuesday, 24 July 2007, 12:28 GMT
We now import the preview image embedded in the RAW file, if present, as a secondary version.

It's not the same thing, though.
Solomon Peachy (pizza)
Wednesday, 14 November 2007, 22:50 GMT
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.
Solomon Peachy (pizza)
Sunday, 25 November 2007, 17:56 GMT
the "original" image is now size code 0, and a lot of the refactoring of the resize/db insert code has now taken place.
Solomon Peachy (pizza)
Friday, 25 January 2008, 01:49 GMT
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.

Loading...