first pass of consolidating search in DBox for existing person, and then using the results to add override force match to that person, and WORKING version of adding refimg to existing person too. Still does not kick off new AI scan at this point, and still need to re-format dbox to be easier to use and code for resetting DB contents, rescaning files from scratch and matching overrides back
This commit is contained in:
27
TODO
27
TODO
@@ -1,11 +1,14 @@
|
||||
## GENERAL
|
||||
* run_ai_on throws log line, for matching even if there are no faces, would be less noisy to not do that (or should say no faces?)
|
||||
* on viewer:
|
||||
- allow face to be used to create person, add to existing person, and allow 'ignore', mark as 'not a face', etc
|
||||
-> ignore/not a face/too young --> all need to go into DB so we can remember the 'override' when we re-ai-match
|
||||
-> redraw 'ignore's as a greyed out box?
|
||||
-> menu should only allow override IF we have put override on...
|
||||
SO, override manual match, is awkward if somehow the file/face changes (e.g. we rescan a file for faces, do I delete override? if not and we rescan, there will he a new face id, how do I know which it connects with????)
|
||||
- allow face to be used to:
|
||||
- create person
|
||||
[PARTIAL - person.py to go] - add to existing person
|
||||
[DONE] - ignore/not a face/too young
|
||||
[DONE] - redraw 'ignore's as a greyed out box?
|
||||
[DONE] - menu should only allow override IF we have put override on...
|
||||
--> need to test the 'override' when we re-ai-match (AFTER re-build from FS)
|
||||
|
||||
* run_ai_on throws log line, for matching even if there are no faces, would be less noisy to not do that (or should say no faces?)
|
||||
|
||||
* should allow right-click from View menu (particularly useful on search) to show other files around this one by date (maybe that folder or something?)
|
||||
|
||||
@@ -16,8 +19,6 @@
|
||||
then we could just feed those eid's explicitly into a 'run_ai_on_new_files' :) -- maybe particularly
|
||||
if count('new files') < say 1000 do eids, otherwise do path AND no new refimgs
|
||||
|
||||
* DECIDED TO DITCH multiple Dirs per Path, just adds complexity and not needed - will address BUG-60
|
||||
|
||||
* does search of matching dirname give all entries of subdirs of subdirs, etc. (think not) -- maybe a TODO?
|
||||
|
||||
* delete folder
|
||||
@@ -32,11 +33,8 @@
|
||||
???
|
||||
|
||||
* browser back/forward buttons dont work -- use POST -> redirect to GET
|
||||
* viewlist
|
||||
- can consider a POST every time we next/prev in viewer --> set only, to just update the OPT.current, every time you go back into the viewer, then it would go the last image viewed, rather than the first image on the last page you viewed...
|
||||
- can consider an optim-- new_view page makes calls to viewlist to ADD json data only, so only trigger a new "viewlist" if we dont have data for that part of the eids
|
||||
- need some sort of clean-up of pa_user_state -- I spose its triggered by browser session, so maybe just after a week is lazy/good enough
|
||||
-- pa_user_state has last_used as a timestamp so can be used to delete old entries
|
||||
- need some sort of clean-up of pa_user_state -- I spose its triggered by browser session, so maybe just after a week is lazy/good enough
|
||||
-- pa_user_state has last_used as a timestamp so can be used to delete old entries
|
||||
|
||||
GUI overhaul?
|
||||
* on a phone, the files.html page header is a mess "Oldest.." line is too large to fit on 1 line (make it a hamburger?)
|
||||
@@ -53,8 +51,7 @@
|
||||
|
||||
* get build process to create a random string for secret for PROD, otherwise use builtin for dev
|
||||
|
||||
* deal with changing/adding/removing a path in settings
|
||||
-- consider this in light of only one dir per path
|
||||
* deal with changing a path in settings
|
||||
|
||||
* dup issues:
|
||||
* when we have lots of dups, sort the directories by alpha so its consistent when choosing
|
||||
|
||||
Reference in New Issue
Block a user