Want to make sure the Gallery 3 API can facilitate this scenario:
A network of security cameras FTPs JPGs upon motion detect to a central server. Pictures have filename in this format: 1600-pennsylvania-20080914_112127.jpg. (streetNumber-streetName-date-time)
A PHP script runs once a minute, and on each image in the FTP upload folder:
1. Adds image to Gallery into folder for camera's address. (1 folder per address)
2. Sets four tags on image: street number, street name, date, time. Tags may be like this: 1600 pennsylvania 2008y 09m 14d 11h 21m 27s.
3. Deletes original image.
Problems encountered with Gallery2:
1. API had no way to pre-generate thumbnails. Frequently had to refresh Gallery albums many times just to get thumbnails to build. (Had it set to show 3 cols x 20 rows so we could browse more easily.)
2. Generally byzantine API with too many alternatives to do the same thing.
3. No facility to filter images on image timestamp. Instead had to add date/time to image as tags and search tags. If I wanted to find all images at 1600 Pennsylvania between 9 AM and 9:59 AM on 1-23-09, I had to enter these into the search field: 1900 pennsylvania 2009y 01m 23d 09h. Will Gallery3 support a better way? ALSO, not clear if search is for all terms or any terms. If it's for any, then the above search could return tons of images.
4. Way to automatically "age out" pictures based on age or filesystem size. E.g., prune off pictures older than 20 days or prune off oldest pictures until filesystem utilization is less than 70 GB. Investigated API-based solution, but it appeared extraordinarily difficult to do this.
If you can support this scenario, you may be an important component in allowing neighborhoods to set up open source-ish camera monitoring systems.
Posts: 4342
Aren,
I don't mean to be rude, but the use cases for Gallery 3 have already been written about in great detail on this website. It's unlikely that listing a set of detailed specifications for your own customized Image Gallery requirements is going to drive the developers towards implementing them for you. I'm sure you'll realise by now that the intention for Gallery3 is to be easier to contribute to so community members (like you) will be able to add to it and customize it, but as an outsider I detect very little enthusiasm on the part of anyone to spend a lot of time to "support this scenario" for any of a large number of very very corner-case specific "I must have these exact features or your project is a load of crap" requests.
I guess the answer is to wait and see; whatever part of your requirements match up to the developers' stated (and re-stated, ad nauseam) aims for G3 will be included; and those that aren't won't be, and you will have to write the code for them yourself.
Posts: 4342
Going on further, I've read through your list of requirements, and they're all achievable with some fairly straightforward programming in Gallery2.
Posts: 58
Sorry for the late reply, but programming Gallery2's API is anything but straightforward. See forum post Some thumbnails don't generate until page refresh for an example, which you tried to help me on. Also see How to archive or delete old images?.
I look forward to the Gallery3 API documentation so I can get off the Gallery2 API kludge.
Posts: 2466
@alecmyers: I am not sure why so much resistance in your post. FYI API discussion for G3 is just started and still progressing.
There is a list of requests/requirements currently discussed to be implemented in G3 API.
You can find some information about this here http://www.nabble.com/API-development-td24473532.html and here http://codex.gallery2.org/Gallery3:API
From my view, majority of things Aren is asking about are outlined (aside from developing custom module), so I do not see how any new use cases would violate any existing. We are looking to have robust API and for that we need as many use cases we could get, are we not?
To be constructive further, I would suggest for people interested in new features supported by API to keep an eye on the discussion above and participate where possible.
Posts: 4342
Because it was written at a time when it appeared that everyone was jumping on the announcement of G3 as an opportunity to shoe-horn in as many features as possible for their pet project. I sincerely hope the API develops in a direction that is useful for this, and other customisations!
Posts: 58
Thanks, Serge! If you can address the needs in the first post in the API, then Gallery3 could be major part in communities being able to establish low-cost camera monitoring systems.
Posts: 2466
I am working with G3 team to see if API can be implemented as such
Posts: 120
In the meantime you may want to have a look at Zoneminder http://www.zoneminder.com/, which would probably suit your requirements well.
Having said that, I have previously thought about something like the idea you have mentioned here. So you're not the only one, but there probably isn't a very big demand for something like this.
Posts: 7994
This all looks pretty easy to accomplish with the Gallery 3 REST API. http://codex.gallery2.org/Gallery3:API:REST
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git