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 
Ook mystery solved !
Having 2 ICCP chunk is effectively out of spec for PNG and It’s an EXIV2 bug.
The bug have been corrected fairly recently in the version 0.27.6 → PNG: always strip the existing iCCP chunk (backport #2254) by kmilos · Pull Request #2256 · Exiv2/exiv2 · GitHub
And I confirm that if I export a PNG today it’s Ok and readable by avis-img, just that I did export mainly jpg in these last 2 weeks so I did not have any new enough well formed PNG to test avis-img with.
Now I guess It’d could be a + if rust png decoder could overlook this kind of imperfection as this bug have been here for quite a while ! (thus the chance of finding files with this malformed header is non negligible I guess).
That said I’m studying the possibility of correcting my files … and I’m quite puzzled by the fact that DT wants to attach my ICCP profile at all (shouldn’t a raw exported with given settings create the same exact file not depending on the system you exported it on ?)
1 Like
This is great news, glad that at least the root problem has been found thank you for your efforts.
Next weekend I’m gonna implement some callback functions to the user actions. Callbacks such as refreshing the opened collection, reloading opened image etc, this could be useful to your situation, for ex: Assign a shortcut that runs the command which fixes the png (as provided in the thread you created about this issue) and then the callback “reload_image” gets executed. One “click” solution Same thing for all the images in the folder.
I know it still requires user action but it’s a faster solution than waiting for the decoder team to make changes to their code.
1 Like
Just a quick bump : after doubt and subsequent comparison with the image displayed by geeqie, I think avis-img does not take into account my display profile …
I’ll update to the latest version and check again later.
I’m using lcms-2.14-r4 on X11 applied via the xfce provided menu …
I really wished these profile stuff could be managed the hardware way 
1 Like
I don’t think update will help, currently I only use the profile imbued in the image itself.
My idea was that when using a display profile with x11, it applies to the whole output going to the monitor?
Either way, I will run some tests too, I currently am using xfce and it’s a good chance to test it out.
Btw, the new version has a few new features, not many but I’m still adding them slowly
Sorry, strange thing is that it seem that avis-img do apply the colour profile (activating and de activating change the appearance) it’s more like geeqie kind of double applying it Oo
I’m really sorry I’ll try to experiment further on my system and maybe fill a bug at geeqie …
avis-img is much closer to darktable and what I see on my phone than geeqie …
1 Like
No worries and no need to apologize, no harm done It’s good to find out about these things, might help other people in the future too
Hello, I gat this error trying to compile the latest version of avis-img
If I understand correctrly this summary of the error explanation, the code makes use of a features only available in nightly builds of rust ?
I have rust version-1.66.1-r1 on my system, (up to 1.69.0 available in unstable package) which version minimum is required for avis-img ?
Compiling avis-imgv v0.1.0 (/home/clind/imageviewer/avis-imgv)
error[E0658]: use of unstable library feature 'main_separator_str'
--> src/navigator.rs:2:27
|
2 | path::{Path, PathBuf, MAIN_SEPARATOR_STR},
| ^^^^^^^^^^^^^^^^^^
|
= note: see issue #94071 <https://github.com/rust-lang/rust/issues/94071> for more information
error[E0658]: use of unstable library feature 'main_separator_str'
--> src/navigator.rs:175:30
|
175 | if !suggestion.ends_with(MAIN_SEPARATOR_STR) {
| ^^^^^^^^^^^^^^^^^^
|
= note: see issue #94071 <https://github.com/rust-lang/rust/issues/94071> for more information
error[E0658]: use of unstable library feature 'main_separator_str'
--> src/navigator.rs:176:23
|
176 | suggestion += MAIN_SEPARATOR_STR;
| ^^^^^^^^^^^^^^^^^^
|
= note: see issue #94071 <https://github.com/rust-lang/rust/issues/94071> for more information
For more information about this error, try `rustc --explain E0658`.
error: could not compile `avis-imgv` due to 3 previous errors
warning: build failed, waiting for other jobs to finish...
Hello, I’m on version rustc 1.68.2 at the moment. Did you install rust through your package manager or rustup? If it was through rustup, rustup update should solve the issue. If not I’ll take a look to make it compatible with earlier versions, I don’t think I use any other new features
1 Like
Through my package manager, I’ll upgrade to unstable, hope there’s no API/ABI changes that’d break anything
PS : ll’s good! Thanks!
1 Like