Auto Generated Names is deleting text files.

[Bpable]

When loading darkmark if the user doesn't load their custom names file, but it autogenerates one. It has at times deleted large portion, or all of the text files already in the data. Below the same data is present with the one exception is a names file already present in the first folder, and missing in the second one. When loaded, the second folder loses all the text files present.

This has been done on a windows 11, and linux mint 21.1 & 21.3 cinnamon.

[Bpable]

Additional bit. It seems that if a name file that is a different size is used. The folder retains the old labels, but can't be selected. So if you had something labeled as value 8, replaced a names file that only goes to 3. Those still remain. In the first image is that example of the "safety_cone" and "crossing_sign".

[stephanecharette]

I'm not sure I understand. How (or why?) did you load DarkMark without using the existing .names file? There is code in DarkMark to auto-select the first .names file in a folder. Did you manually delete the name of the file to load?

And if you press ESC to go back to the launcher, and then you select the correct .names file, everything is then OK, right?

[stephanecharette]

This has been done on a windows 11

DarkMark doesn't run in Windows. Do you have modifications you can submit to have it run in Windows?

[Bpable]

I work with a small team. I'm not sure why, but someone on there end seems to have removed it, or not pointed to the correct location of their names file before loading. When trying to recreate the issue this was the only way I was able to do so.

And no its deleting all of the corresponding text files, or a large portion of them. So the data is getting lost.

Also for the windows part thats people running it on WSL2. Should've specified that.

[stephanecharette]

Projects need a .names file. If you delete it, then DarkMark creates a sample one. So my first thought is...don't delete the .names file?

You're saying the .txt files were modified and the annotations lost? I can imagine if the annotations are beyond the number of classes in the .names file, then DarkMark probably logs something about erroneous or invalid annotations. I don't recall if it then drops the annotations that don't have a class, but I can imagine that is how it works, since it was told to load the project in question, and the .names file determines the classes. I would look at the DarkMark.log file for details.

DarkMark tries to do lots of validation on the annotations it is importing. Checks the bounding boxes to make sure they're within the image, checks the classes. Bounding boxes are modified to move within the image dimensions. But if an annotation is invalid, what else can be done but drop it?

I'm more curious to know why the .names file was deleted when the project was loaded. What is the right thing for DarkMark to do at that point?

[Bpable]

Projects need a .names file. If you delete it, then DarkMark creates a sample one. So my first thought is...don't delete the .names file?

I am aware, and am trying to convince them thats all they need to do to ensure this problem doesn't happen. Which they insist thats not the issue.

You're saying the .txt files were modified and the annotations lost?

Its not that the annotations are lost. The text files are just fully deleted for some reason. Which seemed odd when it seems to auto generate a names file. Below is what happens when running it without it. It does generate a names file, just all the relevant text files that had the annotations are deleted also.

I'm more curious to know why the .names file was deleted when the project was loaded. What is the right thing for DarkMark to do at that point?

I don't know why they removed the names file. Would've saved a lot of hassle and work if they didn't. I would've assumed it would've just filled the labels with whatever it autogenerated. As it's autogenerated names file seemed to match the number of labels.

[stephanecharette]

If someone deletes the .names file, then DarkMark will create a new one.

But DarkMark will never delete the .names file itself. Either they moved it, or they didn't copy it, or...?

As to how or why it deleted the .txt files, again, please look in the DarkMark.log file to see the details.

I think you're dealing with multiple problems here, some of it caused by the user (deleting or moving the .names file) and some of it caused by DarkMark due to the missing .names file.

If you can figure out a way to replicate the problems with a .names file, then I'll see what needs to be fixed in DarkMark. But if the problems only happen if the .names file is first deleted, then I would say the solution is to not delete the .names file.

[Bpable]

But DarkMark will never delete the .names file itself. Either they moved it, or they didn't copy it, or...?

I'm not saying it's doing that, or thats what happened. Just that when their wasn't a names file. It also for some reason deleted all relevant text files. Which just seemed like an issue, for a small oversight.

If you can figure out a way to replicate the problems with a .names file, then I'll see what needs to be fixed in DarkMark. But if the problems only happen if the .names file is first deleted, then I would say the solution is to not delete the .names file.

You can take any piece of data like the images I shared above, and should get similar results.

Folder_example.tar.gz

If you ran this folder with no names file then, all the text files it has would be deleted. At least that is what I've observed when replicating this problem.