Not showing same image in image_manual

, ,
1

Hi Ines and everyone. I'm posting about an issue that I cannot resolve.

I'm using a recipe with view_id "image_manual" where I write my own stream. I have a single image encoded as a base64 string and have a bunch of rectangles on the image given by their coordinates. As I loop over the rectangles, I yield a dictionary res containing the image under "image" and the rectangle in "spans" (+ other stuff, but it should be irrelevant).

My problem is that only the first image is displayed, with the rectangle correctly displayed there, and the further images are displayed blank (with no rectangle of course). I tried:

  • changing the view_id to "image", and changing nothing else: it works and I get the same image plotted with the different bounding boxes, but I need the annotation/drawing tools in "image_manual"
  • adding a unique "label", "text" to the dictionary to differentiate the tasks, still the same
  • setting hashes directly with both _input_hash and _task_hash, still the same
  • forcing unique hashes with set_hashes (and I print them to verify that they are different between the images), still the same
  • embedding the image_manual interface in blocks, still the same
  • not having a generator but a list, still the same
  • saving the first 5 results in the db and skipping them, once I start the 6th one is fine but the 7th is not here

Any idea what I could be doing ? The weirdest thing is if I change "view_id":"image" instead of "image_manual" and nothing else (return from the recipe), it suddenly works.

Any ideas what else I could try ?

Thanks in advance

2

Wow, I figured it out, somehow.

I did not have the entries "width" and "height" in the dictionary. Still weird that the first one works and not after, seems more like a hash/duplicate issue.

Any idea what is going on behind the scenes ?

3

That's definitely strange :thinking: I don't think it'd be related to the hashes or somthing related to that, because this woud result in the task being skipped entirely. And "spans" will definitely be relevant for the hashing.

I wonder if this actually points to an inconsistency in how the UI "guesses" the width and height from the loaded image. If no width and height are provided, Prodigy will load the image and then get the correct width and height from the loaded image file. So maybe this isn't correctly triggered on updates but only on first load, which would explain why it worked for the first example. It possibly hasn't come up before because if you load images from a directory via Prodigy, the width and height are added automatically during preprocessing. And it'd also explain why you don't see the problem if you're just using the image UI: in that case, the image is loaded statically and in a slightly different way.

I'll definitely have a look into that – but glad to hear you found a workaround by just adding the width and height yourself!

4

Thanks for the reply!

All the best :slight_smile: