[ home / board list / faq / random / create / bans / search / manage / irc ] [ ]

/hydrus/ - Hydrus Network

Bug reports, feature requests, and other discussion for the hydrus network.

Catalog

Name
Email
Subject
Comment *
File
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Options
Password (For file and post deletion.)

Allowed file types:jpg, jpeg, gif, png, webm, mp4, swf, pdf
Max filesize is 8 MB.
Max image dimensions are 10000 x 10000.
You may upload 5 per post.


New user? Start here ---> http://hydrusnetwork.github.io/hydrus/

Currently prioritising: simple IPFS plugin


File: 1426721772716.png (100.78 KB, 1624x1081, 1624:1081, 1327614072601.png)

 No.471


Drag and drop windows with tag rules. Show two windows side by side and one window can be programmed with the rule "ADD tag foo" and the other one has the rule "REMOVE tag foo, ADD tag bar" and you can drag and drop files to them.

Deriving tags from regex of other tags/namespace tags. A file has the tag "filename:big_ugly_name" and we could regex that namespace for another tag.

Tag sets with hotkeys: save a set of tags under a hotkey so it's quick to add them to a file while filtering

Opaque window behind tag list in the corner so it doesn't get hidden by picture background

Option to default certain mime types to be excluded from slideshow and only open externally, will help with videos with odd codecs that don't preview in the slideshow correctly

Option to specify hamming distance in "find similar images", you can't change the option once it's in the filter window and you have to enter the hash manually in the "system:similar to" option

 No.495

File: 1426967053743.jpg (326 KB, 1420x2376, 355:594, 60f16971d95d08958ec5da2d57….jpg)

Thank you for these good ideas. I have incorporated them into my to-do.

Drag and drop windows for tag rules is something I had never thought of, but I like it a lot. It could also do file uploading/exporting and other such duties. I want to add thumbnail dragging and dropping in future, so this could be a great extension of that code.

Internal tag conversion is something that has been on my radar for a while– particularly for large but finicky jobs like adjusting page:n to page:n+1 for two hundred files. I haven't thought about what the dialog would look like for such a complicated and powerful tool, though. Maybe split it into two halves, like LEFT: IF FILE MATCHES THESE PROPERTIES, MIDDLE: DO THESE THINGS. RIGHT: AFTER RUNNING THE SEARCH, THESE FILES MATCHED. THIS IS WHAT THEY WILL LOOK LIKE AFTERWARDS. YOU SURE YOU WANT TO DO IT?. Perhaps this is just an powerful formalisation of the drag and drop idea above. Perhaps I need to write a scripting logic for the program first, so people can do these mass edits a bit easier?

Allowing more complicated hotkeys could also use this scripting/macro language, and would be the easiest of the three things to do. I'll make a note to do that first.

Making the media viewer's elements float above the image on mouse-move is high on my to-do list.

Most of the video and audio stuff was cobbled together, and I need to revisit it. Adding default action options for different mimes is a good idea.

Find similar is another thing I threw together. I've been meaning to expand it for a long time, but never got around to it. I would still like to add a 'find me all the dupes in my collection', but there are several big new things I need to create first. For now, I can definitely add a custom default distance for the menu entry.

 No.513

Not OP, but I have some suggestions as well. I'm new to this program- just found it several hours ago, so I might have some misunderstandings. I have been waiting to find this type of software for a decade. Thank you.

The installer defaults to c:\hydrus, saying that "program files requires admin". Not necessarily true- give the user write access to the database folder, or simply leave it writable by the 'Users' group. Done. This is what steam does.
But hydrus only has one database, correct? Therefore, in a multi-user environment each user must have their own installation of hydrus. The convention for a program without multi-user support is to default install to "c:\users\[username]\appdata\roaming\hydrus". Use the following variable, don't hard-code the path: "%APPDATA%\hydrus". If you point to appdata by default, be sure that you do not have the installer request UAC elevation, as it currently does. I'm not intimately familiar with install scripts, but I believe it should be possible to only request elevation if the installer needs it (eg should the user manually enter 'program files' as the destination). Just remember to manually grant database write access to the initial user (if not the Users group), NOT the elevated user, and you should be able to install to any directory without issue.

I'd like to suggest a random sort order where multi-page images are kept together. pixiv often has two or more images that are meant to be viewed in sequence, and I'd like to have a sort order preserve this in an otherwise random slideshow.

Thumbnails larger than 200x200 and/or display larger thumbnail on mouse-hover.

I'm not entirely sold on the *complete* abandonment of file names. Correct me if I'm wrong, but there are no file names in hydrus, everything must be a tag. Tags are for navigation, and file names can contain information that would just clutter my tag list with useless bloat. Example: MPCHC video snapshot creates a file with name "[filename][timestamp].png. The file name usually contains the episode name and number. There is no benefit to marking the episode name, number, and timestamp as tags, but this is also information I don't want to discard. If hydrus simply kept the file name… Also, the way you have hydrus store images sort of prevents operating on a picture library with external tools, such as a duplicate image scanner. Without human readable file names or a coherent, modifiable folder structure, I would have to export my entire database, delete all images in the database, do whatever needs to be done to the files, and re-import them. Why does hydrus simply not maintain a database of files as they are? Why must it completely take over, move and rename everything? It seems unnecessary and overbearing.

The internal image viewer navigates through pictures within the currently defined filter. If you open an image with an external viewer it will navigate effectively randomly; whatever pictures happen to be stored next to the one you initially viewed. Perhaps you could implement the option to hardlink all images in the currently defined filter to a temporary folder. External viewers would become more useable.

Different slideshow schemes. Let's say I have a set of tags 1-9. I want to view a slideshow of tags 1-3, then after a set time (and/or triggered by a keybinding), I want the slideshow to display tags 4-6, and after that, 7-9. Basically: just the ability to queue up different slideshows in advance.

Thanks for your time.

 No.514

A few more things:

tag censorship of namespaces appears to be buggy or underdocumented. Inputting

page:

into the blacklist does not get rid of pages. If I literally define page:1, that explicit page will be censored.
The input textbox doesn't autocomplete tags like every other tag searching text box in the program does.
There is only a blacklist OR whitelist- why not both?

Censoring all namespaces with : works, and that allowed me to see that the censorship doesn't work in the way I had thought it would. Maybe I'm not in the correct mindset yet, but I navigate my picture library by choosing tags to filter by. By default, hydrus is blank, so I always throw in a system:everything. This displays all the tags in my library in the "selection tags" box, and it is from here that I choose tags to filter by: it's much easier to scroll through a list of tags than it is to try and remember what words I may or may not have used to describe my pictures. In no way, ever, is the page: namespace a useful sorting tool- HOWEVER it is necessary data to have for sorting, and I do appreciate that the page number is shown on both the thumbnail and in the internal picture viewer. Censoring page: removes it from the thumbnail and internal picture viewer. All I want is to hide tags from the "selection tags" list! Could you implement a "hide these tags from selection tags" list please?

 No.515

>>514
>In no way, ever, is the page: namespace a useful sorting tool-

derp, I meant it's useless for filtering. It's useful for sorting

 No.516

>>513
Glad to see more people interested in hydrus.

> Databases and multi-user

While hydrus by default only uses a single database, you can extend it by using some special databases with hash and tag information ripped from websites that collect such things.
In addition, hydrus uses the mobile installation method, with the program and its data closely coupled, which I find a much better way to do it.
I find your interest in this aspect of application development interesting. Could you expand upon why this should be a feature?

> Filenames and location of files

Filenames in and of themselves can be cluttering, agreed, but by making pretty much everything a tag, you guarantee much easier forward compatibility. Using the "title:" namespace should do what you want.
The reason to "take over, move and rename everything" comes from its mobile nature. This is one area where I would like some more options though.

> Slide show

With that much power you might as well just plug a scripting language into hydrus.

> hide these tags from selection tags

This would help with a lot of other namespaces too, for example "title:". I would very much appreciate this feature.

 No.517

>>516
>Could you expand upon why this should be a feature?
I'm not sure I follow- I'm suggesting he follow the conventions of the OS. For example, a convention on linux is that you don't design your program to run as root. If a program does run as root, then changing that is more of a bug fix than a feature request. This context is not so dire, but the analogy is clear: I'm offering solutions to a problem, not asking for a feature.

It occurred to me that another way of doing the above would be to install to program files and have the database be in %APPDATA%\hydrus, that's probably the best way to do it, unless you want to keep the mobile approach and just install to %APPDATA%\hydrus. As for "mobile approach", well isn't that what the mobile, zipped version is for? There's no reason the installable version should defy host OS convention so there can be two redundant distribution methods.

>Filenames & 'taking over' folders/files

I would be more amenable to the way things are currently done if I could automatically tag everything with a filename: and folder: namespace upon import and hide it from the 'tag selection' as per my other feature request. If done right, exports could restore the files and folders exactly as they were. While this is indeed possible to do at the moment, you have to manually define the regex/tag pattern every time you import or export- which brings me to a new feature request: import/export profiles. Save a predefined set of conditions for future imports and exports.

>slideshow, might as well scripting language

Perhaps. I see hydrus as very similar to foobar2000: tags and the power to manipulate them. foobar2000 does not have a scripting language but it is possible to generate a set of playlists using tags, and bind keys to change the currently playing playlist. My feature request is best described as a set of playlists, which I don't see as a very tall or complex demand. I think a scripting language would be extreme overkill for such a feature.

 No.518

>>513

>I'd like to suggest a random sort order where multi-page images are kept together. pixiv often has two or more images that are meant to be viewed in sequence, and I'd like to have a sort order preserve this in an otherwise random slideshow.


As long as the order of the images is part of some kind of tag namespace it wouldn't be hard to add that. An option to randomize one namespace and keep all the others' orders would do what you want.

>If hydrus simply kept the file name…


I have a namespace called "filename" that I add to every file I import. If I ever want to get the original file back all I have to do is export it and use [filename]. This is the regex I use:
[^\\/:*?"<>|\r\n]+(?=\..*$)
If you want to add it to files you've already imported, just import them again and it will tag their existing database entries.

>Perhaps you could implement the option to hardlink all images in the currently defined filter to a temporary folder. External viewers would become more useable.


Oh I like this one, though I think read only symlinks would be safer. Otherwise it would be easy, create a folder named something meaningful from the search, and symlink every file into that folder.

 No.520

>>518
>An option to randomize one namespace and keep all the others' orders would do what you want.
I don't have any formal manga/comic collections where I would use series, volume, title, chapter AND page, so I don't want to presume how this should be implemented, but I don't think that accurately describes what I want. Perhaps this would require more than one sort rule to fully flesh out the idea for all use cases, but all I want is a given collection of pages to be presented in order. Perhaps we should define four sort rules:

random + preserve page order for title
random + preserve page order for chapters
random + preserve page and chapter order for volumes
random + preserve page and chapter and volume order for series

That doesn't even cover all possibilities. Optimally, sort orders should just be user definable.

>I have a namespace called "filename" that I add to every file I import

Yes, I saw the thread for "better regex" here, and I have been using the filename: where necessary, but it's a band-aid solution for a problem that hydrus goes out of its way to create! Hydrus hashes every image and renames the image files to their hash, correct? Then when importing a picture, if the file names match no duplicate is added. How about hydrus has the option to NOT move/rername files, and hashes are stored as a hidden tag (or otherwise in some form in the database)? This approach would actually be more efficient too, since it involves less read/write operations to the disk and relies on the database instead of the files. I get that you can live with tags and tags alone, but throwing out file names altogether is just needlessly limiting options.

Moreover the band-aid solution of creating a filename: tag doesn't address the issue that, once pictures are inside hydrus, access is relatively exclusive to hydrus, which is a problem. See next paragraph for an example.

>just import them again and it will tag their existing database entries.

Yes, I have noticed this and I appreciate it deeply. I have made use of it several times already. However, if I'm exporting the entire database to perform operations on the files with some other program, the import will not work unless I delete the database first. Changed files will be seen as new files: duplicates everywhere. Deleted files will still exist in hydrus' database… Not starting from scratch would just be a mess. Using some other program to operate directly on the database images \could\ work if hydrus is smart about handling unexpected changes, but from that program there will no identifying information on the pictures; this would prevent me from making an informed decision for a process such as batch removing duplicate images. If two+ pictures are near identical, I'd prefer to remove the one with less/no tags, but I will have no way of knowing which picture that is. Similarly, if I ever want to open ANY picture with ANY program, I can't use file -> open in said program anymore- I'd need to open hydrus, export the picture, THEN open it with any given program. If hydrus allowed having coherent file names and structures, I could process my library so that tags are listed in the file name. Do this, and hydrus will go from being a roadblock, to a lubricant.

>though I think read only symlinks would be safer.

symlinks require administrative powers under Windows, hardlinks do not, which is why I suggested hardlinks. If symlinks prove superior for whatever reason, then by all means it should be default in the linux version, and optional non-default for windows. I have to wonder how efficient the process of creating thousands of links is… we might run into a problem where it takes so long it just isn't feasible.

>create a folder named something meaningful from the search

I was thinking that it would be linked to a system temp folder- no need for a meaningful name. If you want to save the folder for later you can rescue it from the temp folder manually, rename it to whatever you want. Well, hydrus could automate this process for you too, if the dev feels so inclined to write it.

 No.528

Instead of starting a new thread I'll post my suggestions here too.

A "suggested tag" feature. When you're adding tags it should show tags most commonly used with the ones already added, as if you're doing a search for images with the incidence (desc) option. For example when I tag an image with character:alice margatroid it should suggest the tags blond hair, blue eyes, and hairband.

I don't mind that Hydrus renames and moves files into its own directory, but I would like an option to have the subdirs of client_files and client_thumbnails folders be stored as compressed archives (zips) instead of loose files. I currently store images this way and use a cbz reader to view them in order to reduce wear on hard drives. When you get larger collections (literally millions of tiny files) doing things this way almost becomes a necessity. Plus all that file slack adds up.

Lastly some minor changes that I think will make life easier.
An option to change the default tag repository when opening the manage tags window to a remote tag repo instead of local tags.
When filtering with the manage tags window open the left and right arrow keys should change images and apply tags on image change.
The hotkey to open file externally should open the current image when filtering.
Right click on an image -> favorite/dislike along with system:favorites and system:disliked or some other form of bookmarking images.
Some way to filter images into safe, questionable, and explicit categories. Perhaps this can be addressed via tags instead of adding a new feature?

 No.530

>>520

>Then when importing a picture, if the file names match no duplicate is added.


I'm not sure if you're saying that this is a problem or not. Yes that's how it works, since a matched hash is necessarily the same picture.

Hydrus makes the rather interesting assumption that an image is immutable, in the same vein as Tineye where there is One True Image representation of a particular artwork. Resized and watermarked images are indeed duplicates in the sense that they show the same artwork, but Hydrus isn't that smart, to it they're just different files.

As more people use Hydrus, we could end up with the interesting problem of lower quality images not getting all the tags of the higher quality ones in the tag repositories. Eventually we could need to start adding reference tags to images like "deviantart_resized_version_of:*hash*"

It would be nice if Hydrus had a simple way to replace files and keep their tags. Eventually it may end up using GUIDs for the files that reference the hashes. That would allow more than one file to be the same "artwork" or whatever the GUID represents.

But then you have the political problem of being the curator of the One True Artwork GUID Database. What if someone makes a competing program with their own GUIDs for artworks? Having hashes for the image primary keys avoids that potential drama at the very least.

 No.533

>>530
GUIDs would be step backwards to be honest. The whole reason hydrus uses hashing in the first place is to be as decentralized as possible, while still communicating with other clients about the same things.
I think this would be solved with the idea of 'hash siblings'. If a user find that one image is indistinguishable from another, but not entirely (resize, watermark), the user should be able to say that the images are siblings. Every tag one image receives should also appear on the other.
Assuming there are enough resized/watermarked image mappings in a repository, this might reduce its sized, in addition to time required to sync.
This is not a perfect solution though: You cannot add a tag exclusively to one image. If such a system could be devised, would it be applicable for use on different versions of images? (Inheritance would be too complex, and I think we need a flat structure for this.)

 No.536

>>530
>I'm not sure if you're saying that this is a problem or not. Yes that's how it works, since a matched hash is necessarily the same picture.

I know duplicates are identified by hash, but I was assuming (having not looked at the source code) that the actual comparison is done by checking identical file names during the import process. As in, "x file name already exists, therefore this image is a dupilcate". I proposed storing the hashes in tags (or in some form in the db) instead, and finding duplicates through that as a faster, less disk intense, doesn't require renaming and moving files, alternative.

>As more people use Hydrus, we could end up with the interesting problem of lower quality images not getting all the tags of the higher quality ones in the tag repositories. Eventually we could need to start adding reference tags to images like "deviantart_resized_version_of:*hash*"


I'm merely using hydrus for organizing my personal collection, so I don't comprehend the logic behind this. Why would you want a resized version of the original? Unless you mean an artwork that has been converted to conventional wallpaper dimensions. Otherwise, I don't see randomly cropped / lesser quality / watermarked / etc images as anything but garbage- which is why I occasionally need to process the *files* in my library by a program that finds visually similar images… but hydrus makes this a pain, for no adequately explained reason.

To be clear, I'm not entirely opposed to the move & rename the files in a non human readable structure- if it is done for a good technical reason. At the moment, there doesn't appear to be a reason other than trying to shape the way the user thinks about organizing pictures (and perhaps, prevent the user from interfering with the database in a way hydrus isn't yet prepared to handle).

You know what might work? If instead of copying files to the database, they're hardlinked to it. The database could rename the hardlink duplicate however it wants without issue. Hydrus would have to monitor the link status of files to keep the folder and database synced. For example: if a file were deleted from the user's Pictures folder, the corresponding file in the database would not be a hardlink and become a normal file. Hydrus could detect that and ask you if you want to remove it from the database (or move it to a trash folder for later review, similar to the inbox folder).

Oh and I have another suggestion. This has been bugging the hell out of me: I need to be able to select & delete multiple tags in the tag editor. When batch importing pictures, let's say 30/100 pictures have a meaningful file name. I generate a filename: tag for each, and I want to remove the 70 filename: tags with garbage strings. I have to manually remove each of the 70 tags, I can't select multiple and remove them in chunks. This needs to be addressed

 No.537

>>536

I also have not read the source code but my experience with importing an asston of duplicates suggests that filename is discarded immediately and duplicates are identified via hash. I think one of the first things Hydrus does when it imports an image is generate hashes, and if it sees a match in client.db it knows not to reimport the file (and instead to add any import tags to the existing record).

 No.538

>>537
>I think one of the first things Hydrus does when it imports an image is generate hashes

Undoubtedly; each image is renamed to its hash and stored in a folder named after the first two characters in the hash, so even without cross referencing hashes, a duplicate cannot be imported.

 No.540

Man I'm full of feature suggestions. Drag and drop the thumbnails in hydrus to interact with other elements from Windows.

For example, foobar2000 let's you drag a song out of foobar into a windows explorer folder. It will create a copy of the song you dragged in the folder you dragged it to. If you drag a song into another program (and the program supports opening files by drag and drop, which a surprising majority of programs do), the file itself (not a copy of the file) is opened in that program.

I see drag and drop import already works :)

 No.544

File: 1427574002281.jpg (1.54 MB, 1940x1264, 485:316, 567067091427b77b760f825462….jpg)

Wow, this thread got big! Thank you all for your comments. I can't really marshall my thoughts into anything that sounds coherent right now, but I've not replied to this thread for too long, so I'll apologise and just say a mix of things. If you would like a specific response to something I miss, please say so or send me an email.

I mean for hydrus to be a store for files that are 'complete'. Such files can have their metadata changed, but there is no reason to alter their content. They are read-only.

Curating a thousand files in explorer is easy, but a hundred thousand is impossible. I see no point at all in trying to manage that many files in a brittle directory structure.

Throughout development, there has been a temptation to permit links, to allow hydrus to manage files at a remove, in their original locations, but this betrays my two former points. External files are subject to renaming, editing, or deleting, and they remain in an impossible-to-manage structure.

Filenames and folders are useful for things you are working on right now, where you might have several versions, or the program you are using to edit relies on filenames to manage library imports or whatever. The only file that should be imported to hydrus here is the final .png or whatever that comes out of the whole process.

Filenames and folders are also useful for a few hundred files, perhaps to be wrapped up in a zip and sent to a friend. Hydrus tries to support this with its export dialog.

Filenames and folders are not useful for storage or search, which is mostly what hydrus aims to do.

Any useful filename data, like in "artist_name-series_name-chapter_24-page_10.jpg", is better parsed and stored in an intelligent database that can regurgitate that information at will. Adding filename: namespaces is fine, but I think that data is better slowly converted to more granular and powerful tags. You can go tags->filename easily, but filename->tags takes more effort.

>>537 Has it right on hashes; the database stores a decent amount of metadata about files, including hash. Those hash indices are cross referenced whenever needed–the actual files are only ever loaded when the whole file is needed for something (display, uploading etc…). When a file is imported, its hash is calculated and then checked against the db–if it is already in the db, it tells the import controller 'redundant' so it can report that and move on to the next file. There's a fair amount of similar checking for image URLs as well, and md5 hash for APIs that report that.

>>513

I don't really want to mess around with %APPDATA%, because I want to keep the program together in one place. I want the program to be portable, easy to backup, and able to run from multiple locations at once without conflict. The Windows installer violates this, but I make that release to be a simple solution for people who don't want to mess around with extracting archives.

Having said that, if there is a good way to set the proper user access control to the db directory under program files with ISTool, which is what I put the Windows Installer release together with, then I am interested to know.

Keeping short sequences of images together is a continuing problem. page namespace works well for large groups, but not small. I may create a new file format, like .cbr is used in online comics, to represent these collections as single multi-page units.

I'll have a look at tag censorship for namespaces; thank you for reporting it. I'll also have a think about options for namespace hide on the 'tags in selection' box.

>>528

Suggested tags is something I definitely want to do.

You can change the default tag repo in file->options->gui.

Page up and page down can do that for the manage tags window right now. I can add this to options if you want, so you can change it to whatever you want (although binding left and right to a text control can be a problem, because then you can't use those buttons to move the caret around).

I haven't touched like/dislike and numerical ratings in a long time. I want to get back to them.

Doing safe/questionable/explicit has been tough for me to think through. I think you are right, saying do it with tags, probably with a 'safety' namespace or whatever. It is really subjective though–maybe it'll be better done with a numerical rating? If people want to filter safe vs explicit, I now suggest they just run two clients–one for sfw, the other for nsfw and anything else private. That way, they can browse their sfw client with someone looking over their shoulder and have nothing to worry about.

>>530

At some point, I want to make a service to accept and sync that sort of metadata to clients. I'll be writing a better dupe checker as well, and add a gui that'll show two very similar images to the user and ask questions like 'which is better?' and 'should tags be merged?'. The complicated parts of that data will be made automatic for users, so images will be replaced/rotated/whatever a bit like tag siblings are now. I'll run a public service, and anyone else who disagrees with my ruleset can run their own. I hope this is a decent compromise between the current mess and the impossible pursuit of 'file purity'.

>>536

I will see about selecting multiple tags–thank you for the suggestion.

>>540

Export dragging is unfortunately a massive pain to code. I have tried several times to figure a way to do it, but I can't find a wx-compatible multiplat solution for virtual file drag and drop. Dropping real writable files with nice filenames is easy, but I want to insert an interim step that'll copy and rename, which I can't figure out in wxPython.

 No.548

>544
>I mean for hydrus to be a store for files that are 'complete'. Such files can have their metadata changed, but there is no reason to alter their content. They are read-only.

I think you've mentioned this is a feature you'd like to expand upon, but my problem is largely duplicate images that don't have exact hash matches. Until hydrus can process the entire library for duplicates, instead of just finding duplicates of just one selected image.. It will be necessary to periodically scan the library with an external program to find clutter.

>Curating a thousand files in explorer is easy, but a hundred thousand is impossible. I see no point at all in trying to manage that many files in a brittle directory structure.


I have fifty thousand pictures, but I see the value in having some easy access folders of pictures. I have a reaction images folder that is manageably small and is faster to access via Windows' indexed search from any given program's file>open prompt, than by starting up hydrus, copying the file location. I have a separate pornographic collection of images which I keep stored on a separate, encrypted drive, and I'd like to NOT mix those in with normal pictures. Regardless, I do feel you might be discriminating against potential users with smaller libraries that still want to benefit from hydrus? Well, I'll drop this because I think I'm starting to sound a bit entitled to have my free software exactly the way I want it. I suppose I could run a separate instance of hydrus on the virtual drive, and keep the reactions folder in synchronized export.

>Keeping short sequences of images together is a continuing problem. page namespace works well for large groups, but not small. I may create a new file format, like .cbr is used in online comics, to represent these collections as single multi-page units.

That sounds like a fantastic solution. Maybe add support for downloading multipage images from pixiv while you're on that line of coding.

>Export dragging is unfortunately a massive pain to code. I have tried several times to figure a way to do it, but I can't find a wx-compatible multiplat solution for virtual file drag and drop. Dropping real writable files with nice filenames is easy, but I want to insert an interim step that'll copy and rename, which I can't figure out in wxPython.


I'm not sure what you mean by copy and rename, but if I'm dragging pictures out of hydrus I do not expect them to have nice file names. I'd be perfectly happy with just the {hash}.{ext} file being delivered on drag and drop.

 No.551

>>544

>Keeping short sequences of images together is a continuing problem. page namespace works well for large groups, but not small. I may create a new file format, like .cbr is used in online comics, to represent these collections as single multi-page units.


For the moment, I've made a sort order of "creator-title-page-filename" that will sort by the page namespace if I've made one, but if not, the filenames likely have page numbers in them and will keep the files in order.

 No.552

>>544
>You can change the default tag repo in file->options->gui.
>Page up and page down can do that for the manage tags window right now.
Thanks. I managed to overlook these.
>I can add this to options if you want, so you can change it to whatever you want (although binding left and right to a text control can be a problem, because then you can't use those buttons to move the caret around).
That won't be necessary. The problem I had was that I was using the arrow keys to change image and opening the manage tag window prevents those keys from doing that. Adding new tags will go much smoother now that I know page up and page down also change the image and that they do so while the manage tag window is open.

As for safe and explicit using a new tag namespace seemed to work well on my local tags, but there was no one to disagree with my opinion. Something else to consider would be having status decided by the image's tags. Images tagged with explicit tags 'sex, blowjob, handjob, etc' also get explicit rating automatically. Not that I'm opposed to such things. It's just nice to be able to see only safe content when looking for things like image macros, guides, wallpapers, and other times it's nice to be able to search for only explicit content because reasons.

 No.562

I'm trying to download a tag of 800 images right now, and I just got 15 failed downloads. And I'm right in the middle. They were mostly 503 errors.

So now my options are to suck it up and give up, or restart the entire download and wait 2 weeks till the slow-ass downloader gets to that part. Sometimes you get a link to the image (that you have to re-type out yourself if you want to retry) but not this time.

Can we PLEASE finally get some proper handling of download errors? Because what hydus has right now is a joke. On one hand I remember you talking about being nice to the various booru sites when scraping tags, which I understand perfectly, but then there's this shit.

 No.571

File: 1427732232086.jpg (135.83 KB, 1280x886, 640:443, test1.jpg)

>>562
Downloading is complicated. There are a lot of unknown factors when communicating with other server, especially when those servers are hostile to automated downloads. This is properly not something hydrus_dev wants to spend their time on.
There is a solution though, and this is more a feature request than anything else:
hydrus_dev, please expose some sort of interface for us to create downloaders. This would allow us that care about this to quickly respond to site changes or add new sites, and create robust interaction code, while you can ignore all of this entirely.

 No.573

The other problem with using hydrus for personal use and sync from a laptop is that hydrus cannot view images remotely. Things that would be perfectly viewable over samba are downloaded, and the download process, as mentioned above, is annoyingly prone to failure.

Unless hydrus implements some local network conveniences within the client/server, or unless hydrus stops taking over files… I don't think hydrus will be an effective tool for a personal collection of images.

Like I keep saying, the insistence on taking over the files creates problems…. As is, hydrus is only good for personal collections if you don't use the hydrus server and exclusively access pictures from that one computer (eg not over LAN).

Maybe there needs to be a fork of hydrus with a focus on home users, rather than massive collaborative libraries.

 No.574

>>573

you could put your Hydrus folder in Dropbox or set up a cross-network XXcopy script that runs in the middle of the night every night or use one of a million other generalized solutions for synchronizing directories between multiple devices that you own.

 No.575

>>574
>>573

Hell, I primarily use Hydrus on my desktop computer over a Splashtop remote connection. That'd work just as well, better even, on a laptop over LAN than it does on a tablet over LTE.

 No.576

>>574
Dropbox/cloud in general: No.

Syncing hydrus itself: Not a solution. That would mandate that I only ever make changes from one computer, because when syncing, the database file will be replaced, not merged.
Also, this method requires that I have the space for it on every laptop I use it on, and pictures can only be accessed on the laptops/PCs I specifically prepare before hand.

Using RemoteDesktop is the best solution so far, but… Really? That's just a pathetic work around for, again, a flaw that doesn't actually need to exist.

I'm just going to be super blunt: I have a collection of pictures I fap to regularly. Hydrus' tagging is a blessing, but the accessibility implementations are a curse. I had previously put pictures in folders and subfolders, which effectively means that any given picture can have one tag and infinite parent tags. For example, a folder of ahegao, with subfolders 'exhausted' 'shocked'. I use any given image viewer to create a slideshow of any number of folders (eg tags) and fap away. Hydrus lets me apply multiple tags without having to define a picture entirely by one trait, but then denies me simple, functional access.

It would probably be easy to implement an option, "remote files are on LAN" for the files service. If this option is checked, the viewer, "right click > share", etc operations would know the files are located remotely (\\pc\share\db\server\00\hash.jpg)
The user would have to set up the share and there'd had to be another option "database location" so you could type in the exact location of the db folder…

 No.577

>>576
>I'm just going to be super blunt
I forgot to mention, these pictures are stored on an encrypted virtual drive on a remote PC. Hydrus interferes with the encrypted part (is it possible to run two servers on one PC?) and the remote part. Yeah, I get that tags are super flexible, but hydrus itself is incredibly inflexible.

At this point I'm really just considering using hydrus to help tag everything, but once I'm done I'll export pictures with the tags as the file name. Maybe I should take this opportunity to learn python and make a fork, if my requests are not agreeable with the dev.

 No.579

>>577

You can definitely run more than one server on the same PC as long as they are using different ports.

I can see wanting to be able to edit stuff remotely, but that's what remote desktop is for; for faptimes, a synchronization of the "master" DB on your main computer is fine because presumably you are not editing while fapping.

I seem to recall the dev saying he wants to majorly improve the server, but we'll see what he says to all this. I agree with you that it'd be hypothetically useful to have an instant-sync master DB on the server that all the clients seamlessly access remotely, and my understanding (though I don't use the server) is that this is not how it currently works.

 No.580

>>579
>I can see wanting to be able to edit stuff remotely, but that's what remote desktop is for; for faptimes, a synchronization of the "master" DB on your main computer is fine because presumably you are not editing while fapping.

Why are you adding unnecessary complication? Syncing takes time and disk space, and if you have as many pictures as I do, you won't be seeing even 5% of it all before finishing.

View the pictures over samba shares. Done. No wasted sync time, no wasted disk space on the laptop. Nothing to do with editing.

 No.581

>>580

I'm a brute force solution kind of guy. They often work better, in my experience.

 No.597

File: 1428170870868.jpg (420.54 KB, 1657x2239, 1657:2239, 6de791807add53cbf783f004a0….jpg)

>>548

About drag and drop, some things about the database have changed since I last looked at it (files are stored with extensions, for instance), so that now I think of it, it won't be so difficult to do an ugly drag and drop. I will plan a prototype.

>>562

How about if I add an expandable control (like advanced tag options) that will list all the attempted urls and their successful/redundant/failed state, and then provide a right-click menu to retry failed ones?

>>573
>>576
>>579
>>580

I am planning to add multiple storage folder support for the client i.e. 'Hey, hydrus, you can store 200GB in this folder and 300GB in this folder'. This came from a convo with a guy who has nine million files, which obviously won't fit on one drive. The client would just balance file storage intelligently through those folders and occasionally 'defrag' itself to rebalance things. That should work over Samba. The client.db will still be stored under the main install dir to keep the CPU-intensive stuff quick.

Does that sound like a fix to this problem?

 No.615

>>597
>That should work over Samba. The client.db will still be stored under the main install dir to keep the CPU-intensive stuff quick.
>Does that sound like a fix to this problem?

If you add this feature to the server, it will fix things. I want to be able to access the library from multiple locations, and if I understand this correctly, one database = one client = I won't be able to manage the library from the computer hosting the samba shares.

 No.616

>>597
Yeah, having url-by-url control sounds great.

 No.650

File: 1429505285496.png (187.11 KB, 459x700, 459:700, 7ab0153c8c2bcb7e8555116948….png)

OK, I have a number of trivial suggestions

Home/End keys don't work in certain/most text fields, but they don't seem to be used for anything else in that context. Could we get those working?

I love sharing files through the booru, but I hate the incredibly long obnoxious URL. Might it be possible to make the booru URLs more manageable?

The 'share to booru' feature gives me a 'copy local url' and 'copy external url'. I'd like the ability to specify an IP/hostname for the external url. I have a vLAN/VPN with friends, so I have to modify the URL every time. Others might appreciate being able to use no-ip or something rather than a raw IP.

The 'paste tags' feature doesn't seem to work, at all. Maybe I'm using it wrong. I copy tags from one picture and try to paste them onto another, but the result is garbage (a lot of one letter tags).

Alternative views for 'tag parents' page. I'm thinking a tree view: show each parent tag once, and all the children underneath, indented. This will better illustrate multiple levels of parents (like you have already done in the tagging text field).

On the subject of parent tags, there doesn't seem to be a way to back those up. How about the ability to export tag relationships? (parent, sibling, censorship)

The image viewer's share menu is less complete than the normal share menu. Since the image you last viewed is automatically selected, this isn't a big deal, but why is this?

thanks


 No.657

An option that if you tag one file, all the files that have the same tag in a namespace (e.g. the same title) get that tag also.


 No.666

File: 1429917739623.jpg (30.4 KB, 720x544, 45:34, Kirk.jpg)

Some more flexibility with scheduling subscriptions would be good. Take these examples:

>update every Saturday at 2am

>update on the seventh of each month

>update on the first Tuesday of each month


 No.670

>>615

If you point two databases at the same file store, you need to be careful with files orphaned in one database getting deleted out from under the other database when the client runs a cleanup. Otherwise, technically there's nothing keeping you from doing what you want.


 No.679

It'd be nice to have a way to quickly add or remove tags to files without having to open up a new dialog each time.


 No.680

>>679

Press F3 to open the tagging box

Press pagedown when in the tagging box to move to the next image, without closing the tag box.


 No.685

File: 1430261645088.jpg (78.21 KB, 682x1024, 341:512, e9e2252d8dc8be7cd9b246650b….jpg)

>>650

Thank you for all these.

I think home/end is eaten up by the taglist beneath an autocomplete tag entry if there are results. When there are tag results, home/end scrolls to the beginning/end of the list of tags. Same with page up/down and cursor up/down. I'm not sure if that is helpful–maybe this behaviour should be optional?

I want to revisit boorus, including adding aliases. I don't have time now, but it is on my to-do list. Adding the better external url options is a great idea.

The way tags were copy/pasted in the tag dialog was an old method. I have updated it to use the same data protocol as clicking 'copy all tags' on a tags list, so this should work in future (although there are some graphical bugs that I'll clean up later). Thank you especially for this.

Better views for tag parents and siblings is something I really want to do (and maybe ways of filtering, like you might on a web browser's shortcut editing page), but I can't find time. It is on the list, but low priority. Same thing for exporting them. I'll get around to it someday!

The share menu on the media viewer is old. I've made a note to update it.

>>657

I think that tag parents can do what you want. Let me know if I've misunderstood, or if you would like help getting into tag parents.

>>666

Good suggestion, Satan. A good time to do this would be when I move subs over to JSON, which should be in the next month or two.


 No.686

>>680

it doesn't seem to be working for me.

But I was thinking something like being able to manipulate tags from the selection tags box.


 No.689

File: 1430354036662.jpg (31.81 KB, 276x141, 92:47, 1230480709333.jpg)

>>685

>I think that tag parents can do what you want.

Not really. The idea would be to give tags to all members of a set at once. Most mangas share one tag for all images in them in many repositories, simply because even if you search for a tag, you typically want to read the entire manga. So if I want to add tags to the entire set, it would be nice to add them quickly instead of making a search page for the set and control-A F3.

Now that I think about it, tag parents could work if I made e.g. "title:this comic" a parent of all the tags the comic is known to have. However I would have to maintain a huge ass list of tag parents, one for every title I have.


 No.690

>>689

I'ma go ahead and say your use case is too niche, and also misguided. The change you propose would be silly.

All this, for the ability to find manga by tags? Just tag the first (or any) page, then. It's not that hard to search for a tag, filter to the desired title:blah namespace that pops up in the list, and remove the initial tag filters, so that the only filter remaining is title:blah. Done. No need to do screwy things to hydrus namespaces.


 No.691

Is there full boolean search?

What would i have to do if i want to view all images with at least one of a number of tags at the same time.


 No.697

>>690

You seriously need to chill out.

What would be changed in the namespaces that would constitute "do screwy things"? My suggestion wasn't to change the namespace handling at all, it was to give the option to find the namespace and add the same tag to all the files with the namespace in one step.

Seriously, you presumed that I didn't know that you could refilter on a file once you found it? You have serious issues if your first reaction to something that doesn't make sense in your mind is to lash out with words like "silly" and "screwy."


 No.698

Can we please get a way to add tags with a hotkey or a right click menu?

How about a modified version of the archive/delete queue where the left and right mouse buttons can be assigned to give different tags?


 No.700

>>698

That exists- select multiple images, right click > filter > custom filter

>>697

Wow you're mad. My statement was not made with any vehemence or emotion, I'm sorry you interpreted it that way. I stated my case in what I thought was simply a 'matter of fact' tone. I stand by what I said- your request does not solve any particular problem and only serves to potentially screw up the database with its wide reaching implications.


 No.701

>>544

>>597

Looking at this: http://wiki.wxpython.org/DragAndDrop#CA-cc495b3a21b78daea18c76017d6b2e6ae2c1b3c1_133

I've read up on DoDragDrop and apparently it blocks, so you could use that to your advantage here.

I am thinking something like this (maybe you've tried this already, I don't know):

def OnDragInit(self, event):
original_filename = 'somehow figure out the filename'
dest_filename = 'the new filename'

temp_dir = tempfile.mkdtemp()
try:
dest_path = os.path.join(tempdir, dest_filename)
shutil.copy(original_filename, dest_path)

file_object = wx.FileDataObject()
file_object.AddFile(dest_path)

tds = wx.DropSource(self.text)
tds.SetData(file_object)
tds.DoDragDrop(True)
finally:
shutil.rmtree(temp_dir, true)

On this page, http://wxpython.org/Phoenix/docs/html/FileDataObject.html , it mentions that FileDataObject isn't fully cross platform yet (it contradicts itself at one point too…). To be honest I would not worry about that, I doubt it's possible to get anything better and at this point you're only limited by what wxPython can do.


 No.702

And I forgot to capitalize True which shows how little Python I've been doing recently


 No.703

>>700

>Wow you're mad. My statement was not made with any vehemence or emotion, I'm sorry you interpreted it that way. I stated my case in what I thought was simply a 'matter of fact' tone. I stand by what I said- your request does not solve any particular problem and only serves to potentially screw up the database with its wide reaching implications.

You bet I'm mad. This is exactly what I have an issue with: your attitude. You have some idea of what a non screwed up database is but you don't say anything about what the implications are in terms of my suggestion. You're being condescending and dismissive, and to top it off you cop out your comments by saying you were just trying to be matter of fact, which is a failure in and of itself because it is not possible for something to objectively be "silly" or "screwy".

I'll grant you one thing: my suggestion does not solve any particular problem. Let's recap: I want to be able to select a couple images that may be part of a title namespace, and with one right click or similar step I want to apply a tag that the selected file has to every other file that shares the title namespace. I envision right clicking "creator:kikuchi hideyuki" and a menu pops up saying "Apply tag to -> title:vampire hunter d".

What it would do is change a process that takes about six steps now and make it take two steps instead. And I feel it's worth it, because I'm getting tired of tagging everything in a manga by opening new search windows for the namespace tag and hitting select all.

You may not feel it's worth doing, and you obviously cared enough to post. Explain yourself then. Twice now you've said that my suggestion would damage some ideal you seem to hold about the database.

What is it?

Do you feel that tags belong to images only and not collections? If so, then why is it that every manga collection site tags based on collections and the images have nothing beyond the page number to identify them?

Or is there an easier way to do what I'm trying to accomplish? Keep in mind I'm probably coming from an already filtered result page where I've found one image out of the hundred or so in the collection and I've hit upon someone else's tagging from the public tag repository which I want to add to the rest of that title.


 No.706

File: 1430852977914.jpg (458.64 KB, 1280x896, 10:7, ff9c52bca0f5a310106f307f58….jpg)

>>691

Not yet. I'm all for adding it. How would you like the workflow to go? What series of clicks and button presses would say:

TagA OR TagB OR TagC

Would making shift+enter start/continue an OR chain work?

Would such a predicate be editable when it is active? (when it is above the autocomplete entry) How would it be editable? Where would an incomplete chain be displayed?

Any thoughts you have would be useful!

>>698

You can do this with a custom filter, although the interface is not ideal. I want to make shortcuts custom across the program so that eventually you'll be able to set specific tags or ratings from anywhere. It'll just take time.

>>701

I planned something similar to that when I was storing files without extensions, but I hated the overall idea of having to copy as an interim step. It also means I have to copy all the files in the gui thread (which blocks) before the DnD finishes. If the user accidentally dragged, that means ui delay. What I really want is:

Create a DnD object, throw it at windows.

Windows treats it like a file DnD, modifies the cursor appropriately

If the user releases on a droppable location, the DnD object is informed, including being told that path. Windows doesn't do anything else.

I can then copy the files to that location at my leisure, in a background thread, with complicated renaming happening dynamically.

But I think that would require a shell extension, which is both beyond my experience and non-multiplat. I tried looking through the Filezilla Client code to see how they do it, and I think they drop a file with a weirdass tmp name and then have a ShellEx that locates/tracks that file and immediately deletes it. They then know the dest_path and can stream ftp stuff at it as they like.

Since I now store files with extensions, throwing "{hash}.jpg" at a copy FileDataObject sounds like an ok compromise. I want to add thumbnail dragging to change thumbnail order as well, and also dragging thumbnails between search pages.

>>703

This is an interesting thought. I see that parents don't quite fix your problem.

Collections are proving a lot more complicated than I originally thought, and I think the ultimate solution I'll move towards is to bundle them up into single media objects–.cbrs or whatever. There are very few times you want to deal with page 62 of a comic alone, and many many times you want to deal with a whole chapter/volume. Tagging should probably work the same way.

I can add what you want, but I am not sure how to avoid false positives. What is to stop an over-eager user tagging creator:whatever onto series:whatever? Parents and siblings all go through a janitor process for this exact reason–they are powerful enough that a mistake can be ten thousand files tagged wrong. Perhaps this is something that could only work for title tags?


 No.837

can you make it so we can control what types of files are imported automatically by hydrus?

I've got it set to import from my downloads folder, but I only want it to try to import images, not videos, archives or other weird files.


 No.839

File: 1434478213422.jpg (386.27 KB, 1844x1386, 922:693, 4985e25d6b65d786b8db39d3f0….jpg)

>>837

Yes, I can do this. I have added it to my list. I will need to create a new control to handle selection of which mimetypes you want–I suppose a list of checkboxes works, right?


 No.843

>>839

that would be perfect, thank you.


 No.846

File: 1434553466474.png (611.12 KB, 600x414, 100:69, 1348799846335.png)

Sure, maybe in a tree of "image/animation/audio/video"

While you're in there can you add a way to move imported images somewhere instead of just deleting them?


 No.848

File: 1434564313909.jpg (479.35 KB, 1676x1177, 1676:1177, ddf1a04d6bdb59185d239e1686….jpg)

>>846

I think I'll change it to be something like:

successful files->do this with them

failed files->do this with them

redundant files->do this with them

already deleted files->do this with them

with the options being:

do nothing

move to location x

delete

Or something like that. Hence I'll be somewhat merging the 'synchronise' and 'delete' modes into a generalised and more granular solution. And maybe I'll add a checkbox for 'don't retry paths you already tried once', to optionally preserve the synchronise mode's current efficient behaviour.


 No.858

When I want to share multiple images at once (such as when dumping several on an imageboard), it's a bit of a pain to have to right-click->share->copy->copy path each time. Having to go manage->files' tags is also rather redundant, especially since manage only has one option in it (although I usually end up using f3 anyway).

Can we have a way to customize the right-click menu so that favorite actions would be more easily reached?

Or maybe a better option would be to add more possible actions to shortcuts. Being able to assign ctrl-c to "copy path" of the currently selected image, for instance.


 No.859

File: 1434823085322.jpg (464.39 KB, 1517x1974, 1517:1974, 74d43d0b17cc57fa410b2afcb3….jpg)

>>858

I plan to improve shortcut customisation in the near future.

That said, at the moment hitting Ctrl+C copies the currently selected files to the clipboard, and if you only copy one, Windows should paste that as the path in a normal file selection dialog's path text box. I don't know about other OSes.

This week, I'll change manage->tags to be just 'manage tags' if you don't have any ratings services.


 No.860

>>859

oh yeah, you're right, that does work. nevermind then


 No.876

Can you make the danbooru downloader bypass the loli block?

https://greasyfork.org/en/scripts/3575-better-better-booru

This userscript does it well, I can give a simple explanation of what it does if you plan to implement this.


 No.877

File: 1435334054386.gif (106.37 KB, 128x128, 1:1, spiderman-ani.gif)

When downloading from a booru/thread/etc., could it made so you can block files from importing that have certain tags?

Would a flow like this

>define tag x as blacklisted tag

>do a booru search for tag y

>find 10 results with tag y

>booru or tag database says 3 of those 10 results also have tag x

>download only the 7 files that don't have tag x

>add the hashes from the 3 barred files to a list of files not to be downloaded again, similar to when deleting a file

be possible to implement?


 No.878

Couple things I had trouble with trying to archive an artist:

>got random failed images with a database error implying that it tried to access an object that didn't exist when pulling from dA; I suspect these are mature images, add an option to feed dA a user account similar to pixiv

>add a Blogger downloader


 No.882

I'd like to be able to drag images from the client like with Windows Explorer. So for example I can drag an image from Hydrus to 8chan to upload it.


 No.884

File: 1435425557269.jpg (306.82 KB, 1805x2488, 1805:2488, 0018fcdd08bda75192d5295822….jpg)

>>876

Hentai Foundry does something like this–I have to push some search options before parsing gallery pages to get all the super-rude images to display. Does danbooru work similarly? A simple summary of that script would be great–just the POST calls I need to make or GET args I need to add to unfilter the gallery results, or whatever!

>>877

This is slightly tricky, because hydrus can usually only link a file to a url after the file has been downloaded (it needs the file to generate the hash). I can add a censorship taglist fairly easily, but to be comprehensive, I would probably add the filter check to after the import. I am thinking of adding a 'recycle bin' service soon, so I would probably move a censored file to that immediately after import and inform the import page that that had occured, so where it says '3 successfuil, 1 failed', it might also say '2 censored'.

Is this what you are looking for, or were you specifically looking to reduce bandwidth by censoring before the download?

>>878

Do you have any of those errors still, that you can post here/email to me? They were probably written to your client.log, which is in install_dir/logs.

I am not sure what you mean about feeding dA a user account like pixiv. I thought my dA download page already searched by artist name? Is there a way of searching with some numerical user_id?

I can definitely add a blogger downloader. Do you have an example blog of the sort you want to parse?

>>882

This has been a problem in the past because I wanted to do it in a 'beautiful' way, but I think I will have to bite the bullet and do it in an ugly way that works for Windows, Linux and OS X all the same.

I will make a job in my to-do list to prototype this. For now, you can do very similar just by hitting Ctrl+C on your selected thumbnail and then Ctrl+V on your browser's file selection dialog.


 No.885

>>877

>>884

I was hoping not to have to deal with content that I'm not interested in by avoiding downloading it in the first place, and as you say, to save bandwidth. I get what you're saying though. I didn't know generating a file's hash was needed to get the remaining tags.

Thanks for the response and keep up the good work m8


 No.886

>>884

For danbooru you need to use the API for the searches

http://danbooru.donmai.us/posts.json?tags=<tags>

or

http://danbooru.donmai.us/posts.xml?tags=<tags>

whichever you like

From there get the id and go to the post page

http://danbooru.donmai.us/posts/<id>

On this page you can either get data-file-url from #image-container

or get the meta tags og:image or twitter:image:src

these can contain a sample url, so you may need to brute force the extension


 No.887

>>884

Not sure what you mean by "ugly" method but it works for me. The main thing I'm looking for is that it works for multiple files at once though, unlike the copy-paste method.

Thanks though!


 No.890

>>887

For multiple files, you may just want to export them all to a folder and delete the folder afterwards. A bit of a pain, but at least you can select them all at once.


 No.891

>>877

Most boorus let you search for files without a tag. If you want tag x but not y, then you would just search for "x -y"

A more permanent blacklist might be a neat idea, though. It could let me avoid loli without having to remember each time, for instance.


 No.892

>>891

I know this and use this method where possible, especially if I strongly wish to avoid some content. However, like you said, it would be better not to have to make a new blacklist each time you do any kind of search.

Another thought, some boorus have a limited number of tags allowed per search, and having a built-in option to filter unwanted content could partially get around that I think.

Now I'm thinking about it, what about a system with a custom blacklist where you can place tags in order of severity? Here tags at the top of the blacklist get added to each search as a "-tag" if there's space in your search, and tags lower down the list, if there's no space left in the search to put tags, the files are downloaded and then censored automatically. mite b cool.


 No.893

The Help mentions a hidden wildcard at the end of a search for tags. This is a good feature but it seems to make slower computers stutter especially when synchronisation is happening.

Any chance for an option to turn this off / a button to autocomplete a search?


 No.894

>>892

I think ideally, you wouldn't want to download a blacklisted tag at all if possible.

Rather than just trying to censor what's being downloaded, I think the best option might be a client wide blacklist, so you can avoid blacklisted tags already in your database and from incoming images unless you explicitly search for those tags. Maybe an option to delete blacklisted images as well.


 No.895

>>894

I agree with you there, I was just taking into consideration some things hydrusdev mentioned when first replying to me here >>884

>This is slightly tricky, because hydrus can usually only link a file to a url after the file has been downloaded (it needs the file to generate the hash). I can add a censorship taglist fairly easily, but to be comprehensive, I would probably add the filter check to after the import.

Having the option to create a custom blacklist that appends itself to each search in "-tag" form should be enough for some boorus, but for others, like for example e621, which limits searches to 6 tags, and Danbooru, which limits searches to a mere 2 tags, some more flexibility is needed.


 No.903

File: 1435792089266.jpg (181.5 KB, 847x1320, 77:120, 485b09a056bc1a427e4c571915….jpg)

>>894

>>895

I have thought about this a bit and decided that I'll add it when I rewrite the downloader engine (which should be in the next month or two). I'll check for tags before I download a file, and if the tags include any censored tags, it'll skip the file.

>>893

Do you want it only to return counts for the exact match for what you put in? Like if you type 'tank', you would only get:

tank (210)

or whatever? If so, you can probably do something this by changing the various thresholds of the autocomplete dropdown searches in file->options->maintenance and memory. The 'autocomplete' options are what you are looking for–hover over the number control, and you'll get a tooltip explaining what each one does. If you can't figure it out, just ask and I can explain more.


 No.905

File: 1435838114155.gif (1.05 MB, 320x240, 4:3, jKQeXPS.gif)

>>903

Once again, doing God's work.


 No.913

>>884

>Do you have any of those errors still, that you can post here/email to me? They were probably written to your client.log, which is in install_dir/logs.

>

>I am not sure what you mean about feeding dA a user account like pixiv. I thought my dA download page already searched by artist name? Is there a way of searching with some numerical user_id?


AttributeError

'NoneType' object has no attribute 'parent'

Traceback (most recent call last):
File "C:\code\Hydrus\build\client\out00-PYZ.pyz\include.ClientDownloading", line 1172, in __call__
File "C:\code\Hydrus\build\client\out00-PYZ.pyz\include.ClientDownloading", line 1255, in _GetArgs
File "C:\code\Hydrus\build\client\out00-PYZ.pyz\include.ClientDownloading", line 394, in GetFileAndTags
File "C:\code\Hydrus\build\client\out00-PYZ.pyz\include.ClientDownloading", line 382, in _GetFileURLAndTags
File "C:\code\Hydrus\build\client\out00-PYZ.pyz\include.ClientDownloading", line 309, in _ParseImagePage
AttributeError: 'NoneType' object has no attribute 'parent'

By "feeding dA a user account" I mean something like the "manage pixiv account" option for viewing mature images. https://github.com/xofred/deviantart-gallery-downloader does the same thing, but that uses Mechanize to crawl galleries manually so it may not be applicable to you.

>I can definitely add a blogger downloader. Do you have an example blog of the sort you want to parse?

http://fupoo.blogspot.com/

Right now using a URL downloader on that blog while fucking with the URL search paramaters sorta works but is clunky and doesn't grab images after the jump.

And now that I'm thinking of it, I also got shit like this trying to crawl Paheal:


Database Error!

<include.ClientData.Booru object at 0x07617EF0> is not JSON serializable

Unknown Caller, probably GUI.

Traceback (most recent call last):


File "C:\code\Hydrus\build\client\out00-PYZ.pyz\include.HydrusDB", line 172, in _ProcessJob


File "C:\code\Hydrus\build\client\out00-PYZ.pyz\include.ClientDB", line 6007, in _Write


File "C:\code\Hydrus\build\client\out00-PYZ.pyz\include.ClientDB", line 4698, in _SetJSONDump


File "C:\code\Hydrus\build\client\out00-PYZ.pyz\json", line 243, in dumps


File "C:\code\Hydrus\build\client\out00-PYZ.pyz\json.encoder", line 207, in encode


File "C:\code\Hydrus\build\client\out00-PYZ.pyz\json.encoder", line 270, in iterencode


File "C:\code\Hydrus\build\client\out00-PYZ.pyz\json.encoder", line 184, in default


TypeError: <include.ClientData.Booru object at 0x07617EF0> is not JSON serializable


 No.915

File: 1436295489640.jpg (204.02 KB, 1373x2092, 1373:2092, c6c5d0b0113053898944869c61….jpg)

>>913

Thank you for this information.

That first error is an unexpected failure of my parser to find a download link for a file. I have improved the error, and it should also print for which url it failed. If you see it again, please let me know the url so I can see what is going on. I expect it is a webm or something that uses a slightly different link-text than 'Save this file' or 'Save this video'.

I didn't even know that DeviantArt allowed adult images! I can add a pseudo-login, but I would rather keep it simple if I can. I just had a poke around their html, and while they are quite careful to hide mature images and thumbnails (and even identifying information from which I could extrapolate a link) from non-logged in users, they acidentally leak the encoded image link in a tumblr share button. I don't think I'll have time today, but I'll put some time into it next week.

Blogger shouldn't be too difficult–thank you for the example. The jump through the 'are you an adult' splash page will be an extra step to code, but that's it. There is probably an API to skip it entirely. I will look into it next week.

That Paheal JSON error is a mistake from the gui session rewrite from a couple versions ago. Booru pages aren't being saved to the database properly, which also happens every few minutes to maintain the 'last session' gui session. It is just some annoying error spam while a booru page is open, but the downloader otherwise works. It is fixed in tomorrow's release.


 No.921

Is it possible to implement a command in the context menu that sends a picture to IQDB? It would be great to open iqdb.org in the default browser, sending the current image to look for the source.

I don't know if this could ever work though.


 No.1003

Would support for .zip or other archives be possible? i.e. given an archive file it attempts to import any images it finds.

Exporting as a .zip might be nice, too


 No.1014

File: 1439326325456.jpg (122.66 KB, 1076x1489, 1076:1489, 28f249707ab737c86d2ddb623e….jpg)

>>921

I am sorry, it looks like I missed this post. I'm planning to do something like this, but I've since added the thumbnail drag and drop export, which should speed up doing this the traditional way.

>>1003

Ironically, I just removed this support a week or so ago! It was making my other code complicated, so when I went to rewrite it, I didn't bother to update the zip stuff. I can bring it back, but I'll probably create separate dialogs for it.

I'll add support for more formats than just zip, as well, as here:

https://docs.python.org/2/library/archiving.html


 No.1030

File: 1439489291728.png (55.64 KB, 456x254, 228:127, 2015-08-13_20-00-38.png)

Could we get a feature to rename individual tabs in the session? Simple right click menu on the tab with a rename tab option opening a simple dialog with one textbox would be enough.

Also, when you slim down the leftside panel with all the search and tags fields, the fields themselves stay fixed width.

Given that some very long tags can make it scroll sideways (and the sideways scroll bar appears within the thinner panel without being hidden, unlike everything else in it) anyways, can the fields contract with the panel itself?

Thanks for your time.


 No.1037

File: 1439582763568.jpg (255.49 KB, 1491x1877, 1491:1877, 12aaf2e094a8543ee92e5b26de….jpg)

>>1030

Thank you, this is a great idea. Should be simple, so I'll try to fit it in this week.

I'll have a look at the management panel minimum widths, as well. I noticed this bad resizing when I was working on the thread watcher the other day.


 No.1053

File: 1439872921910.png (16.49 KB, 838x640, 419:320, Untitled.png)

This may or may not be a sound idea: being able to customize how many files Hydrus downloads from a site before it "takes a break" for a time period before retrieving any more. I find most times when a file fails to download it's after Hydrus has already grabbed a hundred or so images, maybe because the site is trying to limit your access or something. Perhaps be able to make the downloader take a break as soon as a file doesn't download?

I don't know, might not necessarily be the best solution.


 No.1054

I would love to see some refactoring done, the way Hydrus seems to be structured now, the server and GUI client seem to be very interlinked with wxWidgets, which I figure makes it hard to make the server run headless. Please note I make this observation from looking at how the client behaves towards the user, haven't had much quality intimate time with the code yet.


 No.1055

File: 1439916547930.jpg (183.86 KB, 1600x1045, 320:209, c3258d71a979b62d829f8b9642….jpg)

>>1053

This is a good idea. I will add options to change the inter-file and inter-gallery-page delay times (currently three and five seconds or something), and adding another option for a break period after n files should be doable. I could also do it based on num_requests and num_mb sent to any particular domain (i.e. after 50MB, wait twenty mins before requesting again from there).

>>1054

This is in the works, and I try to do a bit more every week. The server's wx parts aren't necessary, so I plan to replace them all and move to console switch and network POST request control of the server. So far, I have refactored my general file parsing and rendering code away from the wx-entangled client-specific code and cleaned up my import tree so the server doesn't accidentally import any client code. Now I have to rewrite the wx app controller for the server and pull wx out of my pubsub and db maintenance timer code. And then add some switches to control it.


 No.1070

I've been loving Hydrus for awhile now and wanted to start using it to manage a video collection since folders just weren't cutting it anymore.

The open externally option works great for this.

Only problem is that thumbnails are only generated from the very start of the videos, not part way through.

So visually all the added videos look the same; black boxes because they all fade in.

Is there any way that thumbnails could be generated part way through the video's duration for mp4s or does that conflict with how the server works?


 No.1071

>>1070

Honestly I think you'd be better served by using software actually intended for managing video collections. Kodi, plex, emby are all good cross platform solutions to take a look at.

Imo projects need a scope, and it's fine to use it however you want, but when you start asking the dev to support your unintended uses you put the project at risk for feature creep. Offset thumbnail generation isn't (afaik) a big ask, but there are already so many excellent video cataloging programs that already do what you ask- I really don't see the point in bending hydrus that way.


 No.1074

File: 1440525585797.jpg (382.42 KB, 1280x1498, 640:749, 49a8f71f4d591db7b5300e627e….jpg)

>>1070

I am considering converting to animated thumbnails for video because of this. Something like grabbing ten frames evenly spaced throughout the video and packaging that into a small gif or just a list of jpegs.

I can then add an option for which frame people want to show by default and also do a preview ~10-frame animation when people mouse over the thumbnail, like how some video sites do.


 No.1077

>>1074

that sounds amazing

>>1071

I actually use Plex, but that's for shows and movies where metadata scraping is possible.

Not the type of video library I'm talking about.


 No.1080

File: 1440672389653.jpg (11.38 KB, 133x188, 133:188, dazzler1.jpg)

>>1074

Weren't you going to do something similar for ugoira support? Could do the same thing for both.

Also do you still plan to give us a way to save our tag import regexes into profiles? I have to copy and paste the same five regexes into the namespace import box with every bleeping folder I import.


 No.1088

File: 1441131338544.jpg (1013.38 KB, 2327x2980, 2327:2980, e03e5b8c19cc9928592659f988….jpg)

>>1080

Both ugoira and saved tag rexes are on my to-do list, but it is taking a while. This week I have almost finished my big wxless server rewrite job, and then I want to move subscriptions and gallery downloads to the new download system, and then I should be a bit more free to add complicated new things.

Saved regexes should be the simpler of those two jobs though, so I will bump it up a bit.


 No.1096

File: 1441288284972.png (12.82 KB, 200x104, 25:13, how-do-I-skip-this.png)

I want to be able to skip this and send files directly to the trash on pressing delete.


 No.1100

File: 1441302288796.jpg (360.45 KB, 1621x1582, 1621:1582, 7ad0ebc08677a987d0cfff364f….jpg)

>>1096

I will add an option for that this week, and for archive/return to inbox multiple files. Thank you for the suggestion.


 No.1105

Is there a way to import ratings like Safe and Explicit from boorus when getting tags? That would be helpful.


 No.1106

File: 1441583344993.jpg (166.17 KB, 1228x1553, 1228:1553, d5af6765c50cefd734d88dcf58….jpg)

>>1105

Not at the moment. Would you like to import it like a namespaced tag, like 'rating:explicit' or whatever? I can't add import to literal like/numerical ratings until I move gallery downloads and subs to the new system.

Also, is there a standard for this stuff across boorus? Is it only 'safe' and 'explicit', or can it get more complicated?


 No.1108

>>1106

Most boorus I've used also have "questionable".


 No.1109

>>1106

Currently I am tagging manually with rating:safe rating:questionable and rating:explicit.

These are the ratings that sankaku chan, danbooru and gelbooru all use.

After some research, konachan and xbooru also use this scheme, so it appears to be a standard.


 No.1111

File: 1441735554158.jpg (155.45 KB, 1011x674, 3:2, 05e62dd4414e89c8b144260837….jpg)

>>1108

>>1109

Thanks. I will see about adding this to the booru code as a 'rating:' namespace. This might be something that is easier to add after I convert galleries and subs to the new system. I'll think about it a bit, and have a look at the html and css.


 No.1125

If it's not already added: an option to bypass the recycling bin and use the old behavior of deleting from disk.

I just noticed the change introduced in version 170 to use the recycling bin broke the option 'delete files after successful import' on my linux install and I can't tell if this is a bug with hydrus or if I'm being retarded. Plus not having to empty the recycling bin of imported files is convenient on both *nix and windows.


 No.1129

File: 1442169921518.jpg (231.38 KB, 1470x2651, 1470:2651, 11e5b1c2b63e369053fc4e5ad8….jpg)

>>1125

Sure, I'll add an option.

Do you have an error for the 'delete after import' stuff, or do the files just not disappear? It is working for me on Linux and Windows, even on read only files. Do you know if your Linux distro has unusual rules for what can be sent to the recycle bin?

Error tracebacks should be written to the bottom of your client.log, which is in install_dir/logs.


 No.1130

>>1129

>Do you have an error for the 'delete after import' stuff, or do the files just not disappear?

No error message appears and the files just don't disappear. As far as I can tell nothing is written to client.log about it. I've also tried launching from a terminal window to see if anything would show up there. What I've found is that trashing a file within hydrus and then using 'delete from trash now' on it does send the file to recycling bin as expected, so originally I thought it was a problem with permissions. I tried different combinations of r/w, ownership, and even trying to delete on import a file previously imported by hydrus (identical permissions as one that can be moved to recycling bin via trashing).

>Do you know if your Linux distro has unusual rules for what can be sent to the recycle bin?

Not that I know of. I'm running Debian stable. Since no one else is talking about this I'm guessing that things are set up wrong on my end.


 No.1135

I don't know why this hasn't been implemented yet.

Is it possible to have an option for the client to minimize or close to the tasktray?


 No.1140

File: 1442341188740.jpg (631.11 KB, 1748x1905, 1748:1905, 2b30922a650069a3e4b5220af5….jpg)

>>1130

I looked at the code again, and deletion errors in this case were getting silenced. I have now made them pop up and write to the log. Let me know if you get any continued trouble with this, even after you move to deleting rather than recycling.

>>1135

Thank you for the suggestion. I have had trouble getting taskbar icons to work in Linux/OS X, so this might be a Windows-only option to begin with. I'll add a shortcut for it, as well.


 No.1148

>>1140

Fine with me if the tasktray thing only works on windows for now.

Also, another suggestion if it isn't already part of the sub rewrite, would it be possible to specify arbitrary tags for each sub, instead of only being able to rip them? It's annoying to manually append them every import, especially when I forget to do so.


 No.1149

File: 1442768656896.jpg (237.14 KB, 1648x1333, 1648:1333, ea5619ec476a7f98de72e82471….jpg)

>>1148

Yes, adding tags to subs is planned. I'll have it work like for import folders. I can extend it to multiple tags in future, if people want that.


 No.1154

I'd like to know how much disc space a tag or set of tags takes up. Is there a way to do this without searching for the tags and then selecting every image? when you've got tags containing several thousand images, trying to do that can severely slowdown/freeze the client


 No.1155

File: 1442939655202.jpg (563.36 KB, 1686x1318, 843:659, 6d9c6a87379906a0bcee944207….jpg)

>>1154

No quick way inside the program. You can make sure your client loads things as fast as possible by making sure your db is vacuumed (database->maintenance->vacuum) and that the hard drive hydrus is installed to is fairly fast and defragged.

That said, I would like to work on speeding up media loading times. Some predicates like num_tags work way too slowly on a big db. Do you find the slow period is when the client just says "Loading…" in the status bar, or when it says Loading… x of y?

Since you want something simple and low level, if you like, you can query the db directly by going to install_dir/db and opening client.db in sqlite3 or SQLiteStudio. If you have never done this sort of thing before, I recommend SQLiteStudio, as it has a friendly gui. In that, you should be able to open client.db and a SQL Editor page and run a command like this:

SELECT SUM( size ) FROM files_info, ( mappings, tags USING ( tag_id ) ) USING ( hash_id ) WHERE tag = 'alphonse mucha';

That will select total size for all namespaces and all tag services. It will result in either a number, meaning total bytes, or NULL, meaning nothing was found. I can generate a more complicated query that'll do namespaces or other pseudo-predicates, if you want.


 No.1156

Manga downloads for Pixiv, pretty please?


 No.1157

>>1155

vacuuming noticeably improved the speeds to where it's bearable, thank you.

Most of the loading is "loading x of y"


 No.1159

File: 1443025352485.jpg (115.89 KB, 877x1204, 877:1204, b91bfd3c8bdb8264e25bd9ae3c….jpg)

>>1156

I am planning to work only on the downloader and subs rewrite next week, and likely the one after as well. Once that is done, it will be much easier for me to add things to the gallery downloaders, and I will get right on this. Please keep reminding me if it looks like I have forgotten.

>>1157

Great. I will keep working on speeding this up.


 No.1172

so ive noticed webms that have sound, lose their audio track in hydrus. If you could add sound support, thatd be awesome!


 No.1174

File: 1443801544627.jpg (102.62 KB, 640x872, 80:109, 90f7858e054282e2644b1627c4….jpg)

>>1172

I definitely want to support audio natively, and I have a rough plan to get there. Once I am happy with this current downloader/subs rewrite, I should be free to work on big new features like this again.

I should be able to support sound for mp4s and mp3s and whatever else as well, which will open up the program to do several new things and will also need some new gui elements to handle mute and volume and so on. The audio is still in your webms, btw, I just don't render it. I use 'open externally' on those webms for now.


 No.1178

Might be outside the scope of hydrus, but what about some sort of positional annotation for images. Some popular boorus have this feature; it is normally used to translate an image without having to modify and typeset the it. They normally work by displaying the text when you hover your mouse over a specified area (say a speech bubble).

You could set it up by having a companion file for an image with annotations, and in your chosen file format, have position, size, and content information. I.E. there’s the image file “(some SHA hash).png” with annotations. The annotations will be in “(the same SHA hash).yaml,” and hydrus will read that file when the image is previewed and render the annotations on top of the image.


 No.1181

I would like to be able to assign keys to zoom functions, primarily a "zoom full" and "fit to screen" switch, instead of using ctrl-mousewheel.

Also, a way to choose default display behaviour for images that are larger than the screen resolution akin to the already present zoom for smaller images would be much appreciated. Something along the lines of "fit larger image to screen width" is what I am missing most


 No.1188

Is there any possible way to speed up the time it takes to import files into the db? Even importing 500 files can take up to 20 minutes, which is a long time considering I have a few hundred thousand files to import. Perhaps it's because I have such a large amount of tags/mappings.

I almost wish I could force it to use 80% of my CPU/ram.


 No.1206

File: 1444498916510.jpg (128.63 KB, 1011x1304, 1011:1304, 95f331b349c46d8aab123a3fa2….jpg)

>>1178

I like the idea, but this is outside my scope for now. In the future, the network may run user-written app services, which would support this sort of specialised function very nicely, but for now I just don't have the time.

>>1181

I have a plan to move towards complete shortcut customisation for all functions. The situation should get better as I continue my overall YAML->JSON rewrite. (some shortcuts are currently stored in YAML, and some in JSON, and some are hardcoded, and there are then two or three ways the gui catches key/mouse events, and it is generally a bit of a mess all around that needs cleaning up and harmonising).

I've been thinking of extending the current 'zoom to fit canvas' option to support also saying 'unless the image is >90% normally', as pngs and other sharp images get unnecessarily blurry with the tiny zoomin. Adding 'fit to width/height' and other options is a good idea, and maybe having different options per mime as well. I will make a proper job of it and put it in my to-do, thank you.

>>1188

Someone in the v175 release thread mentioned file imports being slow. I am not sure what is causing it. The file importer should attempt to run as quickly as your machine allows, and my dev machine reliably rises to ~25% CPU (using all of one of four cores) and imports about 2-3 files per second, depending on file size, but some people seem to be having some gui-related delays that I haven't pinpointed yet. I just ran a test on my laptop, and I only get 7%, and about 1 file/s, so perhaps having a tag- or file- heavy db is causing the slowdown. I am looking into it.

HDD latency is also a common problem. Is your hydrus hard drive particularly fragged or full, or could there be some other disk-intensive program running while hydrus is trying to import?

If you like, go help->debug->db profile mode while you are importing some files. That will dump a lot of profile text to the bottom of your log file (install_dir/logs/client.log). You can email/pastebin those profile tables to me and I can have a closer look at your situation.

Unfortunately, the language I write hydrus in (Python) won't work on multiple cores simultaneously unless you bend completely over backwards, so I am limited in some CPU areas.


 No.1218

>>1217

>Do you think it's possible to have an option for swapping spaces with underscores instead when searching tags?

Why not just put underscores in your tags?


 No.1220

>>1218

I didn't want to manually mess with the tags.

On second thought, I realized how minor it is. Spaces are fine, Nevermind.


 No.1223

I'm going to throw this in here so other people can comment on it too.

Auto-Loading

When I type in a tag, it loads all the files related to that tag. (At the bottom left corner on the status bar)This can take several seconds depending on the amount of files loading. I was thinking instead, you can have users limit the amount of files that is loaded at a time.

So for example, when I type in "character:princess peach", it'll only load the first 100 out 1,000 images. (Additionally, Allow users to set how much is loaded) Then, as I scroll down past the 100 image mark, it'll load the next 100, and so on, until it reaches the total of 1,000. Basically, it'll work exactly like Sankaku's Complex Auto-Paging system.

https://chan.sankakucomplex.com/

This is extremely useful if someone were to type in a generic tag like "loli", which would cause the client to attempt to load around 120k files at once. Instead with this method, you'll get the results nearly instantly. Right now if I type in loli, it's going to take quite some time for me to even see any images show up.

TL;DR, load files in small chunks instead of 1 large chunk.

Tag List

This may or may not need to be a feature, but I don't see a way to view all of my currently available tags? I realize this will take awhile to populate, so I figured maybe you can have an additional option to limit how many tags are displayed at once(around 20 is good), and have it so scrolling the tag list auto-generates the next 20 tags and so on.(same as method above, except with tags)

Gelbooru has trending tags, which shows around 20 tags on the left side. However since we obviously can't have a trending tags, it could be randomized to give the same result.


 No.1224

File: 1444755783117.webm (399.86 KB, 1280x720, 16:9, 1.webm)

>>1223

Here is a webm of what I mean when entering a generic tag. As you can see, it takes awhile. With my file streaming suggestion above, it'll stop loading at 100, or whatever the user sets, so that I get my results quickly.

(Loading is also slightly slower due to the fact that I was currently importing files + recording)


 No.1229

File: 1444761814119.jpg (120.61 KB, 763x768, 763:768, b5099221a1c69fe8d2d88b2a7f….jpg)

>>1223

>>1224

Here's what I just emailed you, so people can see what I generally think:

I like the idea of auto-loading. I am going to have a look at my media-generation code (the bit that does "Loading 512 of 2000") in the near future, and if I cannot speed it up sufficiently, I will look at doing something like this. Thank you for the suggestion.

If you haven't seen it yet, for now you can add a "system:limit" predicate, which will limit the results to a random sample up to the given number. I use it all the time, and it does the first half of what you are talking about here. You can also pause a search by clicking the "searching immediately" button, which is helpful if you want to put in several tags without having the CPU hit of the half-completed search going on in the background while you type the subsequent tags in.

There's no way to see the tag list yet. I have thought about creating a tag cloud to display a client's most popular tags, and there is a thought to add this information to the tagging dialog (e.g. anything tagged with 'series:blah' could have a tag cloud that had various common 'character:' tags for that series), but I am not sure how I would really display that data on a normal application gui.


 No.1231

OK, I have a reason to revisit the server again. BARE minimum change I would have you make- if the client is local to the server (eg same directory/installation) have just one shared database.

Having the client and server operate on separate databases results in one of two things: the database being twice as large as it needs to be, or reduced client functionality. I have my database, I want to share it while still being able to use the client and without wasting space.

I can see two solutions

1) couple the client and server into one database

-or-

2) implement LAN/local specific client-server code for the client viewer. That is, keep everything exactly the same except allow the viewer to directly access the server database, as opposed to importing it to the client database and viewing it there. This could be in the form of a special kind of user, instead of writing LAN code.

What do you think? My end goal is to have client functionality for my personal uses, while also serving my database.


 No.1240

File: 1444863468628.jpg (3.23 MB, 1754x2563, 1754:2563, 66ad4d690583beed797335988c….jpg)

>>1231

Thank you for the suggestion. I have thought about doing something like this before, but it is actually quite tricky, as the way the server and client store some sorts of similar information is different, and so many tables just can't be combined without hacking things into inefficient shapes. The server stores files and tag mappings with timestamp and account info for every row, for instance, while the client considers everything to be timeless and anonymous and is more concerned with keeping everything quick to search. Combining the two datastores would also need new gui and db code to replicate all their existing http communication on an intra-application level. Furthermore, the db engine I use, SQLite, is a complete pain about multi-threaded access, so trying to get simultaneous server and client access would require some locking magic that would almost certainly slow things down, especially when the server wanted to suddenly generate a big update for 45 seconds straight.

Writing insta-access local http requests produces some not dissimilar problems, in that the server is designed to use very little CPU recording new content and occasionally generating update files, not in performing complicated tag queries. I could create a cache of the server's data inside the client and search that, but that's what a file repository already is.

My general long-term plan is to move many of the server's responsibilities to the client, file sharing included, once I have some p2p functionality going. I don't really like how the file repo works, so it might be better for the server to be a p2p node-connection facilitator, rather than a big media server.

If your concern is more in doubling file storage between the client_files and server_files directories, there is probably a good way to neatly merge them, maybe with an auxiliary db file that tracks which hashes to keep and delete between the two programs, but that makes clean backup and restore a new headache. I will think about it a bit more. I expect I am missing some obvious solution. If you have any ideas on how to cleverly do this (and it needs to be multiplatform, so we can't spam symlinks), I would be very interested.


 No.1241

>>1240

I'm not suggesting symlinks, but on the subject of symlinks & Windows, cygwin invents its own symlink to neatly avoid the permission issues in NTFS style symlink. Food for thought.

I like the idea of moving the server's functionality into the client. The client already has the beginnings of a booru server, and imo it would make a lot of sense to

a) rename client.exe to hydrus.exe, remove server.exe

b) add a headless mode to hydrus.exe (hydrus.exe –daemon)

P2P sounds interesting- are you thinking complete redundancy across the entire P2P pool, or…? I can't really tell you how to handle the server, since the massive scale you're designing for is not how I'm used to thinking. I'm also not used to the concept of DB locking- I remember that as a thing of the past, because so many internet services have found ways around it. I don't have personal experience here though.


 No.1247

File: 1445010004819.jpg (261.28 KB, 1178x1701, 1178:1701, 1006c1dfde1bdc614e4a248e65….jpg)

>>1241

Hydrus.exe is generally where I think I am heading. I would eventually like the network to move towards something like gnutella, but working with hydrus's specifics like sha256 hashes and predicates and optimised for small files like images.

I'd like for people to be able to go "show me some x" and get a page of thumbnails for the various media the other nodes have to share. Not necessarily comprehensive over the whole network, but more like "here's some x I found" like Limewire and those other clients used to do. Nodes would share their and others' file and tag caches about, perhaps with differing levels of trust, and offer proxy and signing services as well. Specific always-on supernode services would probably play a part, but only really as certificate authorities and IP caches and that sort of thing.

That's a very vague description of a very complicated system, so my current practical plan has been to get some instant messaging going and start tacking on features like real-time IM file transfers. In time, I can add asynchronous (email) messaging and so on and so on. I was messing with this stuff a long time ago, but I've been distracted by the sheer mechanics of showing media in the client (which is what most people request me to work on). I have a lot of ideas and a few splatters of mostly broken code lying around. Nonetheless, I feel that the 'searching and viewing and tagging/rating' part of the client is working fairly well right now, so I am starting to think about this stuff again.

I am also planning to add support for many regular client actions (import and tag files, that sort of thing) to the client's local server, through POST requests. Then people will be able to externally script mass imports and tags from various complicated locations. Formalising more client commands into proper serialisable objects is a good step towards client-to-client syncs and so on.


 No.1258

File: 1445369062921.jpg (116.59 KB, 2140x1605, 4:3, 1439155146001-0.jpg)

I'm new to hydrus and so far I'm really enjoying it.

There's one thing I would really like to see and that's the implementation of sibling posts. I would like to be able to link two or more entries together and preferably have them show up next to each other.

I often have multiple versions of the same image and I don't like to see them all over the place. This seems like a good solution to that problem.

I could obviously just tag it with different volumes and pages but that just looks bad to me.

I don't know if there is already a better way to do it but this seemed like the place to leave my idea.

Thanks for your time and keep on doing what you're doing!


 No.1268

File: 1445449535526.jpg (533 KB, 1280x1575, 256:315, 40c2b7c14543f51f3d0a5ea3f9….jpg)

>>1258

I am glad you like it!

One of my next big plans is to scale my 'looks very similar' duplicate detection code up to the entire database, so you'll be able to say "show me all the images that might be slightly different resolution, or have little watermarks, but are otherwise basically the same thing", and then have those results appear in a way that makes sense. I then aim to add some new concepts for the db to understand like "This file is the same as this file, but it has a slightly higher resolution" or "has fewer jpg artifacts" or "isn't cropped" or whatever that people can enter, perhaps through some filtering system. This information could be shared through a new service, and then people could clean their dbs and merge tags for dupes in an efficient way by setting up commands for each relationship type (like "when you spot dupes, I want you to delete the version that has jpg artifacts and port its tags over to the better version.").

It would be easy for me to add "This is an alternate of this. The first image is the 'parent'." to that sort of system. I could add a little button to the media viewer to show the stack of alternates, or include them in normal queries, or whatever. In any case, I am not very happy with how collections work at the moment–I think I could incorporate this sort of rich metadata into better sorting and display of media. But the first step is in gathering that metadata in an efficient way.

This stuff will be a lot of work that will take me a long time to do, so please follow along and let me know what you think of the components as I build them and keep me reminded if it looks like I have forgotten about siblings. Thank you for your interest and suggestion.


 No.1270

speaking of p2p, have you looked into ipfs integration at all?

tl;dr magnet links for static website content

some people over on /tech/ have been playing with it and it looks perfect for boorus


 No.1278

File: 1445549900538.png (14.58 KB, 640x256, 5:2, ipfs-logo.png)

>>1270

beat me to it

>>1247

yeah, ipfs

>>>/tech/412592 should be the current thread they're discussing it in

Seems like a perfect fit, since it takes care of the hard part by trying to be a general purpose protocol for data decentralization and distribution, and it bases everything around hashes similar to your method.

It even has python api bindings: https://github.com/ipfs/python-ipfs-api

My very rough idea of how it would actually be used:

Transfer of all Hydrus hashes to use ipfs' multihash format ( https://github.com/jbenet/multihash ) so as to not lose the millions of existing mappings we already have (likely easier said than done, but still) and then pinning those hashes in Hydrus.

For new files we could get the hash instead by simply adding them in ipfs (which automatically pins them as well in the ipfs client, not sure about the python-api) and recording the resulting hash in the database. You could even do the same for file thumbnails as well.

When you want to retrieve the file, a simple "ipfs cat <file_hash>" (or however it would be written in python) would let you retrieve the file from ipfs and view it in Hydrus.

If you actually did this, then it would immediately come with the added bonus of every hash Hydrus knows about can now be searched for by its tags and retrieved even if the user does not have the file locally as long as at least one other person on the entire ipfs network has that file to share and is accessible. Essentially removing the need for file repos altogether.

Of course, the real implementation will be more difficult than just that, and will beg for the need of a few extra features of how the whole thing would work. You would need to be able to handle cases where a hash is requested but not actually able to be found (likely not too difficult) as well as have a proper interface for pinning, and how it works with the inbox/archive/trash paradigm you currently have (my idea would be to add and pin everything, just marking it differently like you do now, and then when you want to actually delete something you just unpin it and let ipfs garbage collecting take care of the rest). Not to mention the many subtleties of Hydrus I don't even know about that would make implementing this more difficult, I'm sure.

But, again, if you actually did go about doing this, the benefits wouldn't even end there. The tag repos themselves could be decentralized despite having to be update-able (and thus changing its hash that ipfs relies upon) because of ipns. Now, ipns especially is still being worked and has its problems in its current state, but in the future should be more reliable and a practical alternative to tag repos by, again, just having a specific ipns hash that every Hydrus client is told "This is the public tag repo, download this over ipfs and use it locally" In fact, it even supports DNS, so you could even instead tell it to go to /ipns/brand-new-hydrus-website.biz and it would look at brand-new-hydrus-website.biz for a custom ipns DNS record with the correct ipns hash to then use, letting you change the hash without worry.

Hell, there may be a way to optionally not use a local database at all and basically just use an updated, decentralized, shared database directly. There is already talk about how to implement and use databases on ipfs (see https://github.com/ipfs/ipfs/issues/82 ).

And then there are ipfs "services" that I admittedly am not too familiar with but I'm sure are very interesting and has a plethora of possible uses with Hydrus. The most relevant to Hydrus I've seen is https://github.com/ipfs/archives/issues/8 which talks about decentralizing searches, where different nodes running this search service have only a fraction of all combined mappings but can be used together to not only decentralize the data it searches but even take part themselves and decentralize the actual process of searching.

Sorry for dumping a fuckton of info and autistic ramblings in front of you, but ipfs has given me a massive boner that simply will not recede and my doctor says that talking about it will help. Hope you were able to garner something useful from it.


 No.1279

File: 1445550906900.jpg (259.87 KB, 480x600, 4:5, 4c4ccb2ac617b728a36169ff3f….jpg)

One of these might already be possible but im not sure, but i have two feature requests

A.Dual Monitor Support, I would like hydrus to open fullscreen on the monitor I have hydrus on, not always on my main monitor, or even, a "windowed" fullscreen mode, so I can still browse through images and tag with the hotkeys, but have the images show up in a smaller window, this can even be useful to shrink the window a bit and put the tagging window to the side so they won't overlap (the "fullscreen" window would be locked in size and the image would stretch to fit)

My other request, is a tag downloader, instead of downloading all the images off a booru, it would just grab tags. This would be very useful for people who are picky about their collections, but also want the tags that already exist on popular boorus. So instead of downloading several thousand images of a character, they can just set the tag downloader to go and grab the tags off the site without grabbing the image, this might also lower the resource usage on the booru in question (educated guess here)


 No.1280

>>1278

I was thinking that the simplest way to go about doing it would be to add a context menu option to send the file to an existing ipfs daemon and mark it as being shared within hydrus via a new archive/inbox category and maybe an icon in the thumbnail corner.

This would maintain a clear division between hydrus and ipfs. Many people manage media with hydrus that they don't want made public or simply wouldn't want to participate in such a scheme for various reasons (such as bandwidth limits).

———-

Lots of picture pages on deviant art include a download button to save a higher-res version. Hydrus currently saves the smaller resized picture that is displayed on the page. It'd be awesome if it were changed to get the larger picture whenever one is made available and fall back to the resized version when it isn't.

———-

Lastly I'd like to bring up adding g.e-hentai and exhentai gallery support. They also offer full resolution links on some of their pages and it'd have to go slower than usual because they limit users to X pages per hour without using their credit ystem. Ex would obviously need to use login credentials. Gallery language filtering would be similar to hentai-foundry's filtering. A lot of work, but in the end it'd be well worth it imo.


 No.1282

File: 1445596524624.jpg (16.13 KB, 347x257, 347:257, 1de9f6ee1760dd40e44c416aba….jpg)

>>1278

PLEASE do this. You have so much good work put in to this thing already, if it could be used for distributed serving of tagged files it could be something truly phenomenal. People wouldn't even have to upload many images to chans anymore after a while, just link to a file in the system and the copies that are already out there will be streamed. All the people who like it will just grab it through the system and help distribute it and manage the tags.


 No.1288

File: 1445714987171.jpg (693.83 KB, 1600x1217, 1600:1217, c447b9fe5c06c03ee4518befc8….jpg)

>>1278

I appreciate all this info, thank you.

Now I have read a little bit about it, IPFS looks quite interesting and something I can definitely plug into. That python library looks great. I haven't used the network yet, so I do not know how stable or laggy it all is, so I will make the first step very simple and optional.

I have created a new job to basically do what >>1280 suggests–I will add an IPFS option page where you can point to your local IPFS daemon, and add an 'add this to IPFS' option to the right click menu for local files. I'll change my download code to allow downloads from unknown locations and let the client search IPFS for any outstanding downloads, essentially like a different kind of file repo.

If you happen to know, what's the ipfs cat/get failure state? If the file doesn't exist on the network or just can't be found in say 30 seconds, does it dump out with an error?

>>1282

A distributed chan is what hydrus was originally intended to be, funnily enough. I wanted to build a localhost service that would be a p2p node on the internet side, a bit like IPFS, that you would connect to in your browser, and would fetch distributed threads and images from via AJAX. All built through a LAMP stack, originally, until I stumbled over python and the pursuit of "Actually, getting images is fairly easy, let's try to burn some heavy clientside CPU searching and organising them" moved it all towards ACDSee for Anon.

>>1279

For multiple monitors, try pressing 'f', or hit the 'fullscreen switch' (tooltip) button in the top hover window of the media viewer, which should convert it to a normal window. The button looks like a couple of windows overlapping. The media viewer should remember its position and maximised/borderless state, but let me know if it doesn't.

I would love to build an efficient tag downloader for boorus, but I would need them to supply an API call for me to do it. Their API would have to accept file hashes, either MD5 or SHA-whatever, and then return tags. I could then say to the booru "Hey, you got any tags for [file]?" and they would say "Yeah, [tags]." Or they would need to support something like muh_booru.net/post/[file_hash] in addition to their existing muh_booru.net/post/internal_booru_post_id systems they use.

Unfortunately, I currently have to download the file if I want any tags, as I need the file hash to associate those tags with, and the file hash can only be generated by having the file itself. There are ways I can be clever, like if you have downloaded the file before, the client will remember that and will be able to reproduce the hash without having to download the file (that's what "get tags even if file is already in db" is about).

Again, if the boorus wanted to provide some xml/json/whatever API that was something like "Hey, booru, can you give me a hash->tags dictionary for this query?" I could do it and cross-reference with the files already in your db, but the API that danbooru and some others offer doesn't give hashes and at the API level doesn't namespace the tags. At the moment, my parser walks through every gallery page, picking up image pages, and then goes through each image page in turn, harvesting tag lists and image links.

4chan and 8chan bundle the MD5 hash in their API and it is great. I can check for redundant and deleted files without having to download, but boorus do not do it.

Sorry, I feel I didn't explain that very well. Let me know if you still have questions. TL;DR is that it is currently technically impossible to just download tags from a booru and insert them into the db. They need to offer more information on their end.

>>1280

Thank you for the note about the deviant art button. I though the click-zoom (which loads an image with the deceptive classname 'dev-content-full') was the same resolution, but it isn't! It looks like there might be some referral or cookie hoop I have to jump to get the button's link to load, but I will see what I can figure out.

I don't know much about g.e-hentai and exhentai. Isn't one like a login for the other, and one hosts loli or something? I am all for writing a plugin, but I want to do per-site bandwidth management in my next network engine iteration, so if there are complicated bandwidth limits then maybe I should put it off until then?


 No.1289

>>1288

>try pressing f

HOLY SHIT HOW DID I NOT REALIZE THIS WAS HERE

Also thank you, I understand what you mean about the tag downloader, shame about that.


 No.1290

>>1288

8chan can pull md5 without downloading an image with the api? This is where you might lose me in technicality, but, is it possible to use this to pull md5 hashes from the site without downloading something to your hard drive?


 No.1291

File: 1445727442521.png (10.16 KB, 222x273, 74:91, e49f8a52bd7fe475c1131a9cca….png)

>>1290

Yup, it's actually not complicated at all. In fact, you can go to the json endpoint of this very thread just by replacing the .html in the url with .json: https://8ch.net/hydrus/res/471.json . Just do a Ctrl+F for "md5" and you can see what he's talking about.

>>1288

I was actually interested in the ipfs python api myself and decided to look into it. For testing I used the hash QmPZ9gcCEpqKTo6aq61g2nXGUhM4iCL3ewB6LDXZCtioEB as that is the standard welcome document that comes with every installation of ipfs and is unlikely to change. Don't quote me on that, though, it might not work in the future.

It looks like a call to api.cat() will return the contents of whatever hash you want, and any errors will raise a general ipfsApi.exceptions.ipfsApiError with the message describing what actually went wrong.

An invalid hash, for example, with have the message "invalid ipfs ref path", and a timeout should have the message "context deadline exceeded". I'm not sure what the default timeout for it is, but you can set your own by sending {'timeout': '<time>'} as the "opts" parameter in the call to api.cat(), which is the equivalent to "ipfs cat <hash> –timeout <time>" in the go client. <time> has to be both a number and what unit your using ("s" for seconds, "ms" for microseconds, etc.)

This is what I used to catch different types of errors. There are probably better ways to do it but it works for now and should answer your question:

import ipfsApi
api = ipfsApi.Client('localhost', 5001)

def retrieve_file(hash):
try:
return api.cat(hash, opts={'timeout': '30s'})
except ipfsApi.exceptions.ipfsApiError as e:
msg = str(e)
if msg == 'invalid ipfs ref path': return 1
elif msg == 'context deadline exceeded': return 2
else: return 3

contents = retrieve_file('QmPZ9gcCEpqKTo6aq61g2nXGUhM4iCL3ewB6LDXZCtioEB')
print(contents)

Hope that helps! Also, thanks for fucking everything man. You really made my day.


 No.1292

File: 1445728128325.jpg (520.71 KB, 1116x1100, 279:275, ac72c83efe2ef45c55b8294a44….jpg)

>>1291

*milliseconds

Basically the same, right :^)


 No.1295

File: 1445794630264.gif (323.38 KB, 500x333, 500:333, excited.gif)

Oh man oh man if IPFS support gets added to this I'm gonna freak out (in a good way).

https://blog.neocities.org/its-time-for-the-permanent-web.html


 No.1298

File: 1445808381542.jpg (134.18 KB, 680x871, 680:871, ad481ce789025ebae5fce3eef3….jpg)

>>1290

As >>1291 says, I need an API that'll give me the MD5. I just looked at Danbooru's and they actually do offer that in their json API, like this:

http://danbooru.donmai.us/posts.json?tags=blue_eyes

I guess I forgot they did, because I do remember looking at that before, or that is a new addition. Moebooru boorus offer something similar, but looking at this:

http://konachan.com/post.xml?tags=kantai_collection

I don't see any hash info. EDIT: Wait, it does, I was searching the wrong thing. Nonethless, in both, the tag list is not namespaced, so in order to get better tags, I would have to pursue the image page. That's not bad (although I don't really want to make a habit of hammering them with 20-100KB page requests just to harvest namespaced tags), but since the API request calls and responses are different across boorus (and some are unreliable, like http://gelbooru.com/index.php?page=dapi&s=post&q=index which currently gives me an error about overuse), I have shied from extending the already-messy services->manage boorus to support different APIs. Perhaps that is a long term project I can do, or it can wait for when downloaders are more complicated plug-ins that users can write themselves, which is a long-term goal.

>>1291

Thanks, this info is great. I will have a long recheck period (something like four hours, I guess) and bottleneck the number of files to attempt so hydrus doesn't end up hammering people's IPFS daemons every twenty minutes with 500 spurious hash requests (each of which I presume sends out some request to other nodes across the network), and also to abandon the download if a file can't be found after x requests.

Post last edited at

 No.1304

File: 1445852102021.gif (50.88 KB, 300x225, 4:3, 1363370082778.gif)

>>1291

by any chance, could a bit of js be written to display md5 hashes next to images as one browses 8ch?

Sadly I don't know js and am completely incapable of writing something like that myself, but it could turn out to be incredibly useful if I had something like that


 No.1308

>>1304

I assume Greasemonkey could do something like that, but I don't know anything about coding for it, so I'm afraid I can't personally help.


 No.1312

File: 1445895361120.png (401.07 KB, 857x1000, 857:1000, c46bb9d29b4e03533af46ef97d….png)

>>1304

https://greasyfork.org/en/scripts/13395-8chan-md5/code

Have fun! If you don't know what a userscript is just use the help on that site. On some posts it doesn't work because they're so old they don't have a recorded md5 on 8chan, at least it appears that way.

For some reason the md5 is embedded as an attribute on all 8chan img tags, but not exposed as text to the user? So this was super easy, almost a one-liner with jQuery.


 No.1313

File: 1445912454356-0.png (622.09 KB, 830x641, 830:641, rating-color-text-bg.png)

File: 1445912454361-1.png (630.58 KB, 830x641, 830:641, rating-color-overlay.png)

Is it possible to have files which are rated, identified by a color? This would let me see what files I have rated without running a system:rating search/sort.


 No.1317

>>1313

I like this idea and the mockups you have made a lot. I think I will generalise it so users can set their own predicates, like:

file is rated in some way on some/all rating services

file has some number of tags on some/all tag services

And then doing the colouring with semi-transparent tints to mix with the otherwise default colours for any of:

thumb border

thumb background

the namespace text at the top

your overlay example.

Thank you. I have created a job and a plan for this. It might be a little complicated, so I will first create something simple, maybe just starting with the overlays and specific ratings. I'll be doing a bit of thumbnail code cleaning soon, so that would be good time to start this.


 No.1318

>>1317

Glad to see you're looking into it. thumb border colors is good enough for me, or whichever operation consumes the least amount of memory.


 No.1322

I don't know if it's a feature or a bug, but when introducing tags I can't use neither the button END nor HOME, or use the CTRL or SHIFT modifier to select or move around. If I mispelled something (especially when starting a new database) it can be a little bit annoying to either switch to mouse or mash the backspace key.


 No.1329

File: 1446126302751.gif (1.2 MB, 312x171, 104:57, 1369170016597.gif)

>>1312

Thats awesome! Just added

question though, if I want to make the md5 appear a line down, where would I put \n, OR is there a way it could a little [-]/[+] be made to hide/display it?

Ive already got a save as original filename script lengthening that row of info, so now its REALLY long lol

Great work btw


 No.1334

File: 1446141701739.png (495.26 KB, 714x1000, 357:500, bdeceee017d67d6c7781e12d75….png)

>>1329

I added a break before the MD5 (html uses <br/> for newlines), hopefully that unclutters things for now.

I'll add a +/- thing in a little bit.


 No.1335

File: 1446161991434.gif (1.1 MB, 200x250, 4:5, 1433165781910.gif)

>>1334

Saw the updates go through, looks awesome!

thought it was js, my bad, didn't realize it was html


 No.1342

File: 1446315005523.jpg (146.8 KB, 997x1364, 997:1364, c438cb670367927220e63fb898….jpg)

>>1322

This is difficult because if you type something in, the autocomplete dropdown (the list where all the tags appear) needs to grab the vertical navigation keys (page up/down, home/end, arrow up/down) before they can propagate to the textbox so you can navigate the list of results. Arrow left/right should work, and with ctrl and shift. Does ctrl+arrow left work for you?

I could stop the list from grabbing the key events when there is only one result, which would often happen with a bad spelling, but I am not sure if that would be jarring/confusing. I'll change it for next week, and we'll see if it is helpful.


 No.1346

You know what, don't change anything, it was a stupid suggestion. I am used to using home/end, that's all. I can live with pressing a few times the left button. I really didn't think the whole thing through.


 No.1350

>>1268

For the similar detection code, maybe you could use/look up the code of imagemagick. I believe the people that made VisiPics used it and it was really powerful.


 No.1383

File: 1446947482854.jpg (694.88 KB, 752x1062, 376:531, e2eccab9d83d9eeae85ea51a53….jpg)

Hey dev, I always find it incredibly time consuming that I have to exit the tagging dialogue when using it with the full screen viewer, to archive or rate files. Any chance you could include the rating option and an archive button, or enable the shortcut to work when the tag dialogue box is open?

I usually skip ratings all together because of this, and id like to use them more than I do. I usually have to close the tag dialogue and the media viewer then highlight everything ive been tagging to archive, and I get crashes every once in a while, and I usually set my inbox to random order, so I often end up not being able to hit archive on a bunch of files that are now tagged.

The crashes are to be expected on my end, my hydrus library has now passed 100,000 images, i had to move it off my ssd because its too big, it gets a bit buggy now, especially when tag selecting ill have to wait a moment. But really at that size, again, expected


 No.1384

File: 1446957902611.png (43.34 KB, 771x530, 771:530, 200.PNG)

Hey, just started looking into this program, and it seems amazing so far, but I've got two suggestions I'd thought I'd post before moving my collection into it.

First would be a source field.

Keeping the source of an image has always been important to me, and I've found ways of saving the source with pictures via file names and folders since I started my collection. It hasn't been the easiest or cleanest, but it worked.

However, Hydrus copies imported images with different file names to it's own directory, so I'd lose all the source information I saved with the images.

It'd be awesome if you could add a source field into Hydrus somewhere for images, possibly multiple for artists who post their pictures across multiple websites, so I can import and organize my collection in Hydrus without losing the source of images.

Second is more of a personal preference, but I'd suggest adding an option to change how zooming in on a picture looks.

Zooming in on Hydrus makes the image become all fuzzy, which makes pixel art look poor, jpg compression a bit harder to spot, and makes the image look poor.

I could just open images externally to image preview, but I thought I'd suggest the idea anyway.

Sorry if either of these have been suggested before or are already planned, but thanks if you consider looking into them.


 No.1388

>>1384

Why don't you just use a tag with a "source:" namespace?


 No.1389

File: 1446963685477.jpg (20.6 KB, 223x113, 223:113, .jpg)

This has probably been asked a few times already, and there's probably a reason for this, but

Why doesn't Hydrus have this?


 No.1390

>>1388

Didn't think of that, I guess it'd work.

Still wouldn't be a nice as a proper source field, but putting it as a tag probably wouldn't be any worse than putting it in the file name.


 No.1391

File: 1446980545489.gif (1.23 MB, 480x480, 1:1, 9835a357fa3c3af9d3675c16e6….gif)

System tag for if image/gif is transparent?


 No.1399

File: 1447008504461.jpg (412.28 KB, 1200x1600, 3:4, c7b5afafa17e3dd8024bca558a….jpg)

>>1350

The tricky bit is the search algorithm. There are several ways to compare two files, but comparing n files in anything less than n-squared time is tricky. (I can't remember the exact math, but comparing 100,000 files by doing them all in turn would take something like 5-10 billion comparisons!)

So instead, you basically have to store the chunks of data that represents your images (I use a perceptual hash based off of a DCT of the thumbnail) in something like a VP-Tree that allows for quick hamming distance comparisons, and then encode that data structure in a database and then write some clever insert/remove/search functions to maintain and use it.

At the moment, I store the phash and can do "Is this single file like any of these 100,000 files" in 100,000 inefficient db hits, which usually takes a second or more.

Getting this to be n log n or whatever is all doable, but I just need to find the hours to point my brain at the problem.


 No.1400

File: 1447010085900.jpg (433.46 KB, 1502x1510, 751:755, 3fcfebafa37104283ee71dafd3….jpg)

>>1383

I had a plan to copy everything in the top hover window (the one with archive and prev/next buttons) to the tag dialog, and then it got overtaken by other things. I have put it up to top priority.

ACTUALLY: Maybe I should instead move the tags dialog into the media viewer? If a click of the tags hover on the left were to 'pop-out' a fully-fledged manage tags panel, maybe that would be better. Or keep it launching a window, but make the manage tags dialog be a frame instead, that isn't on top? So you can drag it about but still interact with other things.

I can make it a frame pretty easy, so I think I will experiment with that. I am not happy with the general multi-filtering-workflow, and I think the clunkiness of dialogs is a part of that.

>>1384

For the first thing, as >>1388 suggests, I think tags will generally do what you want. If I add a box for source or any other specific variable, then I have to add ways of adding and removing and searching and efficiently harvesting that info, when from a data standpoint, it is still a bit of text.

If your important information is stored in filename, and if it is stored in common patterns, you can capture that information very quickly and powerfully with regexes. If you haven't heard of them, they are a great but 200% autistic tool that can convert one bit of text to another.

When you are about to import some files, hit add tags based on filename. Hit add on the quick namespaces panel and do something like

source : (?<=\\)[\w\s]*?(?=\..*$)

There are also ways to get directory and parts of a filename and so on and so on. When you hit ok on that sub-dialog, you will see a preview, so you can go back and edit the regex if it doesn't do exactly what you want.

If you already know regexes, then you are fine, but I am also happy to help, and other people on the board know much more than me. I don't really like them, but I don't know of a better tool.

Also, if you download from hentai foundry or whatever inside hydrus, you can set source:hentai foundry as an explicit tag for everything you download in the tag import options panel. Let me know if you would like any help using this.

For the second, I agree. I want to add some simple 'zoom to fit?' options for each mime, but I think I should allow people to choose which resizing algorithms are used as well. There are some bugs in the zoom code too.


 No.1401

File: 1447010742012.jpg (246.59 KB, 1425x1772, 1425:1772, 03fb0dd7e40e1c5d77ef8e1a03….jpg)

>>1389

I haven't written it yet! Several controls in the program (like the thumbnail viewer) hold too many objects for OSes to handle with normal gui elements, so I had to rewrite them all with custom code. As a result, I have to rewrite basic stuff like shift-selection and so on from scratch.

Funnily enough, I don't think anyone else has suggested drag select yet, although now I think of it, I have wanted it myself a couple of times. It shouldn't be too tricky to add. I will put it on my to-do list, thank you.

>>1391

It looks alright for me. Which OS are you using? What colour do your system predicates usually have? Is the text not showing but the predicate still has background a colour when you select it, or have I misunderstood your problem? Can you post a screenshot?


 No.1402

File: 1447023227039.png (3.92 KB, 424x49, 424:49, _source.PNG)

>>1400

I don't know anything about regexes, but I know you touched them briefly on on the help part of your website and linked out to a full guide, guess I'll have to look into them.

Just to clarify what I mean though, I'm not talking about adding "source:deviantart" or "source:paheal", I'm talking about saving the actual source URL of the image.

So what I meant by source field was a separate thing from tags, where a clickable link would be placed, like on paheal or gelbooru.

That'd also mean you probably wouldn't need to worry about adding in ways to search for or by sources.

Although, it sounds like I'm more or less the first person to suggest a source field, so I guess there really isn't any demand for the feature.

If there isn't enough demand to justify the effort of adding it, that's fine. I managed to found a way to put the source URL into file names, I can probably make it work with a tag.

It just would have been nicer to have a proper source field with a clickable link instead.


 No.1404

File: 1447082615409.jpg (58.95 KB, 500x378, 250:189, 0f2e74a11e8f4ead8e44d25adb….jpg)

>>1401

I think >>1391 is suggesting that you add a global system tag for when images have transparency, not complaining that system tags for him are transparent or something.

I actually thought the same thing and had to re-read his post, though, so I blame his wording.


 No.1405

File: 1447116864896.jpg (162.46 KB, 1024x645, 1024:645, Official Ron White - I Got….jpg)

You talked about offsetting thumbnail generation "so every video doesn't just have a black thumbnail".

Why not take it a step further and generate multiple thumbnails per video? See picture.


 No.1409

File: 1447192334774.jpg (431.97 KB, 738x536, 369:268, 5e46055c47e36f57828d9222fc….jpg)

>>1402

I see, that's an interesting idea. Anything you download from a website inside hydrus actually has its 'page' url saved to the db (so the client can know to skip a download if that url turns up in a subsequent gallery search), so this particular information is already supported somewhat. It would not be too hard to query this cache and expose it to the gui in a 'known urls/I have got this from' list or something from a thumb's right-click menu. This information could also be shared amongst users, and that might be very much a useful thing to do. Let me think about it a bit, and then I'll prototype something.

>>1404

>>1391

Thank you, I read it wrong.

Transparency info is something I don't currently cache in the db, so I can't search it. Once I add efficient dupe searching, I will likely be adding additional 'this image is like' information, like 'redness' and 'lots of curves' and 'sharpness'. This system could support 'has transparency in its palette' very well, so please remind me when we get to that point.

>>1405

This is the plan. I will move to all animations having gif thumbnails with up to say ten frames, and then you'll be able to set a custom offset for the 'display' frame. Also, I'd like to have these thumbs do their rough animation when you mouse over them.


 No.1413

>>1400

Being able to select either/or would be useful.

I typically seperate them now, usually the image viewer in the upper left, tag dialogue on the lower left, and some anime on the right side of my screen.

I like having it as a seperate window, but being able to select both, or adding the clickable things in the image viewer would be great options, or what you said.

Also as is now, the only thing that changes size is the list of current tags, you should allow the spacing on the tagging dialogue box to be changed for the other windows, so the list of tags based on what you are typing, and the window on the left for which tag repo you are using can be shrunken as well


 No.1440

Is there a way to add explicit tags to files being imported?(not downloaded/subscriptions)

I only see add tags based on filename


 No.1444

File: 1447604202351.png (17.49 KB, 530x695, 106:139, uQbTODt.png)

>>1440

Make sure you have version >=180


 No.1445

File: 1447604367489.png (54.61 KB, 1748x901, 1748:901, Screenshot_1.png)

>>1444

Or here (i don't quite understand what you mean as both options are obvious for me)


 No.1446

>>1445

Thanks. Didn't realize it had more options in it.

I never clicked the "Add tags based on filename" because I assumed it would automatically start trying to add tags from the filename.


 No.1456

Suggestion: Hotkey for tag autocomplete

Basically, I want to be able to hit a hotkey and have my tags auto-complete instead of waiting on a character threshold or long/short wait timer.(Manual auto-complete?)

For example, if I type 'creator:princess', it will populate quickly. If I had it set to a long wait, then it'd be needlessly waiting on something that can be processed quickly. if I were to accidently type 'creator:' though, i'd be waiting around 20 seconds for it to finish while my gui is frozen.

With a hotkey, I can type 'creator:princess', press 'Tab', and it'll automatically start the auto-complete. This way, I can control exactly when it'll search for tags. Of course, you can also allow a hotkey in conjunction with wait timers too.


 No.1461

File: 1447818889562.png (205.1 KB, 604x900, 151:225, 87666bf2a8fe67980e6e0b4ca5….png)

Would it be possible for the tumblr downloader to be able to pull from the source link of a post if it's an appropriate mime-type and exists?

I'm not sure if the behavior should to be to download the source instead of the post (because there can be multiple images and only one source) or just download everything, source & post, perhaps an option?

Here's an example blog that uses the source to link to higher res versions of the posted images (as it seems tumblr limits resolution on uploads): http://t-hoodie.tumblr.com/


 No.1475

So today I realized that if a file is tagged with both 'pov' and 'looking at viewer', it should obviously be tagged with 'pov eye contact'. I made a new tag parent that works the other way around, but going from two tags to one new isn't supported. I know that the pov eye contact tag seems a bit useless if you can just search for pov and looking at viewer, but it just feels like it could possibly be a useful feature of some sort.


 No.1479

File: 1448221847778.jpg (327.9 KB, 960x835, 192:167, 650f2f136fab7a8b50f77621cf….jpg)

>>1456

This is a great and simple idea that I can add quickly–thank you. I will add an option for it, and hardcode tab as the shortcut.

>>1461

I really like the idea (I didn't know tumblr had that source thing–I assume it appears if you embed an image from a url or something?), but I am not sure how to harvest that url information. I use the old tumblr api to generate links, like so:

http://t-hoodie.tumblr.com/api/read/json?start=0&num=50

I can't see that 'source' information or the puu.sh links in there. I looked around and found a per-post api, like this:

http://t-hoodie.tumblr.com/post/133375777797/json

But I can't see it there either. I could write a new parser to parse each post for a 'meta-item source-link' class tag and harvest the href from that, but I won't have time to do that for a little while. Do you happen to know of another API I can plug into, or anywhere else I can get that puu.sh link? Or even a way to get an rss or json or whatever of the artist's puu.sh links directly?


 No.1480

File: 1448222207735.jpg (149.56 KB, 981x990, 109:110, ed4e9e6ac9b7fc37537e0e2beb….jpg)

>>1475

I love the thought of adding these complicated sort of rules for parents and siblings, but it will have to be something for the future. For the moment, please add those sorts of tags manually.


 No.1484

File: 1448332026959.png (355.39 KB, 1181x935, 1181:935, 0d9b055617e6ab41d4bb6cac79….png)

>>1479

The source link is manually input on each post, I'm not sure how widespread it's use is on tumblr. I had assumed you were scraping tumblr pages like booru pages and could have just scraped the <a> tag, which thinking about that now doesn't seem like the best solution as tumblr blogs are theme-able and the source link class could differ per blog.

Looks like the v2 api exposes the source url.

https://api.tumblr.com/v2/blog/t-hoodie.tumblr.com/posts?api_key=fuiKNFp9vQFvjLNvx4sUwti4Yb5yGutBN4Xh10LXZhhRKjWlV4

(I don't know who's api key that is. It shows up in the api docs https://www.tumblr.com/docs/en/api/v2#posts)

Also, there's apparently an official client library for their api

https://github.com/tumblr/pytumblr

not sure how useful that is to you, also not sure how viable it is using the v2 api, as hydrus would need a consumer key for tumblr, perhaps have the user request the key and input it to hydrus?


 No.1489

File: 1448391367042.jpg (234.53 KB, 1649x1403, 1649:1403, bb7c758ce6dfdd532ee099e987….jpg)

>>1484

Thank you for this information! I think this is ultimately something I will leave to users to create once my downloader engine allows people to create their own gallery parsers. I don't want to mess around with non-open APIs if I can help it.

For now, I suggest you make a job to check that tumblr every x days and manage the download and import cycle yourself. I do this for several webcomics and artists I follow that I would never have time to write individual parsers for, batching up a month's worth or so and then importing and tagging them in an efficient group.


 No.1497

File: 1448536238794.jpg (726.14 KB, 1280x905, 256:181, Konachan.com - 210153 anim….jpg)

>>1489

Alright, thanks for the advice. I'll probably end up writing that parser when hydrus does come to support that.


 No.1505

When a subscription fails to download a file, it does not give any notifications about it. I only found out about it when I realized I didn't have a new image from one of my subscriptions.

This also ties in to another idea I had where you could scan your subscriptions and get, for example, subs that haven't gotten any new images in a long while, or ones where you've archived the least amount of images… But for now, maybe some way to know that your subscriptions have failed files?


 No.1508

File: 1448665944994.jpg (140.48 KB, 984x1316, 246:329, c0fe4592fc476f42c866a8f9b8….jpg)

>>1505

Thank you for your thoughts. I think I want a button somewhere that says 'retry all failed subs files' or something, and for per-sub as well, and maybe a way of reviewing this info en masse. Maybe I could stick a generic 'my subs' service on the review services window, under local? Or I could put some extra info in the list of subs in the manage subs dialog? Maybe colour 'inactive' and failing subs' names a different colour? Or have a checkbox to filter them?

I can easily add some text to the manage subs dialog's subs panels, like '3 failed files', rather than hiding it all behind the import status button, so I'll start with that.


 No.1516

>>1508

I think some sort of generic "subscription management" window could be helpful. Considering subscriptions is the feature I use the most in Hydrus, it feels to me that being able to see various subscription stats and maybe even filter/order them (last update, last update with a new file, last update with a new currently archived file, failed files etc) would be very convenient. I do wonder, however, how slow such filtering would be.


 No.1521

>>1516

+1 to this.

I also use subscriptions a ton.

Are you going to allow update intervals to be lower than 1 day? I have a high traffic sub, and being able to set it to every 3-5 hours would be nice.


 No.1526

File: 1449094544429.jpg (343.09 KB, 1372x1600, 343:400, 457bb0b964bbb1174ad63ca3c5….jpg)

>>1521

Sure, I will create a new control to allow hours as well as days.


 No.1539

Minor change. The selection tags context menu should have "include this tag in current search" and "exclude this tag from current search" options.

I know double clicking the tag will add it to the current search but I haven't found a way to exclude a tag using only the mouse.


 No.1541

hydrus newbie here: love the program!

I would love it even more with two usability improvements:

- a way to favorite tags. (where do you keep your lists of favorite artists?)

- a way to drill up/down while browsing pictures. example: I look at pictures with tag a fullscreen. a certain picture looks really cool. I press key b. The program automatically switches to showing pictures with Artist/series tag of cool picture while downloading more of said tag. I press key c and resume looking tag a pictures.

thanks for writing this program, keep up the good work.


 No.1542

File: 1449340885221.jpg (3.28 MB, 3762x2866, 1881:1433, df84ecb2c06eb77eaf944d4d40….jpg)

>>1539

This is a great idea, thank you. I have written some intelligent menu items for selection tags and the active predicates boxes for next week–depending on whether the tag or -tag (for any of the currently selected tags) exists in the current search, the menu will provide up to four options for remove/require/permit/exclude. It seems to work well! Let me know if you have any problems with it in v185

>>1541

These are both great ideas. There is a thought to add a tag cloud or something in the future to quickly display and search popular tags–it would be easy to add favourites to that.

For jumping between browsing and searching, for now you might try middle-clicking the the 'creator:blah' tag, which should open up a search page for that tag no matter where you are. You can then alt tab back to your media viewer window when you want. You can also right-click on a tag for a menu to quickly copy it to the clipboard, which might help quickly downloading more from a gallery.


 No.1573

I've had hydrus for over the weekend, and here some features and things I thought of. I wouldn't be surprised if a handful are already implemented.

page tags in order

hide page tags unless looking at only one image

when in image view, just start typing to add a tag (can also ctrl+v tag)

option for tagging order of images when importing, (or regex shortcut for this)

booru-on-rails support would be nice

support for groups of images on boorus (like pools or collections)

option to remove dash between page chapter volume etc marks

button to open externally when memoryerror occurs

ability to add custom thumbnails for flash files

option for regex to only apply to file name, and not full path

can't exit view except for force quitting when fullscreen viewing a flash that is the same resolution/ratio of monitor


 No.1574

File: 1450123038629.jpg (483.87 KB, 600x900, 2:3, 3420b6c8831a3794e745e7fd9b….jpg)

It'd be really cool if there was a way to mass add subscriptions.

I bookmark all the artists I'd like to collect the art of and just recently wrote a script that turns the bookmarks into a list of tags categorised by service. It's A LOT of stuff to enter by hand and I'd much rather have a way of importing them automatically, whether it be through some custom import format or a direct python api.


 No.1582

File: 1450204238241.jpg (396.28 KB, 839x1024, 839:1024, 17dcee4bf7f2051c3680f8e643….jpg)

>>1573

Thank you for this list.

You can sort by volume/chapter/page namespace (not very well, but it generally works) under the sort dropdown on the top left of most pages.

Also, you might be able to tag by import order like you want if you click 'add tags based on filename' instead of 'import now' after you have some pending imports listed. The little bit labelled '#', middle bottom, tags based on the # column in that dialog's list. You can set an offset and a step and a namespace, which should let you do quick page tags if that information isn't easily parsable from the filename.

I force flash files to be slightly smaller than their media viewer frame, so you should have a slim gap on every edge to quit or bring the hover windows to the front if you are in fullscreen. Let me know if that doesn't work for you.

The other things I have added to my to-do list. Some I already hope to get to as part of larger features.

>>1574

Better mass-handling of subs is a planned feature that'll be on the soon-to-come voting list. Doing mass-adding is a great idea to add to it, thank you.


 No.1598

I'd like a way to know when I'm importing files when they are already in the db/deleted so I can quickly identify the image, like an icon next to the others. This would enable me to check

better why I haven't deleted the original yet.


 No.1602

File: 1450550842035.jpg (539.15 KB, 1264x1652, 316:413, 835b4c1b8f995167077192f78e….jpg)

>>1598

Thank you, that's a great idea. Icons would be good, but I might be able to add this as part of another system I am planning, like the custom thumbnail border thing (i.e. you could set: "if file is less than an hour old, give it orange border"). I will think about it a bit.

Until I can get something done on this, you could try sorting by oldest/newest first, which will put all the new files at the bottom or top.


 No.1607

File: 1450573759956.jpg (80.69 KB, 475x690, 95:138, mask.jpg)

We already have the '-' sign to exclude a tag from search results, how about adding the '+' sign to include a tag's results even if it doesn't match what's already there? Basically an "or" search.


 No.1612

File: 1450641619262.jpg (150.64 KB, 1333x717, 1333:717, fea5f239fbe29ea320917542df….jpg)

>>1607

Now I think of it, adding OR searching logic was something on the big to-do list. I will put it on the poll for next week.

Using + is a good idea, but I am not sure how you would differentiate which parts of the query you wanted to OR with and which you wanted to AND. I think my original idea for that was to say that shift+enter would start a predicate OR chain and normal enter would end one, so you could create complicated queries like:

system:size>1MB

character:shinji

character:asuka OR character:rei OR character:mana

Which would give you large images with shinji and one or more of the girls.

Funnily enough, the db search code for this is fairly easy–it is getting the gui workflow and feedback right that seems to be the impediment.


 No.1678

I'm not sure if these have already been requested before, but here goes.

How about an option to hide the tab bar if it's < 2 tabs? Would save on some screen real estate

And one more, for regex favourites - When adding tags based on filenames you can only save favorite expressions, but not a namespace for them. Making the namespace default to the name you assigned the favorite would save a lot of typing if you like me keep re-using the same combination


 No.1689

File: 1451762004180.jpg (74.49 KB, 500x530, 50:53, 2eba2e39ff2a322d6e3cca3c8d….jpg)

I'd love if we could add a permanent tag to different sources.

For example; Idol Complex, I'd love that every file downloaded from there would have a tag "3dpg"

Alternatively, we could do save tags from what booru files are from when downloading (#130) and then it would be up to the user to parent those tags to other tags, like 3dpg.


 No.1690

>>1689

by save tags from what booru files are from when downloading (#130)

I mean https://github.com/hydrusnetwork/hydrus/issues/130


 No.1691

Is there an IRC or something available for hydrus?


 No.1696

File: 1451868400621.jpg (2.47 MB, 2765x2386, 2765:2386, 9db730113b50eef37e2bea7302….jpg)

>>1678

I am not sure I can do your first suggestion easily–I use a wx.Notebook for the main page display, and I don't think it supports hiding the tab area. I would probably have to write my own custom notebook control to do that. But I may have to end up doing that anyway when I eventually go for tab dragging/reordering, so perhaps I can add tab hiding once I have that done.

Your second suggestion is planned. I ran into the exact same annoyance myself yesterday. I will have separate regex favourites for the namespaced and the unnamespaced controls, and make it so if you select a favourite for the namespaced area, it pre-fils the text fields rather than copying to clipboard. Perhaps I will do it with dropdown choices. Anyway, thank you, I have it planned.

>>1689

>>1690

You should be able to do this with file-options->default tag import options and then setting an explicit tag for a particular site. e.g. you could add 'site:hentai foundry' to the hentai foundry default import tag, and then anything you subsequently set to download from hf, or any new subscriptions you created for it, would have that explicit tag pre-set.

I think the default tag import options extends to individual boorus, so you should be able to set '3dpg' for Idol Complex.

>>1691

I haven't set one up, so I don't think so. I'm afraid I don't really do chatrooms/IM.


 No.1702

>>1696

>>1689 (me)

>>1690 (me)

Thank you very much.


 No.1709

Not necessarily a suggestion, but what do you think of https://nik.bot.nu ?

It might interest you.


 No.1710

Is there a way to add new namespaces to the collection dropdown? I'd like to be able to collect by character or artist, for instance.

Also, I've found there's a few inconsistencies in namespace tagging. Some boorus use "artist", others use "creator". Sometimes pokemon are tagged by "character", and other times by "species", and so on. Should I start adding in tag siblings to resolve these?

Or could something like namespace siblings be possible? Although that's probably too dangerous and of generally limited use, now that I think about it. artist -> creator or vice versa seems like a pretty safe bet, but trying to do character -> species for pokemon only is bound to cause trouble doing it any other way than tag siblings.

What about a 'soft' association of namespaces that's set by clients and doesn't actually touch the tag repository? Like, I could set my client so that if I search for 'creator:<tag>', then it searches for 'creator:<tag>' OR 'artist:<tag>', depending on how you decide to get OR predicates working. Right now you can just search <tag> to get all the namespaces, but that doesn't work if you right click to open a new search page with a tag.


 No.1712

File: 1452103832026.jpg (713.8 KB, 1800x1081, 1800:1081, d7aa20535da8d906c75ea190e8….jpg)

>>1709

It does, thank you! I had never heard of it before. I love the aesthetics and animations of the ui, and I particularly like the five colours it puts beside the image in the detailed view.

Hydrus might have looked a bit like this once, but I just found that browsers didn't give me the kind of large-data power I wanted.

>>1710

You can change the collect namespaces, but be warned that it is very ugly. Go file->options->sort/collect. The collect by namespaces are derived from the sort by schemes, which default to 'series-creator-title-volume-chapter-page' and 'creator-series-title-volume-chapter-page'. To add a new sort entry, enter the namespaces in the text box at the bottom, ordered by sort precedence and separated by hyphen, and then press enter. Double-click an existing scheme to delete it. You might want to just add 'artist' to begin with. Then any new pages should show that new scheme in its sort by dropdown and any new namespaces in the collect by dropdown.

I apologise that this ui is so ugly and unexplained–I threw it together after I first got collect working, and never got around to upgrading it from its current 'debug' level.

Yes, please feel free to add artist->creator siblings to my PTR. I like the species namespace for pokemon and digimon and so on as well. Don't bother to give a long reason–I'll approve anything obvious.

I do plan to support local namespace siblings, probably through an expansion of the current tag censorship system. I might also add that meta-sibling relationship to be sharable through repositories. I appreciate that some people would always want to see 'artist' instead of 'creator' or 'copyright' instead of 'series', or would want to unify semantically similar namespaces from different tag repos that use different standards, or even to translate these terms to different languages.


 No.1713

>>1712

Ah, thank you. I saw the sort/collect page, but I just assumed the text box was for sorting only.

I'll go ahead and start adding in siblings.


 No.1720

I probably just didn't find it but is there a "always maximize pictures to fill entire screen" toggle? Because I really want it.


 No.1722

>>1720

I think images automatically fit to height.

You can enter fullscreen using F11 and zoom in and out using + and - .


 No.1727

>>1722

yes large pictures get downsized, but I also want to automatically enlarge small pictures. the zoom button does this manually but I want to set this as the default option.


 No.1735

File: 1452359243950.png (148.35 KB, 730x1011, 730:1011, b26f14e44e39695020b4ccb68b….png)

>>1720

>>1722

Try file->options->media->zoom smaller media to fit media canvas. I'd like to make this more complicated in future, as well, like for saying 'if a png is > 100% and less than 120% zoom at fitted size, just show it at 100% so its pixels stay sharp'.

The default shortcut for making the media viewer fullscreen borderless is 'f'.


 No.1767

>>1735

thanks.


 No.1844

File: 1453285912295.jpg (645.6 KB, 1280x1029, 1280:1029, 810404fa69d53d1d919d8f0b59….jpg)

Yo!

we have ffmpeg a part of the package

Can we get a method to convert a video into another format (mp4->webm) on/before import for storage


 No.1848

File: 1453318435258.webm (5.69 MB, 640x360, 16:9, 70c7c4a8eb75b948eb532c70a….webm)

>>1844

That's a good idea, thank you. I like the idea of conversion on import and also from the right-click menu.

I would probably add a warning for any conversion to webm though, as the codec introduces some random data that means every generated webm has slightly different content (and thus file hash), which makes it an extreme pain in the ass to match up differently generated webms across clients.

For instance, if I go:

ffmpeg -i a.gif a.mp4

ffmpeg -i a.gif b.mp4

The two mp4 files will be exactly the same byte-for-byte, but:

ffmpeg -i a.gif a.webm

ffmpeg -i a.gif b.webm

Creates two slightly different files. Importing a.mp4 and b.mp4 would give '1 successful, 1 already in db' and one thumbanail, but the webms would give '2 successful' and two thumbnails. This is fine right now, where webm generation remains rare and the same original webm file is usually shared across imageboards so everyone imports and tags the same file, but if I automate mass webm production via conversion, we'll just be massively diluting our hashes.

Out of interest, why are you thinking of collapsing everything to webm specifically? Or did you just pick mp4->webm as a random example?


 No.1856

File: 1453342497736.png (14.22 KB, 747x178, 747:178, 16-01-21_13-11-18-Properti….png)

>>1848

webm is made with web content in mind, it's much smaller than gif/mp4 files when done right (unless it's a tiny gif or something)

Imageboard is a plus, as webm has been adopted into it's culture, but more importantly it's easier for me to share/upload due to the compression(??) in the format

I would suspect this 'random' data comes from it's unique ID, something I didn't know about five minutes ago


 No.1867

>>1848

VP9 encoding for webm sends different temporal samples to different processors during encoding. The processor used varies depending on system load, etc. Since different processors may do their work at different times, each has a slightly different view of the previous frames depending on how many other processors have finished their motion search analysis, and that view changes between encodings depending on which processors get done in what order. vpxenc has a –debug switch that forces slow and inefficient serialized analysis for deterministic output, but I have no idea if that switch found its way into ffmpeg's encoder.


 No.1868

Ugh, why dont use already existed webm converters? Image organizer and video converters are two different type of programms. Combine them is a bad idea.

And why on the earth someone wants a lossy-lossy conversion (gif to webm)?


 No.1869

>>1868

>Ugh, why dont use already existed webm converters?

I agree that scopes are good, and feature creep is bad, and Hydrus dev seems to be almost too accommodating with accepting feature requests…

But ffmpeg is an existing converter already included in Hydrus. The functionality is already there, he just needs to add it to the gui.

That being said, yeah, ew lossy-lossy conversions. The requester's intended use case is to share files more easily- perhaps this feature would be better implemented in hydrus' export dialog. Present it like foobar2000 does: Which exe are you using? What arguments are you passing to the exe? Save this for future use?


 No.1870

File: 1453442896778-0.png (25.46 KB, 724x728, 181:182, 2016-01-22 (1).png)

File: 1453442896787-1.png (25.26 KB, 826x777, 118:111, 2016-01-22.png)

>>1869

Pictures of what foobar2000's export/conversion interface looks like. One is a dialog of different profiles, another is the dialog to edit a profile. Hydrus could have something similar under the existing export interface.

>>1848

>we'll just be massively diluting our hashes

I really think conversion on import is a _bad bad bad bad bad bad bad_ idea because of this. Sure, give people the option to convert on export, but if a user wants to ruin the integrity of what goes into their database, they should have to work hard to shoot themselves in the foot like that.

My rationale:

-Converting on export is a per-image, one-off event that you do when the content you want to share is incompatible with the destination.

-Converting on import is, if available, going to be (ab)used for everything. Like I said, if the user really wants to do that, they can do it themselves, don't help them.

>>1856

>webm is made with web content in mind, it's much smaller than gif/mp4 files when done right

Mp4 can be just as small. webm/mp4 are just containers, and containers don't say anything about what is actually inside. While webm is typically pretty locked down, an mp4 can range from lossless video to webm equivalent. Twitter actually uses mp4 instead of webm.


 No.1871

While I'm here, I have two questions:

Why does hydrus_dev not pay attention to github issues as much as this board? Actually it looks like you've just abandoned github's issue tracker. I get that you're catering to anonymous and github requires an account to post…. but bug reports and feature requests are a hell of a lot easier to navigate on github than on here.

Is there any special dependence on the version of ffmpeg packaged with hydrus, or would it be fine to delete hydrus' included ffmpeg if we already have the latest version installed? (installation = on PATH). Package managers can include ffmpeg as a dependency.


 No.1874

Is there anything I can do on my side to speed up file import? IE, having more cpu cores/overclocked cpu/more ram/defragging the drive/etc, or is the main bottleneck just the code?


 No.1875

>>1874

Keeping your drive defragged is generally a good idea anyway.

Besides that, the only other thing I can think of that might improve speeds is to get a faster hard drive.


 No.1883

File: 1453659426165.png (49.05 KB, 670x610, 67:61, treelist.png)

Groups for services(like/ratings)/subscriptions.

This is more of an organization suggestion. I'd like to keep my subs/ratings contained in a group. For example, pixiv subs will belong in the [Pixiv] group. Since it's a list, I figure it'd be easy to make it a tree node.(Pic-related)

It also helps me achieve more narrow ratings, such as if I wanted to do 1~5 ratings based on images from a specific character.(I have global ratings and ratings based on other factors)


 No.1896

system:history

when the system:history tag is entered, it will display the last n files you clicked on.


 No.1975

File: 1454525915502.jpg (674.92 KB, 760x2343, 760:2343, 18a223f969b40f88b122193ae2….jpg)

>>1871

I don't really 'get' github, I don't know why. Maybe it is their emphasis on collaboration, and perhaps diligence, which has never been my thing. I focused on clearing out the github bug reports a little while ago, and that was working fairly well, but then I lapsed back into my normal routine of checking this board and my email and then going straight to work on my existing to-do.

When I am back to normal schedule, I am going to try again, maybe checking one github issue every time I sit down to code. I hate leaving people hanging, and I keep telling myself to sort it out, but I still can't seem to connect the two in this case. I can only apologise for being a sperg, really.

If you delete the ffmpeg executable in the install_dir/bin directory, the client will try to just use 'ffmpeg', so if that is in your path, it should all work.

>>1883

One of my big planned jobs is an overhaul of the subs dialog. I like the idea of grouping by tree, thank you.

>>1896

That's an interesting idea, thank you. I will add it to my to-do list.


 No.1980

I'd like to see there be a "remember this" option in the dialog that appears if you paste multiple tags at once that have tag siblings, so you only have to decide once per tag replacement and allow for an easier workflow when mass pasting tags, please.


 No.1991

Also, while I'm at it, I'd also like the ability to wipe the deleted file hashes from the db to keep that fresh for the "don't reimport deleted files" option. I may or may not have at one point deleted everything and reimported things which left a lot of not quite correct deleted file hashes since I put them back anyways.


 No.2007

I have done an image de-duplicator in the past. you can use this snippet of code if you like: http://paste.pound-python.org/show/Hk4l44hPOVeFZf3XV4v4/

it generates a 64-bit visual similarity hash for an image. calculating it isn't the fastest, but once every image has its hash finding duplicates should be easy enough since you can just use exact equivalence.

as input it expects a PIL Image or a filename. it could probably be sped up a bunch if you don't mind a dependency on numpy.


 No.2035

File: 1455405681233.jpg (1.77 MB, 3585x2810, 717:562, 2f1ab2b1a0122b74cd4ed8d065….jpg)

>>1980

Thank you for this suggestion. I have set it to throw up a yes/no dialog if it detects more than one pending potential sibling choice. If you hit yes, it'll preference siblings in every subsequent choice. Although this works when I test it, I am not sure if it produces a good workflow in the real world, so let me know if it causes you any problems.

>>1991

I have added a button for this to services->review services->local file service. Again, let me know if it doesn't work right.

>>2007

Thank you for this–that's an interesting way of doing it. I currently use a 64-bit DCT-based perceptual hash that describes the general colourless shape of the image. If you are interested, I do it in GeneratePerceptualHash in include/ClientImageHandling.py.

My current challenge is searching hamming distance of two such hashes quickly, but perhaps I am being too complicated. Do you know how well your hashes stand up to similar images, like when one has from 9gag plastered on it? I suppose I could run a hamming search like I do for my current phashes.

Once I am done with IPFS and a new tag suggestion control, I will be working on this. If I can't figure out an easy solution, I would appreciate your further suggestions.


 No.2042

Don't know if this is possible, but is there a way to order the selection tags so that namespaces always appear on top of the list first?

character:a

character:b

creator:a

creator:b

series:a

a

b

c

Another idea is to group tags.

[-][character]

—→character:a

—→character:b

[+][creators]

[+][series]

[-][no namespace]

—→a

—→b

And yet another suggestion is partial tag searching

"character:a* " searches every file that has a character namespace that begins with a.

Of course I understand there's already a huge backlog of ideas, but these are just small things that would benefit me greatly


 No.2046

>>2042

I should probably explain my reasoning too.

-namespaces on top

For the most part I don't look at a files non-namespace tags. The tags I use when finding files are namespaces such as character, creator and series, so it makes sense to have those displayed first. There's also the issue where some files have a shitload of non-namespace tags, and it becomes a pain when I have to dig through them just to find the character. Multiply that by every image

-tag groups

sorry I'm autistic about organization, especially when it comes to organizing millions of files. thats pretty much it

-partial searching

This is just an easier way to mass search without having to manually input every tag.


 No.2047

File: 1455653657791.jpg (284.94 KB, 1280x987, 1280:987, 3b6104ebd9317ce4bdd839f939….jpg)

>>2042

>>2046

Thank you for these suggestions.

Ordering namespaces is something I have also wanted, I just never got round to doing it. It should be fairly easy, as I just need to add an option for it and tweak the sort code. I'll bump it up my list.

Grouping tags is doable but more complicated, as the tag lists are all custom controls I wrote, so I would have to overhaul the internal data representation and external layout stuff to support trees. I will put it on my to-do list and save it for the next time I do a big rewrite of that stuff.

Partial tag searching should work already, much like you suggest. Putting a '*' in the search box should insert that exact search string in the autocomplete list below, and selecting that predicate should return all files that have tags that match the wildcard. For instance, putting in 'star*' should give you all the files matching 'star trek' and 'star wars'.


 No.2164

File: 1456771409965.jpg (17.4 KB, 253x190, 253:190, Clipboard01.jpg)

>>2042

>>2046

I second this, because I have stuff like this

Tag groups is also majorly wanted.

Now, for my own suggestion, I'd want a way to easily identify what file belongs to what url in the detailed file import status window.

Something like a query tree instead of displaying everything in one go.


 No.2196

Instagram support? Is it possible?


 No.2197

Has an API or plugin support ever been considered yet? There seems to be a handful of devs here in the community that would be happy to knock out some small features, atleast until they're officially supported in the main program.


 No.2198

File: 1457204731130.jpg (366.62 KB, 900x987, 300:329, 71bdd7eb6349ec29c40761a70f….jpg)

>>2164

When you say:

>I'd want a way to easily identify what file belongs to what url

Can you explain a bit more what workflow you are looking for? Would something like right-click->open selected in a new search window do what you want? Or are you thinking of something like 'as you move the mouse over the lines in the list, the thumbanil is highlighted' or similar?

>>2196

Almost any website is possible, but I have generally stopped working on new website plugins so I can instead rewrite my downloader engine to support user-created plugins.

>>2197

Yeah, that's my general plan. The next iterations of the downloader engine should support more detailed html/json parsing rules, login FORM and cookie info, and also a migration of all that custom info to external files that anyone will be able to create and import/export.


 No.2226

File: 1457496610470.png (17.29 KB, 638x519, 638:519, mongo sort pornography.PNG)

Regarding tag archives: Would it be possible to create a more streamlined/efficient method of updating a particular tag database, assuming that we as a community can get one or more of them to the point that we have regular updates releasing?

I tested out my tentative e6 DB on a blank DB containing only ~7000 images, and it matched 1800 of those but still took 30-60 minutes to apply the tags from the DB. Removing those tags (so I could apply a new version) was a little faster, but still, it is a not insignificant operation, and I'm leery of how bad it will be on my live Hydrus install (which has probably 30-40,000 matches to this one tagrip, never mind the others I'll be working on).

I ask because this time around, I'm proceeding with the goal of making the spidering, collation, generation, and posting of the rips I'm concerned with as fully automated as possible, so that - for example - if e621 takes ~8 hours to rip in its entirety, and that process requires zero input from me, I can set up a monthly cron job that releases updates automatically, so those of us concerned with e6-sourced tags have the most up to date metadata possible. Other DBs such as Furaffinity may not be feasible to do monthly - but then again, e6 is a booru, so tags on old files can be changed, and therefore since I can't query by mod date the whole site must be rescanned every update, whereas FA is generally past-immutable and thus incremental update tag archives could be released on a shorter schedule.

So, I guess my question is, is it possible for you to code in a streamlined "update tags from archive with new version" operation in, or is that not how the system works?

If that isn't possible, what can I as a tag archive producer do to reduce the length of the update operation for myself and other users? I could theoretically calculate a "diff" - where I release two archives every time there's an update, one with added mappings and one with removed mappings - but since I don't know the rate of mapping changes on a large booru, that might not turn out to save that much time when applying them.

Is there anything else you can think of? Should this sort of thing be a live remote tag service, instead? I'd actually love that, from a user perspective, except that I'm not sure how to make the current Hydrus server interface work on a headless remote Linux server, which is where I do all this shit, and I'm also not sure how that could be made resilient - if I vanish, I don't want the data I've compiled to become unavailable to the community. Tag archives on Mega.nz will always be there, and can be shared around as files, but if I'm running some custom server, that relies on me providing that resource *forever*. I'm not down for that, really.


 No.2227

Also, I've been wondering - what happens with duplicate tags added from multiple tag archives? For example, Furaffinity and e621 are likely to have many of the same tags. You've mentioned before that duplicate tags mess with your UI code - and I've noticed this in places like the Edit Tags window, where a certain tag has a count higher than the number of files being looked at, because a given tag has been applied more than once (manually, by archives, by siblings/parents).

Maybe a "deduplicate tags" maintenance op in the client?


 No.2244

- Rename the window

- As someone who's more comfortable using different databases for different parts of my life, this would be a huge help.

- Pull whitelisted tags from PTR to Local Tags

- There are only certain tags I actually care about when it comes to auto-tagging, so this seems like a good way to only show the tags I want to see. Regexes and Namespaces would be excellent here.

- click-drag selection

- just a qol change. If it's unpopular, maybe have it default to disabled

- a tag option that gives each file tags based on the names of the folders it's in

- easy way to track and tag images after an import


 No.2245

>>2226

Also, did I miss a release note where the client_archives folder got deprecated in favor of the "apply archive" buttons, or am I missing the appropriate area of the UI to configure that now?


 No.2254

Is it at all possible to exclude files of a certain rating? Like "-system:rating for R = 0.5" or something. Or indeed, a ≠ operator.


 No.2256

File: 1457822713832-0.png (207.12 KB, 972x995, 972:995, regex_dir_names.png)

File: 1457822713836-1.jpg (168.81 KB, 1058x1500, 529:750, 03ecc524364e1c9baef29fa769….jpg)

>>2226

That's an interesting thought, and I am not sure the best answer. The more generalised and powerful I make tag archives, the more they look like hydrus services. I am strongly considering moving all tag archive functions to the new extracted service database I am planning. When I pull client.db apart, all service-specific data will be extracted to its own folder. It'll be a portable container for most sorts of hydrus-compatible content, so it'll probably be able to do everything tag archives currently do, and with siblings and stuff as well.

So, in future, I'd like the user to be able to go something like file->import service->pick file/directory/whatever->would you like to import it as a new service, or merge it into an existing service?. Maybe with a single wizard that covers a lot of potential bases, rather than having different functions hidden all over the client.

For your plan for now, it might be reasonable to make three-monthly update archives subsequent to your original 'e621 up to 2015-09' or whatever, and then people can add those smaller (~50MB? something like that?) files a few times a year rather than having to deal with larger ones all the time. Having two archives of 1970-01->2015-09 + 2015-09->2015-12 works the same as 1970-01->2015-12 from hydrus's perspective, it'll just take two db queries. Having your users manage multiple files could be awkward, but it is easy.

The only difficulty there is figuring out what is the new content. If there is a way to grab that from the site (like if you know the guy who runs it, who has direct db access), then that's easy, but I presume you are expecting to have to do a full sync every time you update your tag archive, in which case you can go:

A = Tag archive 2015-09

B = Tag archive 2015-12

C = New tag archive

For every mapping in B:

If it is not in A:

Add it to C.

I am not sure if tag archives currently support membership queries, but if you figure out any new calls you would like, just let me know and I can add them no problem. I can even add a 'create_diff_tag_archive( A, B )' or something. Or you can query them directly, if you are comfortable with the sql.

I can easily add 'merge these two tag archives' code as well, but I don't want to get tied up writing client gui stuff for it when it might just be generalised to the new service db fairly soon anyway.

>>2227

Exactly similar mappings are merged on the same service, so if a tag is 'current' for a file on a tag repo, trying to 'pend' that same tag to the file is a no-op. The duplicate tags issue comes in gui-side, with siblings and when the client has multiple tag services (e.g. 'local tags' has a lot of tags and you have multiple tag repositories synced that have file and tag overlap) but the viewed domain is 'all known tags'. It is just a bit more difficult to quickly and accurately union and count siblings and merged services on-the-fly, so in some places, those counts are inaccurate.

Otherwise, applying multiple tag archives that have very similar content to a single repository isn't a big deal. Anything duplicated will be (quickly) ignored.

>>2245

At the moment, I think you can do two things with tag archives:

1. Permanently sync to them, by putting them in client_archives and then booting the client and going services->manage services->tag service->archive sync.

2. Doing a one-time import via services->review services->tag repo->perform a service-wide operation.

I don't like the workflow for either, really, nor the dichotomy of those two dialogs. The manage/review difference represents what is going on behind the scenes, but not what the user necessarily wants to do. I might end up merging them one day, or removing all commands from review services, or something.

>>2244

- Rename the window

Great idea, thank you. I would use this myself!

- Pull whitelisted tags from PTR to Local Tags

I hope to greatly expand tag display filtering and service-to-service copies and moves once the client.db split-up is done. I hope to pull all service data to separate directories, and I expect it to be easier and simpler to do service operations at this point. When I start work on that, please give me your feedback on the gui I create for it and make sure I include the features you are interested in.

- click-drag selection

This has been on the wishlist a long time (so long that I think I put it there!), and I have just never found time for it. I think it was on the last 'vote on what to work on next' poll, but I cannot remember how well it did.

- a tag option that gives each file tags based on the names of the folders it's in

You can do this now, but it is technical. When you import some files, click 'add tags based on filename', which will let you automatically parse tags from filenames using regexes. These are powerful and can get quite complicated. If you are a programmer, you may be familiar with them and can figure it out yourself, but if you are not, let me or the board in general know, and someone will help you. My attached image shows an example regex that parses simple folder names. It is:

(?<=\\).+?(?=\\)

I am not very good at regexes myself, so there may be better ways of doing it.


 No.2259

>>2256

Your logic re new content is what I was musing about - the problem is removed tags. If there is a mapping in A that is not in B, I have no way, in the HTA, to say "this mapping should be removed if it exists". I suppose I could do an "add these" update db and a "remove these" update db, which could be one-time applied, but I'm not sure that's worth it. I'm especially not sure that running a DB that has 50,000 mappings on 50,000 files into Hydrus is going to be appreciably faster than running one that has 500,000 mappings on 50,000 files (just using numbers pulled out of my ass). Question: Does the permanent sync still take a really really long initial processing time, or does it just sit in the background?

For FA, incremental updates can and will work, though.

I like your services idea - that has potential.


 No.2264

File: 1457896706821.jpg (517.02 KB, 1475x990, 295:198, 441fed36d15b471ae29e77fad8….jpg)

>>2259

Ah, I see. Yeah, tag archives have no deleted knowledge yet. The service db will, so again that's probably the direction we'll head.

Initial sync takes ages, although it no longer locks up the gui. It now runs off a pausable and cancellable popup window that does 50 files at a time or something, so the program runs a little loggier, but is still usable. The total time it will take will be roughly proportional to the number of files that are cross-referenced. If only 5,000 files are matches, it will be about ten times faster than if 50,000 were. (The exception to this is if the tag archive is sha256, in which case 100% of the files are matched, so it'll take ages every time.)

I was heartened to see tag processing generally working faster with the recent autocomplete cache change, so we'll see how that generally holds up as I continue to alter the cache. I expect some further speed-up and also some slow-down, but I am not sure how much they will balance out.


 No.2328

Would it be possible to add a "censor this tag" option to the right-click menu you get in the selection tags menu?




[Return][Go to top][Catalog][Post a Reply]
Delete Post [ ]
[]
[ home / board list / faq / random / create / bans / search / manage / irc ] [ ]