Hmm, no change either. Could you tell me how I can send a photo to Gimp please?
Yes, of course, I’ll send you a PM so we don’t clutter the thread too much.
Hi, I quick tested your software, it’s rather fast, faster than my usual viewer (geeqie)
The lack of interface in the base configuration is a little bit dis orientating but I’ll have to give a try to the commands and configuration tips you give in the Git page.
Anyway, work here (up to date stable profile gentoo)
1 Like
Hello, thank you for testing it, glad to know it works fine. Unfortunately the configuration won’t be of much help when it comes to interface. Besides user actions, it’s mostly shortcuts and performance adjustments.
I’m working on introducing some buttons and menus, at least for opening files/folder and switching between both kinds of galleries. The main(mostly backend) part for me is mostly done so now it’s time for all the niceties. More to come!
Hello, I played around a bit with your viewer.
I managed to add a context menu “Open with geeqie” and with gThumb and files open fine. Open in Digikam doesn’t work, I suppose because I use an AppImage.
One thing I don’t understand: the config file talks about “gallery” and “multi-gallery”. What’s the difference? When I start the program, the first image shows up full-screen, hitting Esc gives a gallery view with thumbnails. I suppose this is the multi-gallery as it shows me the images_per_row that I set in the config file. When set to 12, the thumbs are being created but very slow. Digikam is much faster here (because it uses a database I guess).
Worse is that once all the thumbs in the folder are created and I stop the program and restart it with the same folder, the thumbs are re-created from scratch. They are not stored in a cache apparently.
That brings me to the performance adjustments: how can this process be accelerated? I tried to adjust the preloaded_rows, simultaneous_load and limit_cached without (seemingly) any improvement. The value for the latter is 1000000, are those bytes?
Regards, Paul.
Yeah, this is one aspect where I’m still considering caching the downsized images. At the moment their resolution varies according to how many are being displayed per row, so I need to see how to best approach this. simultaneous_load is a double edged sword, you can’t select too much if your system can’t handle it or it’ll slow the whole process down. I spawn one thread for each one so try lowering to see if it helps. A good number is core count - 2, or so.
preloaded_rows is how many rows off screen are loaded, so when you scroll it should appear to be faster, this is dependent on user RAM so I didn’t leave that many by default.
Sorry, I should’ve been more clear in the docs about what the cache is. At the moment I only cache image exif data, nothing else.
I think digikam is a different beast because it’s more than an image viewer. I have thought about using this base and building a sort of “digikam light” which stores more information in a database, and then you can search, filter, etc, but it’s not my goal yet.
Ok, thanks, I’ll fiddle around somewhat more with these settings.
Caching the thumbs is certainly a good idea!
And of course, Digikam is quite another beast, don’t try to beat that one! 
1 Like
Hi, I played some more and put the finger on the first few thins that I miss :
quick functions keys to :
- fit to width
- fit to height
- best fit
- display at 1:1 (100%)
Seems silly but a way to navigate like maybe have not just image files but folders as well in grid view ? An adress/path field to enter a new destination, could be masked and accessed via ctrl+l like in browsers ?
Last note : the keypad’s Eter key does not validate a field.
PS : I like the way you made grabbing around the view when zoomed 
1 Like
That’s a good idea. I guess “best fit” is already implemented with the F key, or do you mean also zooming in lower resolution images to fit to screen?
They all make complete sense and I’ll put them on the to-do list.
This makes sense, the ctrl+I address bar is easy to implement, the rest will take a bit longer, could you show me an application with a similar feature so I have a better idea what you mean?
Do you mean the bottom input box to jump to a pic?
Yep, this field or the zoom field where you can input magnification, if I press the “big” enter key it validates my input but nothing happen when I press the numpad enter key.
For the other example I’ll try to make a mock-up soon.
Thanks for your work !
1 Like
Thank you
Gentoo ebuild?
I’ve implemented a simple navigation bar for now. I think it works well enough, has tab auto completion, you can select recommendations based on the paths in the directory and only accepts directories which have images in them.
It’s design is still a bit rough but I think it does the job well enough.
I’ve also implemented a menu which has a button to open folder/files. In the future it can be used for a few more buttons like changing settings visually and other things.
Also improved UI a bit by removing a few ugly separator bars that were rough on the eyes.
Next up I think I’ll look at the “fit” options that @clind recommended
1 Like
nice, I’ll git clone that right away
1 Like
I’m afraid I’ve a bug to report, avis-img failing on a pair of png with error
Format error decoding Png: Chunk ChunkType { type: iCCP, critical: false, private: false, reserved: false, safecopy: false } must appear at most once.
How can I help with the diagnostic ?
I believe that’s an error with the file itself, I have a few like that too. While they open fine on other software, the library I use seems to be more strict when it comes to file correctness so it won’t decode them. Unfortunately there doesn’t seem to be a way for it to be more lax, so for now those files won’t work unless you re-encode them. In a way it’s a good thing that let’s use find bad files 
I did a little more digging and it must be because your png has a duplicate iCCP chunk.
This explains the problem.
If I can send you a file descriptor of some sort …
Those PNG are exported from darktable 4.1 I believe, I’ll try other PNGs
The same goes with pngs exported 2 years ago with different versions of darktable…
I import them in Shotwell photo manager after and have shotwell write metadatas to it (tags and other stuffs) if that can be a lead
Some png exported with gimp are OK the same PNG imported with Shotwell then tagged is ok again
really looks like pngs from DT have something not ok for avis-imgv
1 Like
That’s interesting 
I’m gonna do some tests locally by exporting some images in darktable as png and check if they work. I shall report back afterwards
I implemented a dedicated image resize crate for handling image resizes in the multiple image gallery. In large images this granted an enormous increase in speed on my CPU (300ms → 50ms using CatmullRom). I also changed the downsizing algorithm from CatmullRom to Bilinear as quality isn’t as important in the multiple gallery.
It should fix your slow loading problem @paulmatthijsse without needing a cache taking up space.
Regardless I have some code for handling image caching already and while it works I’m holding it back for now as I would prefer for it to just be quick enough to not need it and to take space.
Whenever I implement raw images I’ll use it for extracted jpegs.