Different results depending on number of image sets processed at once

[RobertMtx]

Even with the Min tag fraction in batch and interrogations option set to 0, I'm seeing different results based on the number or variation of images processed.

If I process 2 sets of images with about 80 images in each, the tags look nearly identical to what is shown when processing one image at a time. But if I process 10+ sets of such images, where the images have completely unrelated content, the number of tags applied to each image is dramatically reduced to the point where only globally applicable tags are applied.

I'm not sure if this is a bug that reads the wrong value from the option mentioned above, or if this behavior is intentionally built in for some reason?

[RobertMtx]

I've been able to narrow down the issue. The problem seems to be related to the Min tag fraction in batch and interrogations option. Whatever is happening, it seems the default value of this option is being applied even when it has been changed to 0. This may be because the "defaults" of automatic1111 are not correctly adhering when the extension is loaded.

Basically, if I load up automatic1111 and drag the slider of Min tag fraction in batch and interrogations around and then back to zero, it seems to fix this issue. But if I save the default value of 0 using automatic1111 default settings, then restart, the HTML control shows the correct value of 0, but the extension still sees the default value of 0.05 for some reason.

My guess is the displayed HTML value and the actual logical value are two different values, and only the displayed one is being properly updated by automatic's default settings. So I guess the issue I should be reporting is that default settings are not being stored properly.

[picobyte]

Sorry I missed this, I'll have a look at it this weekend. The tagger does not allow tag values of zero or lower, those are omitted. This may be related, though I'd say returning a negative or 0 tag value is an imperfection of the model.
this filter occurs here
ah I think this was naively implemented here, I don't think this changes but always stays on 0.05, the default.

[picobyte]

Actually I don't see where this goes wrong. It may have to do with preset.json.