/hydrus/ - Hydrus Network

>>12683

Ok, thanks. I'll give 'move left/right one' and 'move to first/last' a go, which gives you four options, and we'll see how that works out.

>>12710

Contrary to your opinion, and in agreement with previous anon, you are indeed a saint.

>>12713

Move left, move right, move first, move last

on the video tab I have

stupidly large remove

convert down

not hydrus

view again and decide

with

check before remove

music video

in for good measure

the first set is a wide range of reasons for a quick cull, the second set a second pass, with move left and right, I could easily set it up so its in between 2 tabs and move it to a second for more… hell, even a worst case scenario I could have multiple page of pages and filter that way.

not as set and forget as proper defined hotkeys, but should greatly increase the rate of sorting because I don't have to move them with the mouse anymore. definitely will be a god send once i'm out of video land.

Ill post this again in the new thread too,

I decided that the converted down images will get will get a rating of

Converted Down/Keep Large with 2 stars and not selectable as an option

it allows files to either be converted down and hidden from a search, or specifically keep the large file and hide it, also removed all files from the archive, everything needs a filter pass. these images that were converted down were interesting enough for me to keep/convert down but not really sure if I will long term storage them or not.

when I en mass rated them to converted down I got that error

InterfaceError

Error binding parameter 0 - probably unsupported type.

Traceback (most recent call last):

File "include\HydrusDB.py", line 561, in _ProcessJob

result = self._Write( action, *args, **kwargs )

File "include\ClientDB.py", line 12905, in _Write

elif action == 'save_options': self._SaveOptions( *args, **kwargs )

File "include\ClientDB.py", line 10112, in _SaveOptions

self._c.execute( 'UPDATE options SET options = ?;', ( options, ) )

sqlite3.InterfaceError: Error binding parameter 0 - probably unsupported type.

It doesn't seem to have made anything not work, everything's rated, so not sure what it is.

>>12753

Thank you for this report. This is an odd error–the problem here is that the options object is not being serialised into the db correctly. This is the kind of error I see when someone has like a 2GB subscription, and SQLite falls over trying to make a buffer big enough for it. The options object there is a small thing, automatically saved at various points. Perhaps it was being nullified in some way, or some invalid data was being added to it. I can't think immediately why it would be affected by a rating set event.

Can you say more about this rating conversion? You had a 2-star rating service as set up as under manage services, and then when you did a giant ctrl+a->f4->set rating->ok, it took a moment to write that and then popped up this error right at that time?

Had you set any other options recently, either in file->options or via one of the 'cog' menu buttons? Anything related to default sort based on that new(?) rating service?

>>12717

Ah yes, I also enjoy having a lot of useful files myself and having other people do the work, indeed.

anyone else cherry pick images then tag them individually as you store them in hydrus?

seems like if you mass download images you havent seen yet, you might have a bunch of images you dont care about

>>12758

I do both.

>you might have a bunch of images you dont care about

That's what the archive/delete filter is for.

I have 1TB of inbox to go through while 800GB are now properly archived, as in, I have personally checked them and stuff.

I've stopped working on dupes till the current dupe rework is done, since alternate not copying tags nukes my workflow, sitting at 80k dupes.

OP here, down under 60k dupes finally.

>>12758

I save those to Downloads with the most important tags in their title for later import.

I like how op starts off with how well he's been doing

>>12751

I love hydrus man and hope he is doing well in all aspects of his life.

>>12752

>>12751

I am overall healthy and in a stable money situation. I hope you are as well. I get blackpilled sometimes, but then I remember my true troubles are all internal and that I have a lot to be grateful for compared to my ancestors. I still want to keep pushing on Hydrus every week for the foreseeable future. I love imageboards and all other Anons, including you–the cheeky fun we get up to keeps my soul going.

>>12754

Based and Bloomerpilled

>>12630

I assume you have already done archive/delete filter on these files, so they are all in the archive? Otherwise I would suggest using inbox and archive to track files you have processed or not. You can send files back to the inbox for another round of archive/delete processing with Shift+F7, btw.

I have a couple of like/dislike ratings on my client that I use as pseudo inboxes. One is called 'read later' that I apply to anything I am archive/delete filtering that is like a big thread screencap or a 15 min video on some bullshit that I don't want to deal with in a quick filter. I enjoy like/dislike ratings since I can just click to quick apply and have some shortcuts set up for this as well. Maybe you could make a new like/dislike rating called 'videos to process' or something with some shortcuts to like/nullify to help you keep track of all this?

Mapping things to tabs is tricky. I'll be doing some Client API tab-access work soon, so I'll be thinking more closely about this in a couple weeks. The tricky part is mapping the action to the tab–'send file right one tab' is fairly easy to manage, and has a simple yes/no error state, but 'send file to page named "sexy elves"' is just that step more difficult to track and action and fail with (e.g. there could be two pages with that name). I like the idea of setting a current 'destination' tab in the current session that you could then action. I'll think about that. I've thought maybe having a shortcut or action for 'suck up these thumbs into the mouse' and then 'spit those thumbs back in here', like in cut and paste terms.

>>12636

Oh, well that's good to hear. I don't have any problem with the PTR, I just thought you did since people talk a lot about tags in it and I remember there was a lot of complaining a year or two ago about wrong tags. I just use it as an aid to my own tags to sort stuff, so I'm happy if you're happy.

I do want to try running my own PTR and file server with Hydrus if I ever get the money and time, so if I do I'll give feedback.

As for that workflow idea, I'll give it a try with some files once I finish with my duplicates.

>>12633

I suggested 30 minutes as the obviously safe option, where no one could possibly watch a preview for that long, but the majority of AFK sessions would be longer than that. I wouldn't expect to see much reduction in sessions pruned by going with 10 minutes, but who the hell is legitimately watching the preview for 12 minutes and wants that time recorded?

Honestly, I'm not convinced this needs to be a setting. 10 minutes is way more than almost anyone will ever watch in a thumb. 60 minutes would cut out the vast majority of AFK sessions. It's such a broad range to work in that 30 minutes would do the right thing in 95%+ of cases (and I'm being cautious with my numbers), so why add more clutter to the settings for something almost no one would need to change?

>>12656

>>12654

Thanks lads, only catching up now. This isn't in yet, but I'll keep this in mind as I do this system.

I'll do min/max for media viewer as well. Options are easy to add, and I know someone will want to say 'no minimum time' or whatever, so I'll throw them in for anyone who is interested. 5s/10m sounds like an ok default min/max.

I think I can catch a focus lost event, although some of that stuff is a little unreliable. I'll play around with it and we'll try iterating on this a bit.

>>9961

Wiki - https://wiki.bibanon.org/Main_Page

Matrix/Riot - https://riot.im/app/#/room/#bibanon-chat:matrix.org

discord (the right one) - https://discord.gg/phPHTEs

>>9960

For the love of god, DON'T use jQuery

http://youmightnotneedjquery.com/ and http://youmightnotneedjqueryplugins.com/

If you really need it, Please use one of these instead

https://tutorialzine.com/2012/04/5-lightweight-jquery-alternatives

http://kenwheeler.github.io/cash/ http://minifiedjs.com/ https://umbrellajs.com/

http://www.codingjack.com/playground/jquick/index.html https://grindstonejs.drzwebdev.com/

>>9960

https://github.com/mserajnik/hydrusrv-docker - Hydrus docker

https://github.com/mserajnik/hydrusrvue - Vue Frontend

https://github.com/mserajnik/hydrusrv - Media serving

https://github.com/mserajnik/quicktagr - media tagger with Szurubooru

https://github.com/mserajnik/szuruporter - Hydrus to Szurubooru

https://github.com/bakape/hydron - Hydrus rewritten in Go

Faptchas (classic)

https://github.com/314parley/Hydrogen

https://github.com/Laurelai/tsukiboards

MotionCaptcha

https://github.com/wjcrowcroft/MotionCAPTCHA

Audio Captchas

https://github.com/dchest/captcha

https://github.com/lepture/captcha

https://github.com/mojocn/base64Captcha

Captcha cracking

https://github.com/debasishm89/hack_audio_captcha

https://github.com/mikeyy/nonoCAPTCHA

>>9963

These are also good JQuery alternatives

https://github.com/madrobby/zepto

https://github.com/dojo/dojo

>>10008

https://gitgud.io/Dizmal/borehole

A fellow PHP-fren made this

>>12610

Namespaces are for meta information like the artist, name of the character, series the character is from, whether the image is lewd or not, etc. Tags are for descriptions of what the image contains. Short hair is a description of a character in the picture. With very few exceptions a namespace should only exist once per image. A notable exception is when a picture shows a character who exists in multiple series (eg. Rage of Bahamut / Granblue Fantasy or if you're someone who tags seasons as separate series) or characters from multiple series (eg. crossovers).

You're doing it wrong because you end up with garbage like the following on a single image featuring two characters.

>hair: long hair

>hair: short hair

>>12626

You're doing it better in terms of naming, but you're still doing it wrong.

>>12629

sounds like a very subjective description of namespaces to me.

not sure what the difference to you is between having two namespaced tags "hair:short","hair:long" and having two regular tags "short hair","long hair". Either way you have two tags.

In fact, using namespaces liberally for tags that are important to you (e.g. if you like to add lots of hair descriptors) is useful because the tags will be grouped together when displayed. When checking which such tags are already on a file, it is much easier to find them if they are grouped together.

Maybe you have almost entirely files which contain only one character? I know I don't

>>12593

>>12594

Yeah, try tag siblings:

https://hydrusnetwork.github.io/hydrus/help/advanced_siblings.html

The system is very imperfect, but it generally works. More time will be put into this this year, including better clientside preference management for tags synced over the PTR.

>>12596

There is no solution for this yet. I expect a future version of the tag siblings system to allow some sort of regex-based replacement (think a global rule for 'replace all "\s" with "_"') that will allow this.

Since desiring underscores to either go away or be mandated is common, I am likely to hardcode a solution to manage this earlier than a generalised regex solution, but the tag siblings system just isn't clever enough to handle it yet.

>>12629

>>12632

I have yet to come down to a good description for what namespaces are myself. Here is my current first draft:

Namespaces are good when:

They are a higher category (evangelion is a series)

They are useful to highlight (characters are important)

They are useful to search for (creators are often searched for, and 'creator:*anything*' has value)

They are useful to group together (multiple creators is useful to know, when listed next to each other)

I've been approving 'clothing:' siblings on the PTR for a little while now and I overall like it. I'm mixed on some others though. My ideal solution here is to extend tag siblings to allow clientside preferences and then for you to say "If a group of siblings includes one with 'hair:' namespace, prefer that". I have found that it is easy for users to objectively agree that 'hair:long hair' and 'long hair' have the same semantic meaning, but the big subjective disagreement is over which is better.

An actually bad namespace, imo, is one that breaks the first rule above. 'male:erection' is an artifact of how some gallery sites do various female/male focus on tags, but I would rather 'male erection' (which could nicely have parents 'erection' and 'gender:male'). 'erection' is not a 'male'. Also 'erection:male'.

'general:coffee cup' and 'object:pencil' are technically correct but overspecific for most users, but again I think the specificity of namespaces is highly subjective, so the true answer is to let users define what namespaces tags could have and let them then customise what they prefer to show.

If you were going for 'hairlength:short', I'd probably try to aim for hairlength:short hair for similar reasons, or go to the higher category of 'hair:short hair'. 'shoPost too long. Click here to view the full text.

>>12510

Yeah, I agree on hotkeys. I'll stick them on the tooltips, I think, including for the navigation buttons for skip and go back etc… I'm not super keen on hardcoding this as I'd rather move forward on a system for buttons to understand hotkeys and present this info dynamically across the program. I'll think about what is sensible for now.

>>12517

>>12518

Hey, the program is on Python 3 now. If you are coming from before 335, please check that release post: >>11238

I think that is probably your dll problem here. Read the post for your situation, but basically you'll be doing a 'clean' install to wipe out the old conflicting Python 2 dlls before reinstalling a new version. Let me know if you run into trouble, and make-a/feel-good-about-your backup before you do it.

>>12520

Yeah, I don't like the sort of the sort. I've found it tricky to figure out a concise way of saying some of this stuff, like age vs time imported.

Yeah, perhaps something like 'sort by dimensions: width' would help here to group them better. I'll make a job and think about this a bit.

>>12525

Thank you for this report! Sorry, I fucked up the new focus logic when adding the always-on-top ability. I'll 99.7% have this fixed for 352.

>>12554

personally, just sorting them between file facts and database entries would be enough.

database would be things like tags, rateings, so on so forth that is really only applicable in program

file facts would be things like pixel amount, file size, hight, width so on.

this would at least clearly separate the two.

>>12551

now that you say putting it on another monitor, a floating window would be perfect.

Currently I have a 4k monitor, I have the files open as the right half of the monitor, a magnifying glass as the second monitor, and if this stuff was floating, I could easily possession it wherever the hell I please and not care at all. not sure how easy that would be but that would be a solution that works as a fits most use cases.

VOTE DONE

I am just putting my 351 release post together now. 'Improve duplicate db storage and filter workflow (need this first before alternate files support)' stayed on top for almost all of the past two weeks and is still top now, so that is the winner.

This item will involve overhauling the duplicate db structure to be more efficiently group-based rather than pair-based and will continue the recent ui-side workflow improvements. If there is time, I might even make a skeleton for optional auto-decision making on things like 'if one file is jpg, the other png, and they have the exact same pixels, set the jpg as better'. I will keep file 'alternate' support in mind throughout.

Thank you for voting everyone. I appreciate your input and the surrounding discussions over what to do with hydrus.

>>12505

I have 2 suggestions for the duplicate auto filter

1a) there was a thing a number of years back that would take a png and a jpeg 95% and show you a negative that would be the difference in quality, I know this can also be done with music to show what's lost in compression. would there be a way to pair files off in something like this

1b) Would it be possible to pair files regardless of size or ratio differences off in this? this honestly may completely fuck the results but I have run into cases where the file size is half the normal one in ratio and its fairly obvious whats better, and having an auto duplicate sorter to at least give it a once over for a possible determination

1c) If you do something like this, I would assume it has to be done at or around run time as in no database of files, would it be possible to show the negative so it may be easier to see where my eyes should focus

1d) because I personally subscribe to a 'some loss is acceptable depending on the circumstances' way of thinking, would it be possible to have a better worse check determine one image was better but go with the lower quality one because it fell under a certain % difference?

1e) because of 4chan and a few of the people there I know another thing they did to piss space away, someone posted an image, and for the entire thread all he did was reopen and resave the same image as a jpeg over and over again, slowly corrupting it, I know that if I had an image set like this, I may have gen 1 (good) get replaced with gen 2 (1%wrose) and maybe that one is accepted, but then it goes down from gen 2 ot 3 ect to get 150 where its a fucking wreck. I know its not likely, but a fail safe in automation against that would be greatly appreciated where if it sees 3 images deceptively close in quality to each other it triggers manual review immediately.

2a) Due to the /trash/ scalie thread spam, I was made aware of a method to troll who use an auto dup filter, they have the base image, then they make a png, corrupt the fuck out of it, and that bloats the png, which in a filter Post too long. Click here to view the full text.

>>12506

Check the big list of repos in >>12295 especially https://github.com/andrewekhalel/sewar (it will come in handy)

>>12511

>>12506

1a)I am chiefly limited in how much time I have. I'd love to do more complicated autodecision workflows and backup ui, and I think that sort of thing would help a lot, but I don't have time in this rewrite. I also read up on some jpeg quality estimation here https://www.politesi.polimi.it/bitstream/10589/132721/1/2017_04_Chen.pdf , but it is too complicated for me to implement in the time I have. I would also like to focus on the db side more in this cycle.

1b)I am moving to a simpler comparison system in this rewrite. You'll always be seeing files compared to the 'best' of a group once it is done, which should exaggerate filesize and resolution differences. I am squeamish about autodecision on filesize or resolution alone as there are plenty of stupid bloated pngs of jpegs out there, but I think that bias could be part of a larger system that takes multiple variables to auto-decide.

1c)Sorry, I just don't have time to write clever ui like this atm.

1d)Yeah, I am afraid of the edge cases here. My thrust will always be default to off and lots of user customisation. I'll prep any auto-system with rules like "if exact same pixels and one is jpeg one is png, the jpeg is better", but I'd like for you eventually to be able to write your own rules for what you want out of it.

1e)Yeah, single pixel edits are a problem here. In a future iteration of any autodecision system that took multiple rules to make decisions, I think a blanket "if one pixel different, the older file is better" could be the ticket. There's also issues with file metadata being stripped or altered by CDNs.

2a)Yeah, that's the difficult stuff. Any dupe filter can't be simple, or any simple rules should be able to gauge certainty and pass the decision up to human eyes when something smells fishy. This claPost too long. Click here to view the full text.

>>12542

yea all of 1 more or less required the image difference comparison to be a thing.

as for 1e its not even single pixels, its resaveing the exact same image over and over again as jpeg slowly corrupting it over the course of 100-150 images. that's where I see a slow better worse auto filter jumping from a good image and quickly ending with the most corrupted one is no fail safe was implemented.

>>12458

>and deleting files without leaving a delete 'record'

Right when I was going to ask about that. Thanks.

I think a better term for this action is 'forget'.

How does deletion reason/forget/… work with "archive/delete filter"?

>>12481

With delete, I don't mean delete with reason, what I mean is in current hydrus, there are various hotkey presets depending on what you are doing

So when you get into a delete menu, its hotkey preset takes over, and like I said in my case it would be 1-8, pressing the number could select one of the reasons.

Like I said before, my use case for this is still quite a bit down the road because mass culling is still easier and will be for several months. no idea if this is possible in the current shortcut method but if it is, it would be something to do to fill time if its easy enough.

as for manga i'm leaning on keep the 'money shot' pages

If I read the manga, it will make me laugh/make me want to re read it, if I didn't, I still may get something out of it, if its porn, well… that one obvious.

as for conversion…

personally with that 112mb attrosity, I got it down to 1.5mb after fucking with settings in handbrake for a while

For what to do in the future… that a a bit harder

first you would need a 'lossless' conversion, as some animated gifs are bloated to hell and back, but they have very clean lines, and a conversion even as lossless may end up at a lower file size then non converted.

second you would need a near placebo preset, not quite there but still high quality

third would be a high quality compression, a good catch all for everything,

forth would be another relatively high quality preset, lower but still a catch all

and below that some fuck this presets, I have a few videos where they made a music video of sorts, but it's over 200mb and the only thing that's worth anything from it is the audio, but the visuals are a nice tPost too long. Click here to view the full text.

>>12488

I dove into the code here as part of my research into the dupe db overhaul yesterday and discovered some problems in my original 1.0. I feel less confident about it as I did for certain edge cases where 4+ files want to figure out what worst->best order they should go in. What happens to tags and whether the 'worse' of a pair is deleted is up to the duplicate merge options (check the cog icon on the dupe filter to edit these). I believe the defaults are to delete the worse of a pair, but if for some reason yours is not set this way, I think this will help your processing. Clearing 'bad' files out of the local file domain clears out some unusual AB, BC, AC pair comparisons the current system wants to do.

My plans for the new storage system will do away with the over-autistic comparisons here and push for a simpler model with groups of dupe files with a defined 'best quality' King.

>>12498

The archive/delete filter still uses the old delete system atm, just sending files to trash with a default reason. I would have added the new delete dialog to it, and likely will in future, but the batched way archive/delete filter stores up and commits its actions make it more complicated to integrate, so I put it off.

>>12499

I will not hardcode number shortcuts for certain controls for now. I think macros to tab&space navigate the dialog are your best bet atm.

That's interesting about SFM, I didn't know about the image-based rendering. I had heard the software tends to crash a lot, especially as artists are often working on older laptops etc… Sounds like a nightmare. I assume there is no easy one-click open source workflow–that for instance just neatly eats up their pngs and throws them at ffmpeg–for these users, unless Handbrake can do something like that?

>>12504

Yeah, we might be fucked. 560M mappings already. I'll probably reserve the next 'big job' after this dupe work to trying to sort it out.

A more temporary fix I may apply is a daily 10GB limit, which will stop uploaders from sending so much and throttle the incoming tags more smoothly over the month.

>>12509

*sigh

If only we have a more web-friendly way of dealing with tags… Not saying social media works, but it is the first thing that came to my mind e.g. voting, crowd moderation etc. using psuedonym? Sorry dev

>>12513

No worries. Having too much is a nice problem to have, and I have many ideas on how to mitigate our problems. Clearing out the (1) and done tags like 'title:tuhentu honeuhoen tuhoe nthn', or giving users options on how much of that stuff they want to sync with, will be a likely next step. There is plenty more we can do here, and I am keen to keep on pushing. I am committed to keeping person-to-person interactions Anonymous in my code–boorus already do username-based curation much better than I have time to do–but I know I can give users more power to share and sync just what is useful to them.

bumping this so that we can discover more uses of API better.

The Kinoshita Collection Danbooru { "id":3382448, "source":"https://i.pximg.net/img-original/img/2019/01/13/00/12/24/72630169_p7.jpg", "md5":"d5a650a70fca03ff391b50fc255dcb26", "rating":"s", "image_width":550, "image_height":770, "tag_string":"1girl :o ahoge bangs blue_eyes blue_hair blue_ribbon blue_skirt braid breasts collared_shirt eyebrows_visible_through_hair hair_ribbon juliet_sleeves kazutake_hazano long_sleeves looking_at_viewer parted_lips puffy_sleeves ribbon shiro_seijo_to_kuro_bokushi shirt short_hair sidelocks simple_background skirt solo underbust upper_body white_background white_shirt", "file_ext":"jpg", "has_large":false, "tag_string_general":"1girl :o ahoge bangs blue_eyes blue_hair blue_ribbon blue_skirt braid breasts collared_shirt eyebrows_visible_through_hair hair_ribbon juliet_sleeves long_sleeves looking_at_viewer parted_lips puffy_sleeves ribbon shirt short_hair sidelocks simple_background skirt solo underbust upper_body white_background white_shirt", "tag_string_character":"", "tag_string_copyright":"shiro_seijo_to_kuro_bokushi", "tag_string_artist":"kazutake_hazano", "file_url":"https://danbooru.donmai.us/data/d5a650a70fca03ff391b50fc255dcb26.jpg", "large_file_url":"https://danbooru.donmai.us/data/d5a650a70fca03ff391b50fc255dcb26.jpg", "preview_file_url":"https://raikou4.donmai.us/preview/d5/a6/d5a650a70fca03ff391b50fc255dcb26.jpg" } Moebooru (JPEG is the file of Danbooru) { "id":276945, "tags":"ama_mitsuki brown_eyes brown_hair gloves hat original panties pantyhose skirt underwear", "source":"

 The Bisimplex collection Danbooru { "id":3382448, "score":1, "source":"https://i.pximg.net/img-original/img/2019/01/13/00/12/24/72630169_p7.jpg", "md5":"d5a650a70fca03ff391b50fc255dcb26", "rating":"s", "image_width":550, "image_height":770, "tag_string":"1girl :o ahoge bangs blue_eyes blue_hair blue_ribbon blue_skirt braid breasts collared_shirt eyebrows_visible_through_hair hair_ribbon juliet_sleeves kazutake_hazano long_sleeves looking_at_viewer parted_lips puffy_sleeves ribbon shiro_seijo_to_kuro_bokushi shirt short_hair sidelocks simple_background skirt solo underbust upper_body white_background white_shirt", "file_ext":"jpg", "last_noted_at":null, "parent_id":null, "has_children":false, "has_large":false, "is_favorited":false, "tag_string_general":"1girl :o ahoge bangs blue_eyes blue_hair blue_ribbon blue_skirt braid breasts collared_shirt eyebrows_visible_through_hair hair_ribbon juliet_sleeves long_sleeves looking_at_viewer parted_lips puffy_sleeves ribbon shirt short_hair sidelocks simple_background skirt solo underbust upper_body white_background white_shirt", "tag_string_character":"", "tag_string_copyright":"shiro_seijo_to_kuro_bokushi", "tag_string_artist":"kazutake_hazano", "tag_string_meta":"", "file_url":"https://danbooru.donmai.us/data/d5a650a70fca03ff391b50fc255dcb26.jpg", "large_file_url":"https://danbooru.donmai.us/data/d5a650a70fca03ff391b50fc255dcb26.jpg", "preview_file_url":"https://raikou4.donmai.us/preview/d5/a6/d5a650a70fca03ff391b50fc255dcb26.jpg" } Moebooru { "id":276945, "tags":"ama_mitsuki brown_eyes brown_hair gloves hat original panties pantyhose skirt u

The Andy iOS collection

Danbooru
created_at: Date string in the format "yyyy-MM-dd HH:mm:ss"
rating: possible values - e, s, u, q
md5: string
height: Int
width: Int
preview_url: URL
large_file_url: URL
sample_height: Int sample_width: Int
tags: STring with tags, each tag separated with spaces
id: Int source: URL, String, or nothing

Moebooru
created_at: (This should return the number of seconds since the epoch and be a number)
rating: possible values - e, s, u, q
md5: String
height: Int
width: Int
file_url: You should try to return the full URL, including the protocol and host name (the app tries to build it when they are missing)
preview_url: Same as above
sample_height: Int
sample_url: string 
tags: String with tags, all separated by spaces.
id: Int
source: Where the image comes from. Can be a url, string, or missing 

>>12467

>>12468

>>12469

Really? https://pastebin.com/vzQTRFaa since ghostbin is shutting down

Thank you for this report. This actually isn't my code failing here, but the image library I use, Pillow. Just guessing, I suspect these files are slightly malformed (broken) and Pillow is having trouble dealing with them.

As it happens, I plan to do some cleanup work next week to have a different library, OpenCV, do the initial metadata parsing work here and improve reliability of metadata parsing overall. I will test these URLs once that is done and see if they work. Thank you for the examples!