[ / / / / / / / / / / / / / ] [ dir / random / 93 / biohzrd / hkacade / hkpnd / tct / utd / uy / yebalnia ]

/hydrus/ - Hydrus Network

Bug reports, feature requests, and other discussion for the hydrus network.
Name
Email
Subject
REC
STOP
Comment *
File
Password (Randomized for file and post deletion; you may also set your own.)
Archive
* = required field[▶Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Options

Allowed file types:jpg, jpeg, gif, png, webp,webm, mp4, mov, swf, pdf
Max filesize is16 MB.
Max image dimensions are15000 x15000.
You may upload5 per post.


This board will be deleted next Wednesday. I am moving to a General on 8chan.moe /t/. This board is archived at 8chan.moe /hydrus/!

YouTube embed. Click thumbnail to play.

768770 No.12507

windows

zip: https://github.com/hydrusnetwork/hydrus/releases/download/v351/Hydrus.Network.351.-.Windows.-.Extract.only.zip

exe: https://github.com/hydrusnetwork/hydrus/releases/download/v351/Hydrus.Network.351.-.Windows.-.Installer.exe

os x

app: https://github.com/hydrusnetwork/hydrus/releases/download/v351/Hydrus.Network.351.-.OS.X.-.App.dmg

linux

tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v351/Hydrus.Network.351.-.Linux.-.Executable.tar.gz

source

tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v351.tar.gz

I had an ok week. I sped up several systems and added a new processing panel to the duplicate filter.

The 'next big job' poll is finished! I will next be focusing on overhauling the duplicate filter's db structure (including sketching out support for file 'alternates') and further improving the ui-side workflow.

duplicate filter

Seeing that the duplicate filter work was popular in the poll, I was happy to put a bit more time into it this week.

Most importantly, the duplicate filter now has a new always-on-top panel to make reviewing differences and making decisions easier. Essentially, I have pulled the 'this has higher resolution' statements and the action buttons out of the top hover window and put them in their own box to the middle-right. It stays on top, so you can always see it, and I have expanded the different statements to explicitly state each file's relevant values, such as '550KB >> 141KB', and to colour their text green/blue/red based on that difference. You can now make at-a-glance decisions for easy pairs. Let me know how it works for you!

I also have tweaked the 'show some random dupes' and 'duplicate filter' database routines to sample results more cautiously, meaning that duplicate filters with very large search domains (like system:inbox or system:num_tags>0) will work significantly faster. The initial search step still has to run every time, but the second 'sampling' stage takes barely any time at all. If your dupe work still takes a long time to count up or load pairs to filter, I'll recommend again to just add a 'creator:' tag.

The next 'big job' work here is to overhaul the duplicate database tables to work in more intelligent 'groups' rather than my initial simple 'pairs' system. This will compact the duplicates data, speed up many operations, massively simplify transitive duplicate logic, and lead to alternate file structure support. I'll also probably copy the basic structure to tag siblings and parents, which are a similar data structure also currently stored in pairs. This job will take some work, but I know the general thrust of what I want to do.

faster code and some misc work

I cleaned and improved a bunch of old code this week. First off, image loading now uniformly uses a faster library, so image imports and some thumbnail creation should be a little bit faster and deal with some rare image rotations more reliably. Secondly, the way the tag siblings and parents managers construct themselves on client boot is significantly faster. And a new 'local' tag cache–which will take a minute to construct when you update the client–will speed up many tag-related operations, particularly file results building, especially right after the client boots. There are many changes here, so please report any bugs you see.

review services now uses nested notebooks instead of my old 'listbook' control. I don't really like how it looks now, but the code behind the scenes is a lot saner. The last instance of this bad listbook is the options dialog, which is even worse behind the scenes but a bit too big to fit into a single notebook–I am still thinking about what to do with it.

It is just a little thing, but subscription popups now list file download progress x/y in terms of the current job rather than total subscription history! So, if your sub has 400 files already downloaded and finds 10 more in a sync, the popup will now say (and display a progress gauge for) a much more helpful 3/10 rather than 403/10.

full list

- wrote a new (always on top!) hover window for the duplicate filter that sits on the middle-right. the duplicate cog button and action buttons are moved to this new window, as are the file comparison statements

- the duplicate file comparison statements now state the relevant actual metadata along with better '>>'-style operators to highlight differences and green/red/blue colouring based on given score. it is now much easier to see and action clearly better files at-a-glance

- improved some hover window focus display calculations to play with the new always-on-top tech

- both the 'show some random dupes' button and finding dupe pairs for the filter should be a bit faster for very large search domains. the basic file search and indexing still has to run, but the second sampling step in both cases will bail out earlier once it has a decent result

- core image handling functions now uniformly use OpenCV (faster, more accurate) by default, falling to PIL/Pillow on errors. image importing in the client and server should be a bit faster, and some unusual image rotations should now be read correctly

- the server now supports OpenCV for image operations, it _should_ also still work with only PIL/Pillow, if you are running from source and cannot get it

- unified all thumbnail generation code and insulated it from suprises due to unexpectedly-sized source files, fixing a potential client-level thumbnail generation looping bug

- gave all image processing a refactor and general cleanup pass, deleted a bunch of old code

- wrote a new 'local tag cache' for the db that will speed up tag definition lookups for all local files. this should speed up a variety of tag and file result fetching, particularly right after client boot. it will take a minute or two on update to generate

- sped up how fast the tag parent structure builds itself

- the review services panel now uses nested notebooks, rather than the old badly coded listbook control. I don't really like how it looks, but the code is now saner

- similar-files metadata generation now discards blank frames more reliably

- subscription popups now report x/y progress in terms of the current job, discarding historical work previously done. 1001/1003 is gone, 1/3 is in

- made the disk cache more conservative on non-pre-processing calls

- cleaned up some file import code, moving responsibility from the file locations manager to the file import object

- updated the ipfs service listctrl to use the new listctrl object. also cleaned up its action code to be more async and stable

- I believe I fixed a rare vector for the 'tryendmodal' dialog bug

- fixed a bug in presenting the available importable downloader objects in the easy drag-and-drop downloader import when the multiple downloaders dropped included objects of the same type and name–duplicate-named objects in this case will now be discarded

- unified url_match/url_class code differences to url class everywhere

- updated some common db list selection code to use new python string formatting

- plenty of misc code cleanup

next week

I'll now tackle this dupe db work. I'll plan and experiment first. Otherwise, next week is a small jobs week. I'd like to add .ico support and add pages' 'collect by' dropdown value to sessions so it gets saved.

____________________________
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

01e129 No.12508

File: f3a3fcf31d47dea⋯.png (6.93 KB,202x256,101:128,2019-05-08_17-27-54.png)

>>12507

Initial thoughts on the dup change

Its both good and bad.

now, first things first, can you limit it to a specific size?

Looking at the dup finder right now, everything scales with how big the window is and its hitbox changes too. this bugged me for a while, but till this one came in its been a relative non issue. but now that this is a thing, its become an issue.

Is it possible to set both to only be as big as they need to be?

If thats not possible, could you define the always on top box to be about 200x250? it has no real reason to be bigger then that, however it currently decides to be 385x250 and of I go full screen 760x250

also, could a user positional setting be possible? where its sitting right dead center gets in the way of images that are tall as well as images that are wide, a good amount of issue with it comes from this, would it be possible to have it instead go to the lower right corner? this would make it a relitive non issue even when it covers shit up

another thing, could there be some kind of hide button to hide it when pressed? I know this is a 1:1000 need, but no matter where it is so long as its always on top, it could potentially cover something you need to see.

as it stands, I like it and see it being very useful going forward with dup filtering given that it has both file sizes and both resolutions shown and is a quick view for better worse, but it could use some work.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

18f24c No.12510

>>12507

>t stays on top, so you can always see it, and I have expanded the different statements to explicitly state each file's relevant values, such as '550KB >> 141KB', and to colour their text green/blue/red based on that difference. You can now make at-a-glance decisions for easy pairs. Let me know how it works for you!

I like the enhanced visibility of the size / tag count information. Colors are nice.

Maybe the buttons should also have hotkeys indicated on them, it's the kind of workflow where you might want to work keyboard-only, but on infrequent use you'll not necessarily remember.

Beyond that, I'm still trying it out.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

c6529a No.12517

What a day to check back in on Hydrus! Upgrading from my dinosaur version to current for this.

Sight unseen I'd like to echo the request for hotkey labels, and also ask if it's not already implemented for customizable hotkeys. I'd love to be able to sort using num keys.

Thanks for the code as always.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

c6529a No.12518

>>12517

>R6034

>An application has attempted to load the C runtime library incorrectly

reeeeeeeeeeeee

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

0adcac No.12519

Thank you based dev.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

01e129 No.12520

File: 3e66816444671ea⋯.png (14.17 KB,1001x330,91:30,2019-05-09_13-59-20.png)

>>12507

Ok, making further progress in culling the massive fuck off files,

I ran into some sorting issues.

note, sort by height, sort by width, sort by pixels, ratio

each one of these is a like

note bitrate and duration, another like

would it be possible to get things lumped together better? I get that these are alphabetical, but would it be possible to have a further sort above that to at least sort file properties vs database lookups? also, could it be possible to add in a whitelist/blacklist for sort methods? it may not be 100% obvious, but personally, I use ratings as tags as they are currently easier to do apposed to the more traditional tags, these ratings generally there to exclude files, this is great in a search, but not so great in a general sort.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

b6f71e No.12522

>>12517

>>12518

>jumping >5 releases

>skipping over the important updates

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

3bc99a No.12525

File: 52afcc03f8ea667⋯.jpg (367.07 KB,873x1138,873:1138,52afcc03f8ea667610ec019144….jpg)

Suddenly the media viewer's pop-up windows pop up *above* the manage tags window! Huge problem! I can't click the tabs because the damn tag list pops up over them. Half the window is unclickable. Can't even move the window because stuff pops up above the title bar. Unusable. This didn't happen last version.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

768770 No.12551

>>12508

The hover window positioning system is slightly hellworld atm. I built it to scale to the main media window, so I hacked in the new always-on-top one to do the same. You may have noticed it sometimes flicker-refits itself on new media pair updates. I don't like it and will keep working on it. I'd like it to be repositionable as well–one user suggested putting it on their other monitor, which I like. I'll keep this in mind as I work here over the coming weeks.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

768770 No.12552

>>12510

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

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

768770 No.12553

>>12517

>>12518

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

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

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

768770 No.12554

>>12520

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

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

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

768770 No.12555

>>12525

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

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

01e129 No.12564

>>12554

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

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

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

this would at least clearly separate the two.

>>12551

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

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

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.



[Return][Go to top][Catalog][Nerve Center][Random][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / random / 93 / biohzrd / hkacade / hkpnd / tct / utd / uy / yebalnia ]