Discussion:
[Development] Rotating JPEG images by default
Rainer Keller
2015-04-17 07:10:43 UTC
Permalink
Hi,

there was a change to introduce handling of exif orientation when
loading JPEG images.
Two bugreports complaining Qt is not handling image orientation caused
me to fix this. But now we got bugreports claiming the opposite.

In my opinion the orientation information is an essential part of the
image and should be applied by default. Taking a picture with your
camera users would expect it to look the same in a QImage as it was
taken. Therefor it should respect the orientation by default.

There are different implementations on other projects. For TIFF format
the rotation is also applied. But in webbrowsers the rotation is usually
not handled and must be enabled by an additional CSS flag.

Regards,
Rainer
Agocs Laszlo
2015-04-17 08:08:16 UTC
Permalink
Hi Rainer,

Which bug reports are we talking about?

Are you saying that newer versions of Qt would automatically apply rotation to certain images? That's clearly a regression and cannot be done by default. At this stage it can be an opt-in feature at best.

The difference to formats like TIFF is unfortunate. Ideally none of the image plugins should apply such smartness automatically (there can be other use cases where we want the pixels as in the file, not everything is a photo viewer application). Instead, there should have been a QImageReader level API to enable this.

BR,
Laszlo

________________________________________
From: development-bounces+laszlo.agocs=***@qt-project.org <development-bounces+laszlo.agocs=***@qt-project.org> on behalf of Rainer Keller <***@theqtcompany.com>
Sent: Friday, April 17, 2015 9:10 AM
To: ***@qt-project.org
Subject: [Development] Rotating JPEG images by default

Hi,

there was a change to introduce handling of exif orientation when
loading JPEG images.
Two bugreports complaining Qt is not handling image orientation caused
me to fix this. But now we got bugreports claiming the opposite.

In my opinion the orientation information is an essential part of the
image and should be applied by default. Taking a picture with your
camera users would expect it to look the same in a QImage as it was
taken. Therefor it should respect the orientation by default.

There are different implementations on other projects. For TIFF format
the rotation is also applied. But in webbrowsers the rotation is usually
not handled and must be enabled by an additional CSS flag.

Regards,
Rainer
Rainer Keller
2015-04-17 08:13:47 UTC
Permalink
Post by Agocs Laszlo
Which bug reports are we talking about?
https://bugreports.qt.io/browse/QTBUG-37946
https://bugreports.qt.io/browse/QTBUG-45552
Allan Sandfeld Jensen
2015-04-17 08:48:09 UTC
Permalink
Post by Agocs Laszlo
The difference to formats like TIFF is unfortunate. Ideally none of the
image plugins should apply such smartness automatically (there can be
other use cases where we want the pixels as in the file, not everything is
a photo viewer application). Instead, there should have been a
QImageReader level API to enable this.
If we go with the QImageReader level, it could be an QImageIOHandler::Option,
and possibly be set different between JPEG and TIFF by default. The real
problem is what we decide the default for JPEG should be now.

Ideally the orientation could also be kept as metadata in QImage.

`Allan
Friedemann Kleint
2015-04-17 09:37:52 UTC
Permalink
Hi,
Post by Allan Sandfeld Jensen
Post by Allan Sandfeld Jensen
If we go with the QImageReader level, it could be an
QImageIOHandler::Option,
Post by Allan Sandfeld Jensen
and possibly be set different between JPEG and TIFF by default. The real
problem is what we decide the default for JPEG should be now.
Can we add an API making this settable until the beta? - I think
automatic rotation is a really cool feature for any viewer-like
application and saves writing a lot of quite advanced code (using memory
mapping of files and endian-dependent word fiddling on platforms that
don't have libexif or similar).

Regards,
Friedemann
--
Friedemann Kleint | The Qt Company
Olivier Goffart
2015-04-17 09:51:34 UTC
Permalink
Post by Allan Sandfeld Jensen
Hi,
Post by Allan Sandfeld Jensen
Post by Allan Sandfeld Jensen
If we go with the QImageReader level, it could be an
QImageIOHandler::Option,
Post by Allan Sandfeld Jensen
and possibly be set different between JPEG and TIFF by default. The real
problem is what we decide the default for JPEG should be now.
Can we add an API making this settable until the beta? - I think
automatic rotation is a really cool feature for any viewer-like
application and saves writing a lot of quite advanced code (using memory
mapping of files and endian-dependent word fiddling on platforms that
don't have libexif or similar).
Personally, I was really happy to see that fixed. I even backported it to 5.3
for a customer.

The use case is that we have code like

QPixmap myPixmap(fileName);

So the API should span in many places QImage, QPixmap, QImageReader,
QImageIOHandler, ...

It is true that it is a behaviour change. But now it is too late anyway, and
reverting the patch would make another behaviour change.

The question is if there are application that need to access the original
orientation. And I think it might make sens to have such metadata available
form QImage or so (we have QImage::text already)
But at this point, I suppose that if we really need it, it should wait Qt 5.6
--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
Sorvig Morten
2015-04-17 09:46:52 UTC
Permalink
Post by Allan Sandfeld Jensen
Ideally the orientation could also be kept as metadata in QImage.
I’d like to see general metadata support in QImage. The closest thing we have seems to be QImage::text(), which supports QString data only.

My specific use case setting and preserving the NSImage “template” property [1] across QImage -> NSImage conversions. This does not really deserve a separate setter/getter: a key/value API would be ideal.

Morten

[1]https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/index.html#//apple_ref/occ/instm/NSImage/setTemplate:
Allan Sandfeld Jensen
2015-04-17 10:10:22 UTC
Permalink
Post by Sorvig Morten
Post by Allan Sandfeld Jensen
Ideally the orientation could also be kept as metadata in QImage.
I’d like to see general metadata support in QImage. The closest thing we
have seems to be QImage::text(), which supports QString data only.
My specific use case setting and preserving the NSImage “template” property
[1] across QImage -> NSImage conversions. This does not really deserve a
separate setter/getter: a key/value API would be ideal.
I tried starting on a possible API, just to see if it could be done:
https://codereview.qt-project.org/#/c/110685/

`Allan
Rutledge Shawn
2015-04-17 10:44:10 UTC
Permalink
Post by Allan Sandfeld Jensen
Post by Sorvig Morten
Post by Allan Sandfeld Jensen
Ideally the orientation could also be kept as metadata in QImage.
I’d like to see general metadata support in QImage. The closest thing we
have seems to be QImage::text(), which supports QString data only.
My specific use case setting and preserving the NSImage “template” property
[1] across QImage -> NSImage conversions. This does not really deserve a
separate setter/getter: a key/value API would be ideal.
https://codereview.qt-project.org/#/c/110685/
QTBUG-22367 needs to get fixed too, which I was trying to do here

https://codereview.qt-project.org/#/c/101084/

and I have a patch to show metadata in the imageviewer example

https://codereview.qt-project.org/#/c/101083/
Alberto Mardegan
2015-04-21 15:24:20 UTC
Permalink
Post by Allan Sandfeld Jensen
If we go with the QImageReader level, it could be an QImageIOHandler::Option,
and possibly be set different between JPEG and TIFF by default. The real
problem is what we decide the default for JPEG should be now.
IMHO, QImageReader default behaviour should be that of providing a
rendered image that looks as visually correct as possible. Whether the
orientation is encoded in the image bits or as an EXIF tag is rather
irrelevant: the result should be that the QImage contains the image
shown with the proper orientation.
So, I'm very happy that this bug has been fixed.

On the other hand, since we had applications which had already
implemented workarounds for this, we should have a way to let them know
whether they are using a new Qt image plugin which contains this fix or not.
Adding an orientation option to QImageIOHandler::ImageOption would be a
possibility.

Ciao,
Alberto
André Somers
2015-04-22 06:39:36 UTC
Permalink
This post might be inappropriate. Click to display it.
Alberto Mardegan
2015-04-22 11:32:51 UTC
Permalink
Post by André Somers
I'm with Konstatin on this one: it seems like a regression to me. It
would be a useful feature to add, but then add it in such a way that it
is actually clear what it does, the user can control it, and it does not
break applications. I think it _is_ relevant how the image is encoded.
It may be that we disagree because we have a different view of what is
the goal of QImage and friends. To me, what matters is not the pixel
data, but how the image looks like when I blit it.
I'm writing an image viewer using QML, and I just expect that

Image {
source: "file.jpg"
}

will show me the file as it's intended to be viewed. I don't think that
it's acceptable to require the developer to play with flags in order to
see the image with the correct rotation.
Post by André Somers
If the camera really wanted to put the image in the right side up, it
should have just rotated the actual image. By default, I would expect to
load the image as-is.
We disagree on what "as-is" means. :-) For me, EXIF information is an
integral part of the image.
Also, sometimes the camera guesses the orientation wrong (especially
when you shoot at the sky or at the ground), and the best way to correct
that is to do it in a lossless way, using the EXIF rotation flag; there
are several image viewers that allow you to do this.

Ciao,
Alberto
Иван Комиссаров
2015-04-22 11:57:47 UTC
Permalink
I think, there should be an option in Image item to use autorotation or not
Post by Alberto Mardegan
Post by André Somers
I'm with Konstatin on this one: it seems like a regression to me. It
would be a useful feature to add, but then add it in such a way that it
is actually clear what it does, the user can control it, and it does not
break applications. I think it _is_ relevant how the image is encoded.
It may be that we disagree because we have a different view of what is
the goal of QImage and friends. To me, what matters is not the pixel
data, but how the image looks like when I blit it.
I'm writing an image viewer using QML, and I just expect that
Image {
source: "file.jpg"
}
will show me the file as it's intended to be viewed. I don't think that
it's acceptable to require the developer to play with flags in order to
see the image with the correct rotation.
Post by André Somers
If the camera really wanted to put the image in the right side up, it
should have just rotated the actual image. By default, I would expect to
load the image as-is.
We disagree on what "as-is" means. :-) For me, EXIF information is an
integral part of the image.
Also, sometimes the camera guesses the orientation wrong (especially
when you shoot at the sky or at the ground), and the best way to correct
that is to do it in a lossless way, using the EXIF rotation flag; there
are several image viewers that allow you to do this.
Ciao,
Alberto
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Konstantin Ritt
2015-04-22 15:47:27 UTC
Permalink
Konstantin
Post by Alberto Mardegan
Post by André Somers
I'm with Konstatin on this one: it seems like a regression to me. It
would be a useful feature to add, but then add it in such a way that it
is actually clear what it does, the user can control it, and it does not
break applications. I think it _is_ relevant how the image is encoded.
It may be that we disagree because we have a different view of what is
the goal of QImage and friends. To me, what matters is not the pixel
data, but how the image looks like when I blit it.
I'm writing an image viewer using QML, and I just expect that
Image {
source: "file.jpg"
}
will show me the file as it's intended to be viewed. I don't think that
it's acceptable to require the developer to play with flags in order to
see the image with the correct rotation.
In your image viewer, you'll have 99 other QML Image elements for
buttons/background/whatever that doesn't load photos.
I don't think your expectation/intention is to make all your UI elements
1) dependent on a metadata ignored by most image viewers (- crap, editor
shows me a 400x300 image and it appears to be 300x400 in QML. stupid QML!
stupid trolls! I need to kill someone...)
2) behave differently prior to 5.4 and after 5.4.

Enabling that feature in 5.4 IS a behavioral regression which must be fixed.
Post by Alberto Mardegan
If the camera really wanted to put the image in the right side up, it
Post by André Somers
should have just rotated the actual image. By default, I would expect to
load the image as-is.
We disagree on what "as-is" means. :-) For me, EXIF information is an
integral part of the image.
Regardless of how you interpret "image as it's intended to be viewed", CSS
doesn't do auto-rotation by default - one have to enable this feature where
needed.
Post by Alberto Mardegan
Also, sometimes the camera guesses the orientation wrong (especially
when you shoot at the sky or at the ground), and the best way to correct
that is to do it in a lossless way, using the EXIF rotation flag; there
are several image viewers that allow you to do this.
Unrelated. It doesn't matter where to transform - on the camera, in the
viewer, or at load time.
André Pönitz
2015-04-22 18:54:06 UTC
Permalink
I am, too.
Post by Alberto Mardegan
Post by André Somers
it seems like a regression to me. It
would be a useful feature to add, but then add it in such a way that it
is actually clear what it does, the user can control it, and it does not
break applications. I think it _is_ relevant how the image is encoded.
And I agree with André here.
Post by Alberto Mardegan
It may be that we disagree because we have a different view of what is
the goal of QImage and friends.
QImage is traditionally closer to "pixel manipulation" than to "display",
which is QPixmap's domain, albeit both with quite some wiggle room.
Post by Alberto Mardegan
To me, what matters is not the pixel
data, but how the image looks like when I blit it.
That's of course one possible expectation, and without further context
possibly even a reasonable one.

However, we do have context here, namely existing behaviour in Qt 5.x,
as well as certain general promises given for changes between Qt 5.x and
Qt 5.(x+1).
Post by Alberto Mardegan
I'm writing an image viewer using QML, and I just expect that
Image {
source: "file.jpg"
}
will show me the file as it's intended to be viewed. I don't think that
it's acceptable to require the developer to play with flags in order to
see the image with the correct rotation.
Even though "no behaviour change" isn't one of the guarantees, I don't
think rotating part of an application's GUI by 90 degrees behind the
developer's back is acceptable.

If an application accepts such change it should announce it by explicitly
opting in, i.e. by setting a flag/calling a function/whatever.

Andre' [another one]
Alberto Mardegan
2015-04-22 22:11:23 UTC
Permalink
Post by André Pönitz
However, we do have context here, namely existing behaviour in Qt 5.x,
as well as certain general promises given for changes between Qt 5.x and
Qt 5.(x+1).
I see it as a long standing bug which finally got fixed.

But the problem is that the behavioural change is already out there,
with Qt 5.4. I think it would be easier to have a runtime check on the
QT version (and eventually drop the local workarounds) than to introduce
another behavioural change in the next Qt version.
Post by André Pönitz
Even though "no behaviour change" isn't one of the guarantees, I don't
think rotating part of an application's GUI by 90 degrees behind the
developer's back is acceptable.
It's very unlikely that such images are used as part of the GUI. But I'm
nitpicking, I certainly agree with you that the behavioural change is a
major annoyance.
However, if application developers had filed this bug earlier, instead
of silently working around it in their application, we wouldn't even be
discussing this. So, in a way, I believe that if this behavioural change
affects someone in a bad way, some part of the blame falls on his side too.
Post by André Pönitz
If an application accepts such change it should announce it by explicitly
opting in, i.e. by setting a flag/calling a function/whatever.
Actually, this sounds like a very good idea; I wouldn't mind if this was
a opt-in, as long as the behaviour was configurable with a single line
change (a static method on QGuiApplication, maybe?).
As long as I don't have to change it in every single QImage/QML Image,
all is fine to me.

Ciao,
Alberto
Jan Kundrát
2015-04-23 00:29:29 UTC
Permalink
Post by Alberto Mardegan
as long as the behaviour was configurable with a single line
change (a static method on QGuiApplication, maybe?).
That means that you will have to patch all libraries which care about this
option and which you're using at the same time. I don't think that this is
realistic.

Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Konstantin Ritt
2015-04-23 01:53:08 UTC
Permalink
Post by Alberto Mardegan
as long as the behaviour was configurable with a single line
change (a static method on QGuiApplication, maybe?).
Stop polluting QGuiApplication! Seriously.

We already have a complete solution -
https://codereview.qt-project.org/110685
All we need now is to fix the behavioral regression introduced in 5.4.

Konstantin

P.S. I bet most of you didn't know about this new cool feature until this
thread, just like me.
Alberto Mardegan
2015-04-23 08:00:08 UTC
Permalink
Post by Konstantin Ritt
We already have a complete solution -
https://codereview.qt-project.org/110685
That looks good.
Post by Konstantin Ritt
All we need now is to fix the behavioral regression introduced in 5.4.
But if I understand the code correctly, the fix above gives developers
an option to opt *out* of the automatic rotation, so it will still
behave differently than Qt < 5.4, unless the developer updates his app
to use the new API.

Which to me is all very good, but I think it's not what you have been
suggesting in this thread.

Ciao,
Alberto
Allan Sandfeld Jensen
2015-04-23 10:03:14 UTC
Permalink
Post by Alberto Mardegan
Post by Konstantin Ritt
We already have a complete solution -
https://codereview.qt-project.org/110685
That looks good.
Post by Konstantin Ritt
All we need now is to fix the behavioral regression introduced in 5.4.
But if I understand the code correctly, the fix above gives developers
an option to opt *out* of the automatic rotation, so it will still
behave differently than Qt < 5.4, unless the developer updates his app
to use the new API.
Which to me is all very good, but I think it's not what you have been
suggesting in this thread.
It has gone through several iterations, and this is where it is currently at.
If there is a consensus to change the defaults the patch can easily be amended
again.

Right now I don't see a consensus though, and personally lean both ways.

`Allan
Gunnar Sletta
2015-04-23 10:36:05 UTC
Permalink
I think we should strive to not introduce regressions on purpose. Hence:
- Revert the behavioral change in 5.4 which adds rotation to JPEGs
- Have opt-in rotation in QImageReader.
- Keep TIFF rotation as it is (and change it to the Qt-wide default for Qt 6)

Anything else will cause us a lot of pain down the line.

cheers,
Gunnar
Post by Allan Sandfeld Jensen
Post by Alberto Mardegan
Post by Konstantin Ritt
We already have a complete solution -
https://codereview.qt-project.org/110685
That looks good.
Post by Konstantin Ritt
All we need now is to fix the behavioral regression introduced in 5.4.
But if I understand the code correctly, the fix above gives developers
an option to opt *out* of the automatic rotation, so it will still
behave differently than Qt < 5.4, unless the developer updates his app
to use the new API.
Which to me is all very good, but I think it's not what you have been
suggesting in this thread.
It has gone through several iterations, and this is where it is currently at.
If there is a consensus to change the defaults the patch can easily be amended
again.
Right now I don't see a consensus though, and personally lean both ways.
`Allan
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Alberto Mardegan
2015-04-23 11:20:33 UTC
Permalink
Post by Gunnar Sletta
- Revert the behavioral change in 5.4 which adds rotation to JPEGs
- Have opt-in rotation in QImageReader.
- Keep TIFF rotation as it is (and change it to the Qt-wide default for Qt 6)
Anything else will cause us a lot of pain down the line.
Also the above causes some pain. Whether we go for opt-in or opt-out of
the automatic rotation, please have a static method to globally specify
whether automatic rotation is desired or not.

We should have QML Image show the JPEGs with the correct rotation
without requiring special flags or custom image readers.

Ciao,
Alberto
Gunnar Sletta
2015-04-23 11:34:46 UTC
Permalink
Post by Alberto Mardegan
Post by Gunnar Sletta
- Revert the behavioral change in 5.4 which adds rotation to JPEGs
- Have opt-in rotation in QImageReader.
- Keep TIFF rotation as it is (and change it to the Qt-wide default for Qt 6)
Anything else will cause us a lot of pain down the line.
Also the above causes some pain. Whether we go for opt-in or opt-out of
the automatic rotation, please have a static method to globally specify
whether automatic rotation is desired or not.
I don’t think static options like that are a very good idea. It is not hard to enable an option in your image reading code after all. And it will be in the part of the code where people normally look for image stuff. If we put it in QGuiApplication, nobody would know to look for it there.
Post by Alberto Mardegan
We should have QML Image show the JPEGs with the correct rotation
without requiring special flags or custom image readers.
Whether or not Image {} sets the rotation mode is a separate feature, but following the same logic. Image should NOT rotate by default. Image::respectFileOrientation or whatever as an opt-in would be perfectly fine. Again, we can talk about changing that default for Qt 6, but not in the 5 timeframe, IMO.
Post by Alberto Mardegan
Ciao,
Alberto
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
André Somers
2015-04-23 11:34:43 UTC
Permalink
Post by Alberto Mardegan
Post by Gunnar Sletta
- Revert the behavioral change in 5.4 which adds rotation to JPEGs
- Have opt-in rotation in QImageReader.
- Keep TIFF rotation as it is (and change it to the Qt-wide default for Qt 6)
Anything else will cause us a lot of pain down the line.
Also the above causes some pain. Whether we go for opt-in or opt-out of
the automatic rotation, please have a static method to globally specify
whether automatic rotation is desired or not.
We should have QML Image show the JPEGs with the correct rotation
without requiring special flags or custom image readers.
What is the problem with using

Image {
source: "someImage.jpg"
autorotate: true
}

Again: note that QImage != QML Image

I don't like globals if they can be avoided. In this case, I think they can.

André
Alberto Mardegan
2015-04-23 12:04:10 UTC
Permalink
Post by André Somers
What is the problem with using
Image {
source: "someImage.jpg"
autorotate: true
}
Again: note that QImage != QML Image
I don't like globals if they can be avoided. In this case, I think they can.
I could certainly live with that, but if you renamed "autorotate" to
"showWithCorrectRotation" you'd have to agree that it's a rather silly
flag. Of course I want my images to appear with the correct rotation. :-)

I do agree that for QImage leaving the autorotation off can make sense
in some cases. But for QML Image, I cannot think of a single case where
I wouldn't want a JPEG to be automatically rotated.

Ciao,
Alberto
Konstantin Ritt
2015-04-23 12:12:13 UTC
Permalink
Post by Alberto Mardegan
Post by André Somers
What is the problem with using
Image {
source: "someImage.jpg"
autorotate: true
}
Again: note that QImage != QML Image
I don't like globals if they can be avoided. In this case, I think they
can.
I could certainly live with that, but if you renamed "autorotate" to
"showWithCorrectRotation" you'd have to agree that it's a rather silly
flag. Of course I want my images to appear with the correct rotation. :-)
I do agree that for QImage leaving the autorotation off can make sense
in some cases. But for QML Image, I cannot think of a single case where
I wouldn't want a JPEG to be automatically rotated.
The behavior must be consistent for both.
I cannot think of a single case where you would want text direction to be
automatically applied in QML but not in QTextDocument (not an ideal
example, but still).

Konstantin
Konstantin Ritt
2015-04-23 12:33:40 UTC
Permalink
Just FYI,
http://www.daveperrett.com/articles/2012/07/28/exif-orientation-handling-is-a-ghetto/
http://webmasters.stackexchange.com/questions/16684/ipad-and-iphone-browser-rotating-images-on-site
(note that OS from Apple is a bit "special")
and the CSS3 working group discussion:
http://lists.w3.org/Archives/Public/www-style/2011Dec/0001.html


Konstantin
Allan Sandfeld Jensen
2015-04-23 12:46:52 UTC
Permalink
Post by Alberto Mardegan
Post by André Somers
What is the problem with using
Image {
source: "someImage.jpg"
autorotate: true
}
Again: note that QImage != QML Image
I don't like globals if they can be avoided. In this case, I think they can.
I could certainly live with that, but if you renamed "autorotate" to
"showWithCorrectRotation" you'd have to agree that it's a rather silly
flag. Of course I want my images to appear with the correct rotation. :-)
I do agree that for QImage leaving the autorotation off can make sense
in some cases. But for QML Image, I cannot think of a single case where
I wouldn't want a JPEG to be automatically rotated.
Well, it could be separated between QImage and QPixmap, and QML images
following QPixmap. With the logic being that images are for pixel handling and
pixmaps for showing. It could cause all kinds of confusion though.

`Allan

André Somers
2015-04-23 05:34:21 UTC
Permalink
Post by Alberto Mardegan
It may be that we disagree because we have a different view of what is
the goal of QImage and friends. To me, what matters is not the pixel
data, but how the image looks like when I blit it.
I'm writing an image viewer using QML, and I just expect that
Image {
source: "file.jpg"
}
will show me the file as it's intended to be viewed. I don't think that
it's acceptable to require the developer to play with flags in order to
see the image with the correct rotation.
Please note that QImage isn't the same as the QML/Quick Image element. I
think your example confuses the discussion. QImage is not a class that
does displaying of images on the screen. I am not against adding a
property autoRotate or something like that on the Image element at all
(but again: not enabled by default please).

André
Allan Sandfeld Jensen
2015-04-17 12:19:01 UTC
Permalink
Post by Rainer Keller
Hi,
there was a change to introduce handling of exif orientation when
loading JPEG images.
Two bugreports complaining Qt is not handling image orientation caused
me to fix this. But now we got bugreports claiming the opposite.
In my opinion the orientation information is an essential part of the
image and should be applied by default. Taking a picture with your
camera users would expect it to look the same in a QImage as it was
taken. Therefor it should respect the orientation by default.
There are different implementations on other projects. For TIFF format
the rotation is also applied. But in webbrowsers the rotation is usually
not handled and must be enabled by an additional CSS flag.
I would like to mention one extra relevant detail. While this was implemented
for 5.4, it was not working in 5.4.0, and was only fixed for 5.4.1. So sofar
only 5.4.1 has had EXIF orientation automatically applied on JPEGs. This also
raises the question about what to do for 5.4.2?

Best regards
`Allan
Rainer Keller
2015-04-17 12:23:50 UTC
Permalink
Post by Allan Sandfeld Jensen
I would like to mention one extra relevant detail. While this was implemented
for 5.4, it was not working in 5.4.0, and was only fixed for 5.4.1. So sofar
only 5.4.1 has had EXIF orientation automatically applied on JPEGs. This also
raises the question about what to do for 5.4.2?
I actually worked, theoretically. There was a bug with the endianess
when reading the data field. It worked when data was generated on little
endian machines but all photo cameras are big endian.
This means only photos taken on x86 machines would have been rotated.
Konstantin Ritt
2015-04-20 04:37:57 UTC
Permalink
This post might be inappropriate. Click to display it.
Konstantin Ritt
2015-04-20 04:53:30 UTC
Permalink
And to be honest, I don't like the QImage::orientation() API addition w/o
providing setOrientation() and a respective code code in the image writer
to store orientation as metadata (when possible).
`QImage img(sourcePath); img = img.scaled(img.width() / 2, mg.height() /
2); img.save(destPath);` should not loose the metadata when the format has
not been changed (at least).

Regards,
Konstantin
Post by Konstantin Ritt
I failed to find an official announcing for the EXIF-based auto-rotation
of QImage-s (correct me if I'm wrong), so it looks just like a behavioral
regression to me, nothing more.
IMO, we should revert the behavior to pre 5.4 and give the control over
the image aspects to the user, not to an arbitrary image loader.
I mean https://codereview.qt-project.org/#/c/110685/ and
https://codereview.qt-project.org/#/c/101084/ could co-operate quite nicely
to make the user think: "why my photo gets loaded rotated 90 degrees? ah,
img.sourceOrientation() == QImage::Rotated90 -->
img.transform(img.sourceOrientation())")
P.S. Also not the sample image in QTBUG-37946
<https://bugreports.qt.io/browse/QTBUG-37946> isn't auto-rotated in your
web browser (well, at least in my web browser).
Regards,
Konstantin
Post by Allan Sandfeld Jensen
Post by Allan Sandfeld Jensen
I would like to mention one extra relevant detail. While this was
implemented
Post by Allan Sandfeld Jensen
for 5.4, it was not working in 5.4.0, and was only fixed for 5.4.1. So
sofar
Post by Allan Sandfeld Jensen
only 5.4.1 has had EXIF orientation automatically applied on JPEGs.
This also
Post by Allan Sandfeld Jensen
raises the question about what to do for 5.4.2?
I actually worked, theoretically. There was a bug with the endianess
when reading the data field. It worked when data was generated on little
endian machines but all photo cameras are big endian.
This means only photos taken on x86 machines would have been rotated.
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Loading...