Precision image annotation

[ines (Ines Montani)]

@linusmartensson

If you want to expose custom CSS for different annotation tasks, how about adding the view_id (or a style_class:"classname" in the recipe) to the root div or “main” tag as a class?

That's a good idea! We could do something like .prodigy-view-ner, .prodigy-view-choice etc. I do see the point for custom identifiers for custom recipes, though – but maybe we could expose the recipe name separately, like data-prodigy-recipe="ner.teach"?

In addition, some more containers can get human-readable names, like .prodigy-buttons. And just like the "card_css" setting, we could then have a "global_css" setting that would let you add any other customisations you need.

@linusmartensson

<style> .prodigy-content circle { opacity:0.4; /*Increase visibility under circles*/ } .prodigy-content path { stroke-width:1 !important; /*Thinner lines for increased visibility*/ opacity:0.5; /*Lower opacity for visibility*/ } .prodigy-content svg { width:100% !important; /*Maximize the image in the card, alternative to zooming*/ } </style>

Okay, so what I take away from this is that we could use the following settings (aside from fixing the auto-sizing for lines and labels, as discussed in this thread). Names not final, I'm not always good at naming stuff

• bounding_box_opacity: Opacity of bounding box lines (default 1.0)
• auto_size_bounding_boxes: Automatically adjust line width and label font size if image is resized to fit. If disabled, lines and labels on a large images may appear smaller (default true)
• bounding_box_font_base: Base font size for bounding box labels, in px (default ??)
• bounding_box_line_base: Base stroke width for bounding box labels, in px (default 2)
• force_image_full_width: Force images to always take up the full width of the card, even if they're smaller. May result in lower image quality due to stretching (default false)
  ´

@linusmartensson

Is this on a newer version than the one I have prodigy-1.6.1-cp35.cp36.cp37-cp35m.cp36m.cp37m , or limited to only the custom HTML view_id?

Ah yes, at the moment, that feature is only enabled for the html view, because it's the most isolated one. Adding it to the other interfaces is definitely on the list for the next release.

window.prodigy should then also expose more details about the current task and configuration – for example, the current view_id and the name of the current recipe. The custom prodigyanswer event that's fired should probably include both the current task, as well as the answer – although I wouldn't recommend it, this would let you trigger an action immediately after the annotator has clicked on an answer.

@linusmartensson

I also can’t tell from your linked example if I’m mixing languages with javascript in the JSON file, or simply providing a file path like above

The value of "javascript" should be a string. Initially, the idea here was that users might want to be compiling their markup in Python within recipes – for example, compose the html_template or javascript depending on some command line setting. This would be difficult if the settings only took a file path. But I'm not 100% sure if it's worth it, considering that a file path is just much more convenient and easier to work with in JSON.

@linusmartensson

Finally, it would be great with some validation on the config file (as with the json validation for annotation tasks) to avoid issues with the current mixture of under_score_notation and camelCaseNames (is that intentional?)

Yessss, absolutely! As of v1.5.x, Prodigy uses JSON schemas to validate the stream, and I actually have an open PR internally that adds the same validation for the prodigy.json. I'm not 100% happy with some of the inconsistencies here, but we ended up accepting some of them for easy backwards compatibility. In theory, the only camel-case properties should be the CSS-in-JS-style values in "card_css" (and, in the future, "global_css").

(OT, but maybe the new GitHub actions will actually make Hashicorp's HCL config language more widespread and popular. There's some cool stuff in there that I like, but compared to regular JSON, the learning curve is just too much to ask from users at this point.)