Re: [gthumb-list] Bug: EXIF orientation is broken after resize

[Rennie deGraaf <rennie degraaf gmail com>]

On 01/02/13 12:54 PM, damien clochard wrote:
> Le 29/01/2013 16:30, Dr. Michael J. Chudobiak a écrit :
> > > > the orientation field makes sense only in the original image, when you
> > > > create a new image it is better to reset it.
> > >
> > > Sorry again but I don't understand this logic. I don't see how resetting
> > > the orientation after a resize operation is useful to anyone. These are
> > > two different things. My understanding is that gthumb should keep this
> > > orientation when user ask for a resize.
> > >
> > > Am I correct ?
> >
> > No. The orientation tag is taken into account when the image is loaded
> > into memory.
> >
> > The resize happens on the image in memory.
>
> Yes I am aware that the transformation are executed "in memory" and not
> directly on disk :-) Anyway I don't see how this is related with the
> issue I described.

As I understand it (forgive me if this has changed since I last looked
at the code), gThumb rotates every image that it loads to the "top-left"
orientation.  If it subsequently saves the image, it uses the rotated
image data and sets the EXIF tag to "top-left" to ensure that the tag
matches the data.

If you want to try to understand the reasoning behind the current
behaviour, we had a huge discussion on how we should handle rotation and
Exif orientation back in 2006 at
https://bugzilla.gnome.org/show_bug.cgi?id=343867.

> > To save it with your original orientation tag, another step would be
> > required to rotate the image and copy the original tag. There is no
> > advantage to adding that degree of complexity (and slowness).
>
> But most EXIF fields are left unmodified... If you're able to copy some
> of the original EXIF tags, why not do it for the orientation as well ?
> Just don't modify it in the first place...
>
> All I'm asking is "why are you changing the EXIF fields ?" and you're
> answer is "because if we don't, it will add complexity and slowness"...
>
> I'm confused.

Saving the image with the original Exif orientation tag would violate
the Exif 2.2 standard, which recommends that any tool that re-saves an
image containing an Exif tag changes the orientation to "top-left".
(The standard also recommends that most other Exif tags be copied
without change.)  It also is less than ideal with respect to tools that
aren't Exif-aware, which generally assume a "top-left" orientation.

Also, if gThumb was to save the image with its original Exif
orientation, it would need to undo the original rotation to ensure that
the tag matches the image data.  This adds time and complexity, as noted.

What use cases do you have where it's important that the original Exif
orientation is preserved?

> > The resulting image should look correct, of course. If it doesn't, there
> > is a bug. But the orientation tag should be reset.
>
> Says who ? Where is it written that "the orientation tag should be
> reset"? Is this a secret rule among graphic sofwtare developpers ? ;-)

Exif 2.2 (http://www.exif.org/Exif2-2.PDF), section 7.4.  In particular,
see "Explication Table 3" on page 142.

Rennie