| Summary: | gwenview shows faded version of image after cropping | ||
|---|---|---|---|
| Product: | [Applications] gwenview | Reporter: | Philip Webb <purslow> |
| Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | asturm, voron1, xnagytibor |
| Priority: | NOR | ||
| Version: | 19.12.3 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/qt/qt/qtbase/commit/a4f9e56975fa6ab4a1f63a9b34a4d77b1cfe4acd | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
uncropped image
cropped image : view with another viewer, eg Feh Gqview cropped image as shown by Gwenview in faded/bleached appearance (screenshot) |
||
Created attachment 127727 [details]
cropped image : view with another viewer, eg Feh Gqview
Created attachment 127728 [details]
cropped image as shown by Gwenview in faded/bleached appearance (screenshot)
This bug is still happening with Gwenview 21.04.3 . It seems to happen after the cropped image is saved in place, ie same name. I am now using Qt 5.15.2 , Frameworks 5.82.0 , Plasma 5.21.5 . My system is still stable Gentoo. My guess this happens due to botched gamma handling. Washed out images are a prime symptom of that kind of bugs. Seems like when a PNG gAMA chunk is present Gwenview applies the gamma transform in the opposite direction it should. Thus the washed out images. Seems to be Qt bug, already fixed in 5.15.x: https://github.com/qt/qtbase/commit/de2c3ccd49cb89e0c6912da3b03705a36ef03946 Thanks for your prompt response. Do you know which version of Qt contains the fix ? -- it doesn't seem to be 5.15.2-r3 (Gentoo), which I am using. 5.15.2-r10 is available in Gentoo testing : I assume I need qt-core (Gentoo). The Github date is June 11, which I assume is 2021, so it may not have reached Gentoo yet (Gentoo stable is fairly prompt, but by no means instant). No idea exactly how/when/where it's gonna reach you, I'm clueless about Qt's and Gentoo's release model. (In reply to Nagy Tibor from comment #6) > Seems to be Qt bug, already fixed in 5.15.x: > https://github.com/qt/qtbase/commit/de2c3ccd49cb89e0c6912da3b03705a36ef03946 The linked commit was not yet cherry-picked to kde/5.15 branch, so it can not be available in Gentoo either. The relevant backports tracker issue is still open/pending: https://invent.kde.org/qt/backports-tracker/-/issues/864 Philip, since you are a Gentoo user, please test the patch to dev-qt/qtgui (https://github.com/qt/qtbase/commit/de2c3ccd49cb89e0c6912da3b03705a36ef03946.patch) by means of the Gentoo user patch mechanism: https://wiki.gentoo.org/wiki//etc/portage/patches A possibly relevant merge request was started @ https://invent.kde.org/qt/qt/qtbase/-/merge_requests/53 (In reply to Andreas Sturmlechner from comment #10) > Philip, since you are a Gentoo user, please test the patch to dev-qt/qtgui > (https://github.com/qt/qtbase/commit/ > de2c3ccd49cb89e0c6912da3b03705a36ef03946.patch) by means of the Gentoo user > patch mechanism: https://wiki.gentoo.org/wiki//etc/portage/patches I tested the patch, it fixes the issue for me. To Michael : thanks for testing this ; hopefully, that wb sufficient. To Andreas : I've looked at the Portage patches procedure & it does look rather complex. Esp, I don't know which Gentoo package is involved : the patch refers to Qtbase, but Gentoo only has Qtcore. While this is clearly a bug which needs fixing in Qt -- the patch shows an elementary omission by the original coder -- , I have found 2 workarounds which avoid the problem in my everyday activity, so its no longer a regular irritant to me. Hopefully, the Qt file wb patched & a new version will arrive at Gentoo soon. (In reply to Philip Webb from comment #13) > To Andreas : I've looked at the Portage patches procedure & it does look > rather complex. Like so: > # mkdir /etc/portage/patches/dev-qt/qtgui > # wget https://github.com/qt/qtbase/commit/de2c3ccd.patch > # mv de2c3ccd.patch /etc/portage/patches/dev-qt/qtgui/ > # emerge -1v qtgui Git commit a4f9e56975fa6ab4a1f63a9b34a4d77b1cfe4acd by Andreas Sturmlechner, on behalf of Allan Sandfeld Jensen. Committed on 23/09/2021 at 08:07. Pushed by apol into branch 'kde/5.15'. Fix reading gamma from PNGs without ICC profile The decoding of PNG_INFO_gAMA to QColorSpace was incorrect, the PNG gamma is the inverse of the gamma value we use. We revert it everywhere else, just not here. Pick-to: 6.2 5.15 Change-Id: Ic0ae1963b2dde3004cac8a6430ddaf99e7096915 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io> (cherry picked from commit de2c3ccd49cb89e0c6912da3b03705a36ef03946) M +2 -2 src/gui/image/qpnghandler.cpp https://invent.kde.org/qt/qt/qtbase/commit/a4f9e56975fa6ab4a1f63a9b34a4d77b1cfe4acd I followed the steps listed in Comment 14 , remerged Gwenview, rebooted. Then I made a PNG screenshot, cropped it, saved it in place (same name). Gwenview shows it in full color. So the patch seems to remove the bug. |
Created attachment 127726 [details] uncropped image SUMMARY : after Gwenview 19.12.3 is used to crop a .png image & the saved result is viewed in Gwenview, the image appears to be faded or bleached. The same image file appears correctly in Feh Gqview Xv. The bad view of the image is not corrected when the machine is rebooted. STEPS TO REPRODUCE 1. Use Gwenview to crop a .png image. 2. View the resulting saved file in Gwenview after going to another folder. 3. OBSERVED RESULT : the image appears to be faded or bleached EXPECTED RESULT : the image should show in full color, as it does in Feh. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.17.5 (these are the latest stable versions in Gentoo) (available in About System) KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.67.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION : Many previous croppings haven't shown this bug, which seems to have started after upgrading to 19.12.3 on 21 March 2020.