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.
I’m not able to replicate with my setup, using png’s exported from darktable(4.2.1).
Could you show me your export settings please?
Really nothing fancy just plain default basic png export
cat .config/darktable/exp.darktablerc | grep export
plugins/darkroom/0/export_visible=TRUE
plugins/darkroom/export/expanded=FALSE
plugins/darkroom/export/visible=true
plugins/imageio/storage/disk/file_directory=(FILE_FOLDER)/darktable_exported/(FILE_NAME)
plugins/imageio/storage/export/piwigo/server=
plugins/lighttable/1/export_visible=TRUE
plugins/lighttable/export/ask_before_export_overwrite=TRUE
plugins/lighttable/export/dimensions_type=0
plugins/lighttable/export/expanded=TRUE
plugins/lighttable/export/export_masks=FALSE
plugins/lighttable/export/force_lcms2=FALSE
plugins/lighttable/export/format_name=png
plugins/lighttable/export/height=0
plugins/lighttable/export/high_quality_processing=FALSE
plugins/lighttable/export/iccintent=-1
plugins/lighttable/export/iccprofile=
plugins/lighttable/export/icctype=-1
plugins/lighttable/export/metadata_flags=
plugins/lighttable/export/pixel_interpolator=lanczos3
plugins/lighttable/export/pixel_interpolator_warp=bicubic
plugins/lighttable/export/print_dpi=300
plugins/lighttable/export/resizing=max_size
plugins/lighttable/export/resizing_factor=1
plugins/lighttable/export/storage_name=disk
plugins/lighttable/export/style=
plugins/lighttable/export/style_append=FALSE
plugins/lighttable/export/upscale=FALSE
plugins/lighttable/export/width=0
Here is a link (1 month validity) to a png file causing this behaviour :
http://82.64.103.11/online/f.php?h=31H4E0hx
PS : I find the quit key binding ctrl+q very handy, I guess I could configure it somewhere ?
1 Like
Yep, checkout avis-imgv/examples/config.yaml at master · hats-np/avis-imgv · GitHub. You can either add the whole thing or just the settings you want to change. It’s the ‘sc_exit’ setting.
~/Downloads ❯❯❯ pngfix 1.png
zTXt OK maximum 15 15 17659 77193 1.png
zTXt OK maximum 15 15 124 214 1.png
iCCP OK default 15 15 8518 9012 1.png
iCCP OK default 15 15 8518 9012 1.png
iCCP OK default 15 15 8518 9012 1.png
iCCP OK default 14 14 8518 9012 1.png
IDAT OK stdfast 15 15 37846751 72701608 1.png
~/Downloads ❯❯❯ pngfix 2.png
zTXt OK maximum 15 15 1471 6715 2.png
iCCP OK default 15 15 8516 9012 2.png
IDAT OK stdfast 15 15 91361165 104862995 2.png
It seems that your image has the extra ‘iCCP’ tags that cause the issue. My settings are exactly like yours so I wonder what’s the difference. Maybe different versions of libpng that darktable uses?
Unfortunately I can’t do much about it as it’s the png decoder library that’s refusing to decode the image but it’s strange that darktable would imbue more than one profile on export.
For what it’s worth I’m using libpng16.so.16.39.0.
The plot thickens…
I just tested flatpak darktable and indeed it imbues two profiles leading to the issue.
~/P/darktable_exported ❯❯❯ pngfix _DSF1136.png
zTXt OK maximum 15 15 1593 7056 _DSF1136.png
iCCP OK default 15 15 8517 9012 _DSF1136.png
iCCP OK default 14 14 8517 9012 _DSF1136.png
IDAT OK stdfast 15 15 41125329 78154168 _DSF1136.png
~/P/darktable_exported ❯❯❯ pngfix _DSF1136_01.png
zTXt OK maximum 15 15 1595 7056 _DSF1136_01.png
iCCP OK default 15 15 8517 9012 _DSF1136_01.png
IDAT OK stdfast 15 15 132013793 156304168 _DSF1136_01.png
This is the exact same image, both exported by darktable 4.2.1, top is flatpak, bottom is arch repo darktable.
PS: I just reset my configuration by moving ~/.config/darktable and recreated the test, and it still only imbued one profile. So I would say this is not a darktable problem but probably one of the libraries they use as I tested using the same version.
Thanks to have taken the time to look into this so thoroughly !
Just to answer on the first question I run darktable and libpng versions from gentoo’s portage tree that is to say :
- media-libs/libpng-1.6.39 → /usr/lib64/libpng16.so.16.39.0
- media-gfx/darktable-4.2.1
libpng is compiled with 32-bit (x86) libraries support, unofficial APNG (Animated PNG) spec and SSE enabled but without static-lib option.
e2524333d0722cfa622011a3c1041b26 /usr/lib64/libpng16.so.16.39.0 but given it’s compiled on my system with my option I don’t think the md5sum gives much info … but just in case !
What do you think the best course of action is ?
- Fill a bug report on libpng as it is able to produce malformed png ?
- Or is embedding an extra ICCP is a valid PNG header procedure thus the bug should be filled @ libpng again for it being able to produce files it can not handle ?
- Could it be Darktable misusing libpng in some cases ? But if that’s the case I’d be inclined to think the second solution apply.
If I’m understanding this right, according to lsof avis-img and geequie are using the very same libpng to open pngs but avis fail when geeqie does not ?
PS
RUST scores quite high in efficiency , low cpu usage and binary size !!
If I had time to learn a new language it’d be a good competitor
1 Like
I think this one. More than one ICCP is technically valid but libpng throws a warning when decoding it. Other viewers ignore the warning from my understanding.
I’m using a native rust png decoder. It is more picky and doesn’t decode when there are duplicated chunks at all, like I linked above.
I think it would be worth it to try and see why darktable behaves so differently based on our different environments, either by opening an issue or tagging a dev here, I’m not yet sure what to do.
Just as a curiosity, could you share a raw file that produces those 4 chunks? Like the png you sent above.
Yes, it’s a great choice 
I’m really liking it.
I’ll try to open a thread to adderss this issue linking this thread …
Exports from all sorts of raws are producing it as I tested to no avail avis-img on many raws I exported with darktable of all generation and raws from different origin :
- from play raws of this forum
- from the camera I use now (sony a7)
- from my former camera (lumix gh1)
I think that disqualify the raws as the source of the problem
I never imported exported pngs from play raws into my photo manager (so it’s not shotwell messing with the pngs hearders)
OK nailed it !
I managed to find the first colour profile I made for my former display and the filename bare the date of creation !
And guess what ? The pngs exported with darktable BEFORE I applied a colour profile to my system are ok with avis-img, and not after that …
So none of the png I exported since january of 2014 are working in avis-img.
1 Like
Ah, that’s great news! I guess the extra blocks must be holding your display profile then(Still curious why flatpak has a different output in my machine ). I am off for today but will look into this soon enough.
I will post an issue on the library I use to decode the png’s and raise the problem with them since it should still decode it with those blocks there.
Thanks for all the help so far