download the last version for android Hydrus Network 537

Pixel summary data is not cached long-term, so this routine takes a bit of extra CPU.

Furthermore, if one file is a png and the other not, this statement will colour green/red and bias heavily to the non-png, since the png is likely a bloated 'clipboard' duplicate that you don't want.

The duplicates filter can now detect if static images with the same resolution are pixel-for-pixel duplicates! If they are, it gives one of the standard 'comparison' statements on the right hover window. Some final duplicates work is done, and there is some polishing to the new tag autocomplete. I'd like to clear some of it up when I move onto this PTR work in 2-4 weeks with better overall local control of what tags you see from difference sources, moving solutions to 'I like this/don't like this' preferences away from the existing 'this is correct/incorrect' workflows. The 'what to do when a tag is deleted' workflow has always been a bit shaky.

This is a small thought, but is there any chance some of those files that couldn't take a 'pixiv work' tag actually had it deleted in the PTR (if you are adding to PTR)? If you hit F3 on one of them that you know didn't work and then hit the cog icon on manage tags and tell it to show deleted, is there 'pixiv work:123456 (X1)'? I think I have deleted some before after some large petitions came up on the PTR regarding some of this 'meta'-style content. I am not a big pixiv guy and didn't write the new parser, so I can't talk too cleverly. The actual json parsing rules for pixiv work tag look sensible and don't seem to rely on some clever lookup path that goes through r-18 gubbins anywhere. I just did a test for this:Īs in pic related, and it looked ok.

Download the last version for android Hydrus Network 537