MVP for the DLC webinar

[stes]

Done:

• Add labels to the data model
• Allow to create new users (actually, you can just type and sort of identifier in the textfield)
• API for fetching results
• Collecting stats about labeling (time stamp so far)

Next:

• object persistance (i.e. show points when you click "previous" etc)
• add a default random username that can act as an identifier
• improve the GUI: currently I disabled double clicking etc; there are some issues in the callbacks in main.py (the the log messages I am writing currently)
• Fetch 3 random keypoints instead all, color them
• Make draw area larger
• Improve image loading times (also, currently the images are subsampled, there's some performance issue --> isnt jpeg compression handled automatically by plotly?; perhaps use the jpgs that we added
• Randomize which images is shown

To run this, please first fetch data:

mkdir -p data
parallel wget :::: config/filelist.lst
mv *.png data

For deploy mode, do

./run.sh

For debug mode, do

python app.py

You can fetch the data using

curl -s http://localhost:8050/csv

and see a summary at curl -s http://localhost:8050/csv.

[AlexEMG]

You can remove the folder: openfield-Pranav-2018-10-30

[AlexEMG]

Note, when running locally just cache images first.

mkdir -p data
parallel wget :::: config/filelist.lst
mv *.png data

[AlexEMG]

Improve image loading times (also, currently the images are subsampled, there's some performance issue --> isnt jpeg compression handled automatically by plotly?)

I put pngs. That makes little sense. Switching to jpg now! That is about 10 times smaller...

[jeylau]

Seems to be running smoothly!

[stes]

currently throws this error (fixed for now)

[emmanuelle]

Hi @stes it's awesome to see a Dash app written for this cool application :-). I noticed on the deployed version that it takes quite a lot of time for a marker to appear when you click somewhere (disclaimer: I've got a slow Internet connection ;-)). The reason is probably that you have to transport the figure prop from the client to the server and back since it's both a State and Output of the update_image callback. When working with images one should try to limit these transfers as much as possible. A classical trick is to store the current figure in a dcc.Store and then you could have

• one callback returning a layout patch (also stored in a dcc.Store) when clickData triggers the callback
• one callback returning a figure dict (another dcc.Store) when you need a new image (previous/next buttons)
• and one javascript client-side callback which would update the current figure store with the output of the two previous callbacks (basically the layout patch and the new trace if needed)
• and a last javascript client-side callback to modify the canvas figure with the figure store when it has been modified.

I did not try it myself but from a quick reading of your code I got the impression that this should work. It's a common trick to use a store for a large figure and then use the store in a clientside callback.

Please tell me if this makes sense!

[jeylau]

Hi @emmanuelle, it's great to have a Plotly expert around :)
Thank you for the super useful tips! (And they answer what I wanted to ask you earlier about splitting the update_image callback for efficiency.)
Would you also have other tricks up your sleeve to go around the requirement of a single callback per Output? Or is that normally not a problem if things are well written?

[emmanuelle]

With the requirement of having a single callback for a given output property, you end up writing callbacks which are more like routing functions: you can test which input triggered the callback thanks to the callback context, and execute a different function for each possibility. This way you keep your callback small and well-organized.