Bug 357522

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

When you look through you images, you sometimes want to change rotation (e.g. scanned landscape document). This process is very simple with Gwenview: make your changes and press "Save" button. But there is a big problem with images in TIF format.
Black and white (binary) image in TIFF-format with LZW compression has a very small size. This is preferred format for scanning documents, because a disk space is saving tremendously. But Gwenview ignores the compression type of original TIFF-image and save this file type without any compression at all.
Here is mediainfo output: (I've not found <monospace> tag, sorry)
$ mediainfo ./*
General
Complete name                            : ./OriginalWithLZW.tif
Format                                   : TIFF
File size                                : 52.5 KiB

Image
Format                                   : LZW
Width                                    : 3 508 pixels
Height                                   : 4 960 pixels
Color space                              : Y
Bit depth                                : 1 bit
Compression mode                         : Lossless

General
Complete name                            : ./SavedByGwenview.tif
Format                                   : TIFF
File size                                : 2.08 MiB

Image
Format                                   : Raw
Width                                    : 3 508 pixels
Height                                   : 4 960 pixels
Color space                              : Y
Bit depth                                : 1 bit
Compression mode                         : Lossless

Reproducible: Always

Steps to Reproduce:
1. Open a TIFF-file.
2. Save this file as TIFF-image with alternative name (or change something (e.g. rotation) and save the changes).

Actual Results:  
Check the size of new image -- it's huge!!!

Expected Results:  
Ideally files that are being edited should be saved with preserved compression type (and even compression ratio (e.g. for JPEG format)).

Created attachment 119156 [details]
tiff 1 bit

Tiff of 1bit depth. original size 32KiB, rotated and saved 229KiB.
Image from https://github.com/mike-lischke/GraphicEx/blob/master/TestSuite%20original/TIFF/Official%20test%20images/fax2d.tiff
Tested with gwenview 18.12.3

Experiencing the same bug. Working with astrophotography images. Rotated a 16-bit image and I get an 8-bit image! This is highly critical and a disaster I discovered yesterday. Don't even want to think how many images have suffered from it in the past... Also, initial compression is None and it is changed to LZW, disrupting my work flow, as not all of the software I use support LZW compression (and it is just faster to work with uncompressed data).

I haven't done a single commit to Gwenview yet but I tried looking into this. The situation does seem to have improved a bit since Jaime Torres' comment. I rotated attachment 119156 [details] with Gwenview 20.03.70 using Qt 5.13.2 and the size didn't increase by a lot. I opened it, rotated once to the right, saved, loaded the save, rotated once to the left and saved again. Overall the file size changed from 32 KiB to 36.1 KiB and they look identical to me.
I can confirm that a 16 bit image is converted to 8 bit and to using LZW compression even with this version.
Gwenview doesn't do anything special to transform .tiff images. Actually the only image format for which I saw a little specific transformation code was JPEG.
The relevant code that is used to rotate images is here:

void DocumentLoadedImpl::applyTransformation(Orientation orientation)
{
    QImage image = document()->image();
    QTransform matrix = ImageUtils::transformMatrix(orientation);
    image = image.transformed(matrix);
    setDocumentImage(image);
    emit imageRectUpdated(image.rect());
}

It is using the QImage class of Qt to do all the heavy-lifting of rotating all supported image formats. It is probably out of scope for Gwenview or even KDE to implement this kind of conversion logic but having a warning message might be warranted. In any case this seems to be mostly a Qt problem.

Thanks for the investigation, Felix! Do you think you could file a Qt bug report, if there isn't one already?