diff --git a/README.md b/README.md index 7aaa75b..6eec74d 100644 --- a/README.md +++ b/README.md @@ -123,6 +123,8 @@ Roadmap ------- - TODOs: + - need `nullable=False` on columns where applicable + - 0-5 rating option for photosets - give uuids a style like `this` - search next/prev buttons to match feed links - search tag selector to match tag picker links @@ -142,6 +144,17 @@ Roadmap - nullable=False for all columns possible - check/clean no-js fallbacks - check gps skew in "nearby" section + - camera info / database + - show the camera information on each photo page + - create a catalog of known cameras by extracting the info from the exif + - associate cameras with photos and allow search by camera + - cameras can be nicknamed + - all of this with lenses also? + - make it clearer that the download/preview button gets a (converted) original size image + - make the map view markers colored in some logical manner + - rainbow across age spectrum? + - 4 colors (with shades) for the 4 seasons? + - colorblindness? - Flesh out CLI: - data manipulation @@ -189,3 +202,44 @@ Prior work / modules to use: * https://face-recognition.readthedocs.io/en/latest/face_recognition.html * https://www.pyimagesearch.com/2018/06/18/face-recognition-with-opencv-python-and-deep-learning/ * https://github.com/JohannesBuchner/imagehash + + +Image processing framework +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Purpose: + +Some way to mass process photos in batches. For example, the batch jobs could: + - load metadata from images that is newly supported + - process new faces in images + - create a downloadable mini-album + - proactively generate thumbnails + - replace thumbservice, the video thumb service + +Could also have: + - a session-based mechanism to "select" photos + - e.g. to add them to a batch processing job or album later. Like a clipboard of sorts + +Design notes: + - general ui: + - use a tag multiselector (like the search page) to pick the "input" images for a batch job + - for now, we can have a drop-down to select which job to run + - there could then be a second-stage config screen for the job where + - additional parameters for the job could be set + - like what? + - the job could run some sort of validation + - there is a Job List screen that displays an index of current / past jobs + + - job executor: + - "for now", a SimpleExecutor service. + - it's an http service (like thumbservice lol) that is similarly notified by http hook when a job is created by + the ui/api (except we pass the ID in the http call this time and it looks up the details from the DB) + + - internal notes: + - tables / cols: + - Job: id, uuid, name?, job_name, status(new, running, done, error) + - JobTarget: id, job_id, type(tag, set, photo), target + - this indicates where a job should get images to work on + - there is a numeric ID in the `target` column that can be any of a Photo, PhotoSet, or Tag + - which it is, is determined by the `type` column + - therefore the code can know which method to locate the file with