Mailing List Archive

On Thursday, 9 September 2021 00:25:41 BST Philip Webb wrote:
> I have cropped some .png images using Gwenview
> & the reduced versions are faded with Gwenview, but fully colored with Feh.
> I've tried using 'convert' to create .jpg versions,
> but while they're much smaller in Kbytes (good),
> they're also faded when viewed with Gwenview (Feh ok).
>
> Can anyone explain what has caused this ?
> Is there a way of correcting it, eg with Imagemagick ?

Once you have converted an original raster image into a smaller (i.e. more
compressed) jpeg image you have thrown away some pixels. Post-processing
can't put these missing pixels back.

I think the gwenview faded display phenomenon you describe here is unlikely to
be the result of your conversion, since feh displays it without any fading.
It may be caused by gwenview scaling the image to a different size, to make it
fit in the gwenview window, unlike feh which will open it in its original size
whether its full size dimensions fit in your PC monitor or not. You can check
the gwenview % reduction/increase shown at the bottom right hand corner and
change this to 100% to see if it makes any odds.

In the gwenview settings you can select what the default 'Zoom Mode' is, if
indeed this is the cause of the faded image display.

Another thing perhaps related could be the anti-aliasing gwenview applies to
fit the image in the window aperture and how this interacts with the image
elements and the resolution of your monitor - you should be able to check this
if you change the zoom level.

https://photo.stackexchange.com/questions/24512/what-is-aliasing-and-anti-aliasing

On the same PC/monitor with the same display dimensions for an image gwenview
(with its default settings) and feh ought to produce the same output - at
least they do so here.

On Thursday, 9 September 2021 14:00:50 BST Michael wrote:
> On Thursday, 9 September 2021 00:25:41 BST Philip Webb wrote:
> > I have cropped some .png images using Gwenview
> > & the reduced versions are faded with Gwenview, but fully colored with
> > Feh.
> > I've tried using 'convert' to create .jpg versions,
> > but while they're much smaller in Kbytes (good),
> > they're also faded when viewed with Gwenview (Feh ok).
> >
> > Can anyone explain what has caused this ?
> > Is there a way of correcting it, eg with Imagemagick ?
>
> Once you have converted an original raster image into a smaller (i.e. more
> compressed) jpeg image you have thrown away some pixels. Post-processing
> can't put these missing pixels back.
>
> I think the gwenview faded display phenomenon you describe here is unlikely
> to be the result of your conversion, since feh displays it without any
> fading. It may be caused by gwenview scaling the image to a different size,
> to make it fit in the gwenview window, unlike feh which will open it in its
> original size whether its full size dimensions fit in your PC monitor or
> not. You can check the gwenview % reduction/increase shown at the bottom
> right hand corner and change this to 100% to see if it makes any odds.
>
> In the gwenview settings you can select what the default 'Zoom Mode' is, if
> indeed this is the cause of the faded image display.
>
> Another thing perhaps related could be the anti-aliasing gwenview applies to
> fit the image in the window aperture and how this interacts with the image
> elements and the resolution of your monitor - you should be able to check
> this if you change the zoom level.
>
> https://photo.stackexchange.com/questions/24512/what-is-aliasing-and-anti-al
> iasing
>
> On the same PC/monitor with the same display dimensions for an image
> gwenview (with its default settings) and feh ought to produce the same
> output - at least they do so here.

I may have misread your OP - apologies:

"... but fully *colored* with Feh."

This is probably related to the colour gamut settings of gwenview. In the
gwenview settings, on the Advanced tab, there are settings for "Rendering
intent" and "Colour profile". Change these and see if it makes a difference.

210909 Michael wrote:
> On Thursday, 9 September 2021 00:25:41 BST Philip Webb wrote:
>> I have cropped some .png images using Gwenview & the reduced versions
>> are faded with Gwenview, but fully colored with Feh.
>> I've tried using 'convert' to create .jpg versions,
>> but while they're much smaller in Kbytes (good),
>> they're also faded when viewed with Gwenview (Feh ok).
> I think the gwenview faded display phenomenon you describe here
> is unlikely to be the result of your conversion,
> since feh displays it without any fading.
> It may be caused by gwenview scaling the image to a different size,
> to make it fit in the gwenview window,
> unlike feh, which will open it in its original size
> whether its full size dimensions fit in your PC monitor or not.
> You can check the gwenview % reduction/increase shown at the bottom
> right hand corner and change this to 100% to see if it makes any odds.

Gwenview says it's showing it at 100 % .
Both viewers show it at the same size on my monitor.

> In the gwenview settings you can select what the default 'Zoom Mode' is,
> if indeed this is the cause of the faded image display.
> Another thing perhaps related could be the anti-aliasing gwenview applies
> to fit the image in the window aperture and how this interacts
> with the image elements and the resolution of your monitor
> - you should be able to check this if you change the zoom level.
> https://photo.stackexchange.com/questions/24512/what-is-aliasing-and-anti-aliasing

The problem doesn't seem to have anything to do with aliasing,
which corrects jagged lines etc.

> On the same PC/monitor with the same display dimensions for an image
> gwenview (with its default settings) and feh
> ought to produce the same output - at least they do so here.
> "... but fully *colored* with Feh" :
> this is probably related to the colour gamut settings of gwenview.
> In the gwenview settings, on the Advanced tab,
> there are settings for "Rendering intent" and "Colour profile".
> Change these and see if it makes a difference.

I've tried changing all the various settings in Gwenview config separately,
but nothing changes.

NB this happens only with images which I've cropped using Gwenview,
ie simply removed some outer parts of a larger original.
In itself, that shouldn't change the colors in the new version.

I have made screenshots of the different images via Imagemagick,
which each show the same image in both Gwenview + Feh
-- ie Gwenview shows the Feh test as vivid & Feh shows the other as faded --
& display how the former is faded, while the latter is vivid.
I'll attach them to a separate e-mail to your address off the list.

It remains a puzzle. Any further comments from anyone are most welcome.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Hello,

On Sun, 12 Sep 2021, Philip Webb wrote:
>It remains a puzzle. Any further comments from anyone are most welcome.

Gwenview uses color-management via media-libs/lcms, feh does not.
See "Rendering intent" and "Color profile" under "Advanced" in
Gwenview's configure dialog.

HTH,
-dnh

--
Hey, what do you expect from a culture that
*drives* on *parkways* and *parks* on *driveways*?
--Gallagher

On Sun, 12 Sep 2021 23:14:11 -0400, Philip Webb wrote:

> I've tried changing all the various settings in Gwenview config
> separately, but nothing changes.

Have you tried logging is as a new user with default Gwenview config?


--
Neil Bothwick

For security reasons, all text in this mail
is double-rot13 encrypted.

210913 Neil Bothwick wrote:
> On Sun, 12 Sep 2021 23:14:11 -0400, Philip Webb wrote:
>> I've tried changing all the various settings in Gwenview config
>> separately, but nothing changes.
> Have you tried logging is as a new user with default Gwenview config?

No : why would that be expected to help ?

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

On Mon, 13 Sep 2021 03:57:55 -0400, Philip Webb wrote:

> >> I've tried changing all the various settings in Gwenview config
> >> separately, but nothing changes.
> > Have you tried logging is as a new user with default Gwenview config?
> >
>
> No : why would that be expected to help ?

Because it would revert to a default config, instead of trying changes
one at a time to see if anything makes a difference. If it doesn't happen
with a new user, you know it is a configuration issue.


--
Neil Bothwick

"When you play a Microsoft CD backwards you can hear demonic Voices...
that's nothing - when you play it forward it installs Windows"

On 2021-09-13, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Mon, 13 Sep 2021 03:57:55 -0400, Philip Webb wrote:
>
>> >> I've tried changing all the various settings in Gwenview config
>> >> separately, but nothing changes.
>> >
>> > Have you tried logging is as a new user with default Gwenview
>> > config?
>>
>> No : why would that be expected to help ?
>
> Because it would revert to a default config, instead of trying
> changes one at a time to see if anything makes a difference. If it
> doesn't happen with a new user, you know it is a configuration
> issue.

Or a caching issue. Some libraries cache stuff in a per-user cache
(often in ~/.cache). There's one Qt application upon which I rely
where the UI occassionally stops rendering. It worked fine if you
logged in as a new user, but wiping your config, logout, reboot, etc
and allowing it to default didn't help. I actually switched over
completely to a new use account once to avoid the problem. Later, I
figured out all I had to do was "rm -rf ~/.cache/<something>".

210913 David Haller wrote:
> Gwenview uses color-management via media-libs/lcms, feh does not.
> See "Rendering intent" and "Color profile" under "Advanced"
> in Gwenview's configure dialog. HTH.

That cb relevant, but I've explored further & have some results.

When I crop a JPG image with Fotoxx or Gwenview,
then view it with Gwenview, the colors remain vivid ;
this is true whether I rename the new version in Gwenview or not.

It's only when I crop a PNG image in Gwenview
& save it in place (ie with the same name), that the colors are faded
& that's only when viewed with Gwenview, not eg with Feh.

So I can avoid the problem either by cropping only with Fotoxx
or by renaming them whenever I do it with Gwenview
or by converting PNGs to JPGs before cropping them.

The bad case does look like a Gwenview bug,
but KDE bugs tend to disappear into the ocean, if reported.

Thanks for the comments. I will try redoing the faded versions,
tho' that will mean getting them from the I/net again.
Any further suggestions re causes of the bad case are welcome.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

On Tue, 14 Sep 2021 01:07:42 -0400, Philip Webb wrote:

> > Gwenview uses color-management via media-libs/lcms, feh does not.
> > See "Rendering intent" and "Color profile" under "Advanced"
> > in Gwenview's configure dialog. HTH.
>
> That cb relevant, but I've explored further & have some results.
>
> When I crop a JPG image with Fotoxx or Gwenview,
> then view it with Gwenview, the colors remain vivid ;
> this is true whether I rename the new version in Gwenview or not.
>
> It's only when I crop a PNG image in Gwenview
> & save it in place (ie with the same name), that the colors are faded
> & that's only when viewed with Gwenview, not eg with Feh.
>
> So I can avoid the problem either by cropping only with Fotoxx
> or by renaming them whenever I do it with Gwenview
> or by converting PNGs to JPGs before cropping them.

The latter will result in loss of information.

> The bad case does look like a Gwenview bug,
> but KDE bugs tend to disappear into the ocean, if reported.
>
> Thanks for the comments. I will try redoing the faded versions,
> tho' that will mean getting them from the I/net again.
> Any further suggestions re causes of the bad case are welcome.

It sounds like the images are fine, just that Gwenview is displaying with
the wrong colour information. The question then becomes, does Gwenview
save the colour information in the image file or separately. If you do
have another user set up, you could try cropping and saving as one user
and viewing as the other. If the second user sees the image as it should
be, it is the latter and you can locate and remove that information.

It does seems to be a bug, and one that has been around for some years:

https://forum.kde.org/viewtopic.php?f=66&t=139430


--
Neil Bothwick

And then Adam said, "What's a headache?

210914 Neil Bothwick wrote:
> On Tue, 14 Sep 2021 01:07:42 -0400, Philip Webb wrote:
>> So I can avoid the problem either by cropping only with Fotoxx
>> or by renaming them whenever I do it with Gwenview
>> or by converting PNGs to JPGs before cropping them.
> The latter will result in loss of information.

Ok if the info is irrelevant or otiose.

>> The bad case does look like a Gwenview bug,
>> but KDE bugs tend to disappear into the ocean, if reported.
> It sounds like the images are fine, just that Gwenview is displaying
> with the wrong colour information. The question then becomes
> does Gwenview save the colour information in the image file or separately.
> If you do have another user set up,
> you could try cropping and saving as one user and viewing as the other.
> If the second user sees the image as it should be,
> it is the latter and you can locate and remove that information.

That's all very complex & far more work than I care to spend time on.
I believe I've found a solution as above.

> It does seems to be a bug, and one that has been around for some years:
> https://forum.kde.org/viewtopic.php?f=66&t=139430

Yet another eg of KDE's cavalier approach to bugs.

Thanks for the insights.

> And then Adam said, "What's a headache ? "

He should have said : "What's an apple ? "

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

On Tue, 14 Sep 2021 05:17:21 -0400, Philip Webb wrote:

> > It sounds like the images are fine, just that Gwenview is displaying
> > with the wrong colour information. The question then becomes
> > does Gwenview save the colour information in the image file or
> > separately. If you do have another user set up,
> > you could try cropping and saving as one user and viewing as the
> > other. If the second user sees the image as it should be,
> > it is the latter and you can locate and remove that information.
>
> That's all very complex & far more work than I care to spend time on.

Hardly, it takes seconds to create a new user, which is a one off task.
Then you always have a quick way of testing things with the default
config.

> I believe I've found a solution as above.

I'd say you have found a workaround rather than a solution, but if it
works for you...


--
Neil Bothwick

Modulation in all things.

On Tue, 14 Sep 2021 19:18:51 +0100, Neil Bothwick wrote:

> > I believe I've found a solution as above.
>
> I'd say you have found a workaround rather than a solution, but if it
> works for you...

I've just tried installing Gwenview, I normally use Geeqie. I cropped and
saved a PNG, then exited and restarted Gwenview and the image looked
fine. However, another PNG that I hadn't touched with Gwenview displayed
in faded colours just as you described.


--
Neil Bothwick

If you think talk is cheap, try hiring a lawyer.

210914 Philip Webb wrote:
> 210913 David Haller wrote:
>> Gwenview uses color-management via media-libs/lcms, feh does not.
>> See "Rendering intent" and "Color profile" under "Advanced"
>> in Gwenview's configure dialog. HTH.
> That cb relevant, but I've explored further & have some results.
>
> When I crop a JPG image with Fotoxx or Gwenview,
> then view it with Gwenview, the colors remain vivid ;
> this is true whether I rename the new version in Gwenview or not.
>
> It's only when I crop a PNG image in Gwenview
> & save it in place (ie with the same name), that the colors are faded
> & that's only when viewed with Gwenview, not eg with Feh.
>
> So I can avoid the problem either by cropping only with Fotoxx
> or by renaming them whenever I do it with Gwenview
> or by converting PNGs to JPGs before cropping them.

I have reconfirmed this.

> The bad case does look like a Gwenview bug,
> but KDE bugs tend to disappear into the ocean, if reported.

In fact, as I had forgotten (grimace), I did submit a bug previously :
KDE Bug 420357 back in April 2020, to which no-one has yet responded.
I've added a comment & we'll see if there's any response this time.

> Thanks for the comments. I will try redoing the faded versions,
> tho' that will mean getting them from the I/net again.

I managed to do that & now have images which cb seen via Gwenview.

> Any further suggestions re causes of the bad case are welcome.

They still are, but it does seem to be a bug.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

210917 Philip Webb wrote:
> It's only when I crop a PNG image in Gwenview
> & save it in place (ie with the same name), that the colors are faded
> & that's only when viewed with Gwenview, not eg with Feh.
> The bad case does look like a Gwenview bug,
> & in fact, as I had forgotten (grimace), I did submit a bug previously :
> KDE Bug 420357 back in April 2020, to which no-one has yet responded.
> I've added a comment & we'll see if there's any response this time.

Tibor Nagy of KDE Bugzilla has replied very promptly :

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

As you can see from the link above, some coder forgot to invert a value,
using 'gamma' when it sb '1/gamma'.

The patch is dated 'June 11', so it make take awhile yet to reach Gentoo.

Meanwhile, I have 2 workarounds which are in fact improvements for me.
I have amended the Imagemagick 'import' command I use for screenshots
to produce them as JPGs, which cb safely cropped already via Gwenview.
Alternatively, Firefox will make screenshots via R-click on its window
& the area to be grabbed cb marked on the screen, so already cropped.

From the beginning, I thought it was a programming bug,
as it appeared suddenly after a KDE update in spring 2020.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

On Sun, 19 Sep 2021 00:01:51 -0400, Philip Webb wrote:

> Tibor Nagy of KDE Bugzilla has replied very promptly :
>
> 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
>
> As you can see from the link above, some coder forgot to invert a value,
> using 'gamma' when it sb '1/gamma'.
>
> The patch is dated 'June 11', so it make take awhile yet to reach
> Gentoo.

5.15.2 is already in testing, which explains why I was unable to
reproduce this in the way it hit you, but there was still one washed out
image I saw.


--
Neil Bothwick

667 - The FAX number of the beast

210919 Neil Bothwick wrote:
> On Sun, 19 Sep 2021 00:01:51 -0400, Philip Webb wrote:
>> The patch is dated 'June 11', so it may take awhile yet to reach Gentoo.
> 5.15.2 is already in testing, which explains why I was unable
> to reproduce this in the way it hit you,
> but there was still one washed out image I saw.

I'm using Qt 5.15.2-r3 , which is stable, but -r10 is still testing.
Probably, the correct version wb part of 5.15.3 or 5.16.1 or similar.

Meanwhile, the advice has to be don't manipulate PNGs using Gwenview :
convert them to JPG first.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Am Sun, Sep 19, 2021 at 05:37:20AM -0400 schrieb Philip Webb:

> Meanwhile, the advice has to be don't manipulate PNGs using Gwenview :
> convert them to JPG first.

Rather, manipulate them with something other than gwenview, which is always
better than to use JPG due to compression artifacts (even on very high
quality settings).

--
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

People who are not convex with foreign words should not renovate with them.