MVP

[ctengel]

Write an MVP that basically integrates with ONE FR core backend and not yet a real db - probably AWS-specific, and implements basic image and person only functionality. A simple Python API will suffice, running locally or in EC2 - future versions could go in Lambda or Beanstalk.

API spec:

class FLDB:
    def __init__(self, aws_obj, recognition_coll, bucket_name, create=False, initial_data=None):
        # connect up to backed
        # optionally create them collection
        # optionally load pickled data
    def add_person(name):
        return person
    def get_person(name):
       return person
    def add_image(url):
      image = Image(url)
      faces.append = image.get_faces()
      return image
    def get_image(url):
    def delete_all()
    def export_db()
    def import_db(initial_data)

FLDB_data:

• Images
• Faces
• Persons

Image:

• init(url, rekog)
• get_url(s3url)
• get_faces (actually run rekog and cache IndexImage and create new Faces objs)

Person:

• set/get_name/id
• set_faces(confirmed, denied)
• get_faces(threshold, breadth, depth):
  • 1 = confirmed
  • 0 = denied
  • breadth = check x # of confirmed images to find more unconfirmed
  • depth = check x # deep for each
  • basically run get_similar on known good, and then remove any known bad
• add_face(face, deny=False):

Face:

• set_rekog()
• get_similar()
  • cache SearchFaces
• set/getb_info(rekogoutput)
• set/get_image:
• set/get_person(:
  • get_person easy if set - if not, run get_similar and see what happens

Tests

• add bunch of images
• confirm a few
  • workflow where one is added with a name in one shot
• who is this (based on image) Image->get_faces->get_person
  • workflow where image is added and outputs who it is in one shot
• more of (based on person) Person->get_faces->get_image
  • also more of an unknown person Image->get_faces->get_similar->Image

Backends:

• AWS S3
  • optional
• AWS Rekognition
  • mostly IndexFaces and SearchFaces
• AWS DynamoDB
  • schema TBD

[ctengel]

Should the denial also be handled on the Face side as well?

• allow a deny method on the Face
• store a list of denied Persons
• skip to next similar face in getpersons call

In a SQL DB world there would be just one table with

• faceid
• personid
• confirm/deny Or
• face object has one confirmed or null
• second table with denied person/face pairs

So could denies be a separate object or???

Or could we just handle it on EITHER side?

• face checks person before returning it
• or person checks face before returning it

Or we could just do away with denies altogether for the MVP since apparently they are tricky - better to just get a proper ID to the face, even if a temp one!

[ctengel]

Note even there some checking is needed to ensure that the face's person either matches or is null Unless the current face's person is unset in which case it could be set. Ugh

Also need a list person's and list images method to the db

[ctengel]

Also more of person unknown which could be as easy as get similar

[ctengel]

Get similar image based on same set of faces or person's? Sounds like past the MVP

[ctengel]

Another basic test - new image/vid - who dis is?

[ctengel]

What's still left?

• DB import/export (pickle?)
• have Face.get_person() do an average/etc to return each person once. - see #14
• refactor all "face creation" code
• implement tests CLI