update notes
Gitea/photolib/pipeline/head There was a failure building this commit Details

This commit is contained in:
dave 2023-01-12 22:59:19 -08:00
parent 72cd490e5f
commit 183dcca0ba
1 changed files with 54 additions and 0 deletions

View File

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