Bumping version number as it is still relevant for 2.9 and I don't want the bug to appear together with bug reported against old versions of Gwenview.

Gonna use this to track just JPEG quality for now; can do more later.

*** Bug 333733 has been marked as a duplicate of this bug. ***

Not only JPEG quality but also chroma subsampling, please.

Ref: https://bugs.kde.org/show_bug.cgi?id=294594#c20

*** Bug 294594 has been marked as a duplicate of this bug. ***

Small note that ideally there could be a default setting accessible in preferences, because if you're doing a regular Save (instead of Save As) then there's no dialog with which to give the user the opportunity to change this value.

Also, my two cents that this is pretty important! The default value of 75% (what I've seen reported elsewhere, can't confirm that's the current value) is low - any enthusiast using Gwenview to make changes is inadvertently mangling their collection a little bit.

Oh jeez, I need to just finally do this...

This seems like a good opportunity for me to try out Bountysource! https://www.bountysource.com/issues/78105774-make-it-possible-to-adjust-jpeg-quality-compression-settings-when-saving

I've submitted a patch to implement this feature: https://phabricator.kde.org/D23106.

Git commit 24cd548e1f7fb85319706134980c5354efb5053d by Nate Graham.
Committed on 24/08/2019 at 17:37.
Pushed by ngraham into branch 'master'.

Allow the user to select the JPEG save/compression quality

Summary:
Currently, anytime Gwenview is used to save a non-JPEG file as a JPEG, or anytime JPEG file is saved or re-saved after performing a lossy edit (e.g. crop or red eye, but not rotation), the new file is saved with 75% quality level, resulting in a noticeable degradation in appearance.

This patch implements a user-selectable JPEG save/compression quality setting, which can be temporarily overridden in the {nav Save As} dialog when saving a file as a JPEG. The new default quality level is 90% -- same as Spectacle. This should prevent people from accdientally destroying their JPEGs.

As before, when saving an existing JPEG file with a new name or after performing a non-lossy edit (e.g. rotation, which only changes the EXIF rotation tag), the appearance of the file is not changed because no actual image manipulation is done.
FIXED-IN: 19.12.0

Test Plan:
{F7205336}

{F7208763}

Set JPEG quality to 5% in the config file and test the following use cases:
- Non-JPEG image: do {nav Save} or {nav Save As} in non-JPEG formats -> No changes or regressions.
- JPEG image: do {nav Save} or {nav Save As} without changing the image format or the image's pixels at all -> No changes; quality level not taken into consideration because these are lossless operations that do not re-compress the image (which is good)
- JPEG image: do {nav Save} or {nav Save As} after changing the image's pixels in some way (e.g. a crop operation) -> Image is saved with the user-specified 5% quality level and looks terrible
- JPEG image: do {nav Save As} into a non-JPEG file format after changing the image image's pixels in some way, or not -> No changes or regressions (in particular, lossless images like PNG are not hugely ballooned in file size)

Set JPEG quality to 90% in the config file and test the following use cases:
- Non-JPEG image: do {nav Save As} in non-JPEG formats -> No changes or regressions; dialog box does not show quality spinbox
- Non-JPEG image: do {nav Save As} into a JPEG and in the {nav Save As] dialog, change the quality from 90% to 5%-> Image is saved with the user-specified 5% quality level and looks terrible
- JPEG image: do {nav Save As} into a non-JPEG file format -> No changes or regressions; dialog box does not show quality spinbox
- JPEG image: do {nav Save As} after changing the image's pixels in some way (e.g. a crop operation), and in the {nav Save As] dialog, change the quality from 90% to 5%-> Image is saved with the user-specified 5% quality level and looks terrible

Reviewers: #gwenview, #vdg

Subscribers: filipf, pino

Tags: #gwenview

Differential Revision: https://phabricator.kde.org/D23106

M  +40   -4    app/generalconfigpage.ui
M  +68   -10   app/gvcore.cpp
M  +5    -0    lib/document/documentloadedimpl.cpp
M  +4    -0    lib/gwenviewconfig.kcfg
M  +1    -0    lib/jpegcontent.cpp

https://commits.kde.org/gwenview/24cd548e1f7fb85319706134980c5354efb5053d

Spectacle 19.08.0 has a different look and feel for that option. Is there a reason why this is implemented in two different ways? It increases inconsistency between KDE apps in my opinion.

What about chroma subsampling?

Can you explain what that is and how it's relevant here?

Sure.

The unfortunate thing about the JPEG "quality" parameter's name is that it makes it sound as if this is all there is to the actual image quality, but that is not the case.

The chroma subsampling parameter lets you control the precision at which color information (as opposed to luma) is recorded. At worst, 3/4 of the color info is discarded. More information here: https://en.wikipedia.org/wiki/Chroma_subsampling

Of all the parameters that JPEG compression involves, both quality and chroma subsampling should be exposed to the user.

When dealing with full-sized real-world photographs, the pixel-level level of chroma detail is generally low - the lens, sensor and post-processing result in blurriness at the 100% zoom level, and it's near impossible to see a difference between an image with no subsampling vs one where the chroma was halved. However, when dealing with screenshots or downscaled real-world photographs, there is usually meaningful information at the pixel level which will be glaringly obvious if it's lost in the JPEG compression process.

Examples to follow.

My original issue 333733 was marked as a duplicate of this one, and then this one was closed without solving the original issue, so I'm re-opening this one.

Created attachment 122370 [details]
PNG test image

The same pattern repeated several times over varying background and angles.

Created attachment 122371 [details]
Chroma subsampling 4:2:0

Quality 90, chroma subsampling 4:2:0 - chroma information was quartered (halved horizontally and vertically).

Created attachment 122372 [details]
Chroma subsampling 4:2:2

Quality 90, chroma subsampling 4:2:2 - chroma information was halved horizontally.

Created attachment 122373 [details]
Chroma subsampling 4:4:4

Quality 90, chroma subsampling 4:4:4 - no chroma subsampling.

Not sure if QImageWriter supports that

https://doc.qt.io/qt-5/qimagewriter.html

We can re-open Bug 333733.

As can be seen in the sample images, using chroma subsampling where pixel-level detail exists leads to glaring differences when comparing to the original. If these were screenshots (which usually have pixel-wide lines such as frames, outlines, text, etc) they would look ugly after compression with any chroma subsampling.

Yo @Nate Graham you should claim your bounty on https://www.bountysource.com/issues/78105774-make-it-possible-to-adjust-jpeg-quality-compression-settings-when-saving

Oh! How nice.