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 434194 - enforce minimum libtiff version
enforce minimum libtiff version
Status: RESOLVED DUPLICATE of bug 428725
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-04-28 19:36 UTC by Michael Chudobiak
Modified: 2010-07-10 04:05 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description Michael Chudobiak 2007-04-28 19:36:22 UTC
Hi,

it would be nice if we could set the minimum required version for libtiff (if libtiff is present) to 3.6.1 or higher.

This would allow us to simplify io-tiff.c a bit. Some sections of the tiff loader are obscure; this would help clarify things.

- Mike
Comment 1 Matthias Clasen 2007-04-28 19:48:02 UTC
I have no problem with doing so; just include the necessary configure.in change
in your io-tiff.c simplification patch.
Comment 2 Michael Chudobiak 2007-04-28 21:03:46 UTC
I have io-tiff.c and io-jpeg.c patches coming (part of bug 428725) but I'm still shaky with makefile checks. Could you show me the correct way to insert a libtiff library check for TIFFReadRGBAImageOriented? The existing libtiff checks are quite nested; I'm reasonably sure I'll break them...

- Mike
Comment 3 Matthias Clasen 2007-04-28 21:57:16 UTC
I can do that, sure. Though there is a good chance that I'll break them too...
Comment 4 Matthias Clasen 2007-04-30 17:10:21 UTC
The easiest thing to do would probably be to just replace TIFFReadScanline
by  TIFFReadRGBAImageIOriented in the first AC_CHECK_LIB test
Comment 5 Michael Chudobiak 2007-04-30 17:12:22 UTC
Thanks, I should have thought of that...

- Mike
Comment 6 Matthias Clasen 2007-04-30 18:01:00 UTC
Quick note: the upped requirement should be mentioned in README.in
Comment 7 Michael Chudobiak 2007-04-30 18:22:54 UTC
Matthias,

Thanks, I'll remember to do that.

While I have your attention, I'd like to ask you about what to do API-wise for the pixbuf loaders and embedded orientation tags. The jpeg loader currently ignores all embedded exif orientation tags, but the tiff loader obeys them if they do not require a rotation (i.e., flips/mirrors are OK, but anything that swaps height/width is done incorrectly).

Bug 428725 is about reading in the tags and associating them with the pixbuf option hash so that client apps can rotate the images correctly. It makes sense to put this functionality in gdk-pixbuf, though (otherwise rotation code from gThumb has to be put into the Nautilus thumbnailer, etc).

Is it OK with you if I head in the direction of adding 

gdk_pixbuf_new_from_file_oriented
gdk_pixbuf_new_from_file_at_scale_oriented

functions to return properly oriented pixbufs? 

Or do you suggest a different approach (e.g., just fix gdk_pixbuf_new_from_file and gdk_pixbuf_new_from_file_at_scale, even though this may temporarily cause unexpected behaviour in client programs, and width and height may become swapped in scaled loading?)

I'm coming at this from a gThumb perspective, BTW...


- Mike
Comment 8 Matthias Clasen 2007-04-30 18:31:31 UTC
If we can make the orientation information available as options, then 

gdk_pixbuf_rotate_simple
gdk_pixbuf_flip 

should be enough to let apps get correctly oriented images. That should
be good enough for simple uses, even if it involves maybe 1-2 extra copies.

To avoid that, I'd tend to look at adding a way to specify orientation
when loading with a GdkPixbufLoader, similar to gdk_pixbuf_loader_set_size().

Comment 9 Michael Chudobiak 2007-05-04 20:00:39 UTC
Closing bug, the libtiff minimum requirement changes are included in the patch in bug 428725.

- Mike


*** This bug has been marked as a duplicate of 428725 ***