After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 624937 - tif image size increases massively after rotating
tif image size increases massively after rotating
Status: RESOLVED INCOMPLETE
Product: eog
Classification: Core
Component: image viewer
2.30.x
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-07-21 15:36 UTC by Pedro Villavicencio
Modified: 2012-11-16 21:33 UTC
See Also:
GNOME target: ---
GNOME version: 2.29/2.30


Description Pedro Villavicencio 2010-07-21 15:36:28 UTC 
this report has been file here:

https://bugs.launchpad.net/ubuntu/+source/eog/+bug/603901

"tif image size increases massively after rotating

I've attached an image with ~1 kilo byte it turned to 14 Mega byte after rotating"

test image:

http://launchpadlibrarian.net/51666860/Page0001.tif
Comment 1 Felix Riemann 2010-07-21 20:18:39 UTC 
Short explanation: Your input file is a bilevel image using G4 Fax compression while the rotated output will be an RGBA image (don't know why there's the unused alpha channel right now) without any compression.

Longer explanation:
This is mostly caused by GdkPixbuf.
When your bilevel image is loaded by eog using GdkPixbuf its pixel data will be automatically upsampled into the RGB(A) format which is the only format GdkPixbuf can work on (it decides automatically whether there should be an alpha channel). As this is the only data eog can getm the image that is saved to disk will also be using the RGB format which leads (together with the fact that no compression seems to be applied) to the comparatively huge filesize.


I think there's no easy fix on eog's side that wouldn't require replacing large parts of eog's code right now. One could look if a special "TIFF save handler" similar to the one we have for JPEGs could help here, but that would definetly low priority as it would only work around the symptom and not fix the problem.
Comment 2 nodiscc 2012-07-28 14:31:25 UTC 
This bug was reported against a version which is not supported any more. Developers are no longer working on this version so there will not be any bug fixes for it.
Can you please check again if the issue you reported here still happens in a recent version of GNOME and update this report by adding a comment and adjusting the 'Version' field?

Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here.

Without feedback this report will be closed as INCOMPLETE after 6 weeks.
Comment 3 Tobias Mueller 2012-11-16 21:33:23 UTC 
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!