Willing to hire a programmer to enhance gallery
|
diodata
Joined: 2009-04-30
Posts: 20 |
Posted: Tue, 2009-12-08 21:27
|
|
I work for a research group at the University of Delaware. We're currently using Gallery2 to maintain our digital images inventory. I think it's a great product but there are a few enhancements that would make a world of difference for us. And we have a little money that may help make that happen. The three pieces we need are roughly: 1) geographic search. A user can draw a box on Google Maps or enter lat/long coordinates and it would search all images that are located within that box. Maybe also start from a point and search by distance from that point (even if it was a rectangular extent.) 2) temporal search. A user can enter a date range and then search for all images within that range. 3) the ability to apply metadata from the database into EXIF/IPTC headers of the files. Particularly, as people edit the items in the gallery, those edits should be applied back into the files: title, caption, keywords, GPS coords, and dates. I would love for any work to be submitted back to Gallery. Items 1 & 2 seem like they should be modules, or edits of the core search functions. Item 3 (probably easiest and most straight forward) could be a separate perl/python/php script using exiftool that I would manually run as needed. Are there any developers available to do this work? How much would this cost roughly? And how long would it take? (there's no immediate deadline to get these done.) Please let me know. Thanks. - John |
|
Posts: 4342
Item 2 is a trivial new module based on the dynamic album module, should take all of about 15 minutes, plus however long it takes to design the user interface for the feature.
Item 1 same idea and not a lot harder, if you're prepared to enter the coords, and if the lat/long info is in G2's exifdata (don't know how that's handled)
Item 3: a complete PITA.
Posts: 20
Item 3 sure isn't fun but I am surprised it would be a PITA. You don't need much of a user interface, unless maybe if you wanted to limit it per album/sub-albums.
For item 2, our audience would likely need a map interface to draw a box around their area, or to pick a point and distance. This should be able to populate hidden form fields or generate server-side calls, etc...
Email me if you'd be able to do the work.
- John
Posts: 4342
Item 3 is "Gallery-awkward" because Gallery is predicated around NOT altering the original files. It doesn't have in the API (as far as I know) any primitives that help with that task.
Items 1 and 2 have already been written by Mindless in the (very easy to replicate/extend) dynamicalbums module, save that the db search that returns which images to show need to be changed to search on timestamp in the first case, and some mathematical function of the lat/long in the second. Job done. You could have a crack at it yourself and save the dosh for a good cause. If you want more examples I stuck a module in the -contrib repository that pulls out files whose names contain (or begin with) any given alphanumeric string - I can't remember what it's called. I think I also wrote (modified, really) a date-range module too, which is your item 1 already done.
Posts: 20
Thanks for the thought that I'd be able to do this myself! I agree that it doesn't sound very difficult. Unfortunately, I had absolutely no time... I'm in the middle of several web sites (dev using Drupal + content) and a few GIS-related projects.
I thought I saw in the Google Maps module an option to write coords to EXIF headers. Not sure if they used the Gallery API or maybe the php exif functions. As you say, this may not quite fit into the Gallery framework but it would allow us to manage our data online and keep it attached inthe images when people download them.
I'm thinking item 3 might not work well without the ability to reload photos into the Gallery on a per album basis. Some people edit the photos on the server after they were imported into gallery. Those images need to get re-imported and the exif/iptc metadata re-parsed. People usually do this on a per folder or per album basis. That would need to run probably before I ran a script that put database data into the files. Make sense? ;)
I should also add that it'd be great if the searches worked together. Sometime like "give me all photos in this date range in this location" or "photos with this keyword taken during this time period."
- John
Posts: 4342
From your perspective, yes. But it's not how G2 is designed to work, and the further away from G2's nailed-down operational paradigm you go the harder it is to come up with solutions that are, ultimately, satisfactory instead of being unreliable PITA pieces of junk that nobody wants to use and everyone looks for excuses to avoid...
Once you've written both searches, there's no difficulty about combining them. All the time will be spend designing a UI that suits though, which is an open book until you define it clearly. If I were taking the job on (I'm not!) I'd want photoshop mockups of screenshots signed off before quoting.
Posts: 20
Thanks for your thoughts. I understand and agree with what you mean about the G2 paradigm. Unfortunately, this is something I'm pretty sure we'll need. (people will edit keywords/captions online and those changes will need to be put back into the image files.) However, I'll keep that task separate from G2 api/modules and likely write something myself (in the future, when needed) specific to my org needs.
The searches are what I'll focus development on, and keep looking for someone who can do the job over the next couple of months. Thanks again.