Photo Organizer

  • Status Closed
  • Percent Complete
  • Task Type Feature Request
  • Category Backend / Core
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Devel
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Photo Organizer
Opened by pizza - 2006-04-25
Last edited by 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?

Closed by  pizza
2008-10-27 13:23
Reason for closing:  Implemented
Additional comments about closing:  Finally done. Will be in v2.37
pizza commented on 2006-12-20 15:21

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.

pizza commented on 2007-03-04 17:57

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.

pizza commented on 2007-03-25 12:56

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.

pizza commented on 2007-03-27 03:37

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.

pizza commented on 2007-04-18 23:29

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

pizza commented on 2007-04-23 21:31

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 ]]

pizza commented on 2007-04-26 02:58

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.

pizza commented on 2007-07-24 12:28

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

It's not the same thing, though.

pizza commented on 2007-11-14 22:50

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.

pizza commented on 2007-11-25 17:56

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

pizza commented on 2008-01-25 01:49

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.


Available keyboard shortcuts


Task Details

Task Editing