I have scanned a roll of 35mm mono negatives as 16-bit grayscale TIFFS, then used gwenview to correct orientation and discard bad frames before final fixing up in krita. When saving changes, Gwenview silently overwrites 16-bit greyscale with 24-bit sRGB. Since the curves were not yet set, this represents a conisiderable data loss and I am now rescanning all the negatives. Gwenview should at least ask permission before reducing bit depth in a saved file; it should not silently discard data.
*** 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?