The following code shows the same image three times which is certainly a reasonable default. However, the task can be performed by showing the image in the image_manual view and then showing the choices and free form text below that without any more images. How do I remove the images for the choice and text_input parts?
def add_options(stream):
# Helper function to add options to every task in a stream
options = [
{"id": "cat", "text": "cat"},
{"id": "dog", "text": "dog"},
]
for task in stream:
task["options"] = options
yield task
@prodigy.recipe("image-caption")
def image_caption(dataset, images_path):
"""Stream in images from a directory and allow captioning them by typing
a caption in a text field. The caption is stored as the key "caption".
"""
db = connect()
# input_hashes = db.get_input_hashes(dataset)
stream = Images(images_path)
stream = add_options(stream)
# stream = filter_inputs(stream, input_hashes)
blocks = [
{"view_id": "image"},
{"view_id": "image_manual"},
{"view_id": "text_input", "field_id": "caption", "field_autofocus": True},
{"view_id": "choice"}
]
return {
"dataset": dataset,
"stream": stream,
"view_id": "blocks",
"config": {"blocks": blocks},
}
Hi! Each block lets you overwrite task properties that shouldn't be used and rendered by that block. For exampe, you could set {"view_id": "choice", "image": None} to prevent the choice UI block from showing the "image" present in the data.
The text_input block doesn't render any images. So in your example, you'd then end up with 2 images: one rendered by "image", one rendered by "image_manual" (not sure if that's intentional? If not, removing the first image block should leave you with the manual image UI, a text input and the choice options).
Hi Ines! I'm glad I found this post. I just ran into this exact behaviour this week and couldn't figure out what was going on. Looking back it makes sense, but it absolutely stumped me two days ago.
Is there detailed documentation on the individual views' options and default behaviours? I'm not sure if I missed it.
Thanks, glad it was helpful! And good point, you're right that this is currently not that explicit in the documentation. The classification and choice interfaces are trying to be a bit more "clever" and detect whether the original input data contains relevant information that could be visualized – either an "image", "text" or "html". This way, loading in a task with a key "image" and options in the choice UI will just work out-of-the-box. (But it also means that if you're combining it with other image UIs, you need to tell it to try and be "less clever" )
It absolutely makes sense from a design standpoint, though the behaviour was confusing at first. I still don't feel I understand it completely. Is it that I can give individual configs to each of the elements and they will "fall back" to "top-level" config elements if they can't find any individual ones?
In my case what really confused me was when I was trying to add a multiple-choice element for gathering some feedback at the end of an image annotation task. I gave the choice element some "text" in the config, which I wanted to serve as header for the "feedback" section. If I recall correctly, annotating the image even led to the text being annotated. That was confusing
)