Issue 427 in webp: portrait image gets rotated sometimes

[jerryc… via monorail]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 427 by jerryc...@gmail.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427

What steps will reproduce the problem?
1. use cwebp to encode a jpg shot by my sony a7 and then modified by lightroom (xmp file integration probably?).
2. the output is rotated 90 degree clockwise.
(note that I can only reproduce this on two of my photos with resolution 2000x3008. If I open it in photoshop and then resave it, the bug is gone)

What is the expected output? What do you see instead?
output resolution stays 2000x3008, not changing to 3008x2000

What version of the product are you using? On what operating system?
1.0.2, windows 10

Please provide any additional information below.
The bug is gone if I resave the image somehow.

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[pascal.m… via monorail]

Comment #1 on issue 427 by pascal.m...@gmail.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c1

Is there some rotation information in the EXIF or XMP metadata?
While the cwebp / dwebp tools ignore the metadata's content (but just copy them over), some viewer may make use of them. Hence the discrepancy.

Just make sure you use 'cwebp -metadata all ...', to actually copy the metadata in the WebP file.

[jerryc… via monorail]

Comment #2 on issue 427 by jerryc...@gmail.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c2

- Is there some rotation information in the EXIF or XMP metadata?
No, I don't think so. The image makes no sense when rotated.

- some viewer may make use of them. Hence the discrepancy.
I use IrfanView to open my image files, and it is shown rotated. I also tried chrome, and it also shown rotated.

- Just make sure you use 'cwebp -metadata all ...', to actually copy the metadata in the WebP file.
I tried, and I got a warning saying like only icc metadata is supported.

[pascal.m… via monorail]

Comment #3 on issue 427 by pascal.m...@gmail.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c3

i think the original jpg contain some non-EXIF -non-XMP metadata that is not handled during the conversion using cwebp.

Best would be sending (possibly privately) a sample of the problematic source.

Could also be a problem with the Windows specific system-wide image reader used by cwebp.

[jerryc… via monorail]

Comment #4 on issue 427 by jerryc...@gmail.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c4

It's okay to provide a problematic source as long as it is kept private.
How can I so do?

[jz… via monorail]

Comment #6 on issue 427 by jz...@google.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c6

> - Just make sure you use 'cwebp -metadata all ...', to actually copy the metadata in the WebP file.
> I tried, and I got a warning saying like only icc metadata is supported.

Try using the 'no-wic' binaries for windows. If you're building from source and
have the right dependencies a msys2/mingw build will be able to copy the other
2 forms of metadata.

[1227839… via monorail]

Comment #7 on issue 427 by 1227839...@qq.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c7

When using the "cwebp" command to convert a large resolution jpg format image taken by "iPhone X" into a webp format image, add "-metadata all" or "-metadata icc" parameters, or there will be an inverse The hour hand rotates 90 degrees!
I added this large-resolution jpg format image(1.jpg) taken by "iPhone X" to the "Accessories" for your convenience.
Moreover, this large-resolution jpg format image taken by "iPhone X" contains "ICC"!
(1.jpg)The resolution is 3024 * 4032.
My computer's operating system is Windows 10. Use "libwebp-1.0.2-windows-x64.zip".

Attachments:
1.jpg 2.6 MB

[pascal.m… via monorail]

Comment #8 on issue 427 by pascal.m...@gmail.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c8

I think this 'bug' has to do more with the viewer you're using, and how they handle rotation information in the metadata (EXIF, Sony1 Makernote chunks, etc.).

For instance, your original '1.jpg' file is viewed correctly in Chrome, but is badly rotated when using 'feh' viewer.
Same with WebP format: some image viewers are even less aware of WebP's metadata handling than for jpeg, and ignore rotation information in WebP files even when they are copied with -metadata all.

Which viewer are you using?

[1227839… via monorail]

Comment #9 on issue 427 by 1227839...@qq.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c9

pascal.m...@gmail.com,No matter which image viewer I use to view, the result is a 90 degree counterclockwise rotation.
The "vwebp" command, the latest version of Google Browser, the latest version of Firefox Browser, and Windows 10's own tools for viewing webp-formatted images, all of which rotate 90 degrees counterclockwise.

Attachments:
AAA.jpg.webp 7.0 MB

[jz… via monorail]

Updates:
Status: Invalid

Comment #10 on issue 427 by jz...@google.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c10

I agree with Pascal, this is more on the rendering side. We're copying both the ICC and Exif data (which specifies the orientation as 6 = rotate 90) with -metadata all. You can check the contents of the webp using webpinfo [1].
As a workaround tools like imagemagick can be used to transcode the file with the orientation corrected, see -auto-orient.

[1]
$ ./examples/webpinfo /tmp/1.jpg.webp
File: /tmp/1.jpg.webp
RIFF HEADER:
File size: 614562
Chunk VP8X at offset 12, length 18
ICCP: 1
Alpha: 0
EXIF: 1
XMP: 0
Animation: 0
Canvas size 4032 x 3024
Chunk ICCP at offset 30, length 556
Chunk VP8 at offset 586, length 613900
Width: 4032
Height: 3024
Alpha: 0
Animation: 0
Format: Lossy (1)
Chunk EXIF at offset 614486, length 76

[ab.fevr… via monorail]

Comment #11 on issue 427 by ab.fevr...@gmail.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c11

The bug is still happening in july 2020.

Somehow, when using `cwebp -metadata all -preset photo -q 90 20151215_140812.jpg -o 20151215_140812.webp`, you indeed get a webp image with the exact same EXIF metadata (I checked with gwenview under Linux), however the image is rotated 90° clockwise in _all_ the image viewers I could get my hand on:
- gwenview
- firefox 80b1
- chromium 83
- vwebp

So, it's highly unlikely that all those image viewers are wrong, but the webp output must be at fault here.
This bug is in my opinion major since it effectively prevents batch converting old jpeg folders.

I've attached the source JPG file so you can test it yourself.

Could you please re-open that bug? Thanks!

Attachments:
20151215_140812.jpg 2.6 MB

[ab.fevr… via monorail]

Comment #12 on issue 427 by ab.fevr...@gmail.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c12

For information, this is how the images are shown in gwenview.

Attachments:
2020-07-30_144128_Screenshot.png 300 KB

[pascal.m… via monorail]

Comment #13 on issue 427 by pascal.m...@gmail.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c13

i think the initial conclusion still stands: libwebp, as a codec, has no business looking into the EXIF metadata (or even editing them!)(esp. if they are proprietary data!).
They just pass it on from jpg to webp as a whole.
It's unfortunate that the viewers can't handle this metadata *when they are embedded in a webp file* (since apparently they work ok when it's embedded in a jpg file).

That being said, this EXIF format for orientation seems non-standard.
What device did you use to capture the photo? Looks like the exif is using Makernote proprietary data to overwrite the orientation.

As jzern@ said, your best solution is to use imagemagick's -auto-orient option (it seems exiv2 can do that too).
Additionally, you could try filing a bug-report to the viewers you mentioned, asking for support of exotic EXIF orientations(esp. if they are already OK for JPG decoding).

[Merouane Nadir]

imagemagick's -auto-orient is not a correct solution at all because with that we loose the transparency informations from the original jpeg/png and the image become all buggy with weird imagemagick conversions.  So the orientation will become good but the picture if transparent will become garbage. 

Can be a auto-orient kind of code added into cwebp?  

[James Zern]

Hi,

On Tue, May 24, 2022 at 4:50 AM Merouane Nadir <nadirm...@gmail.com> wrote:

imagemagick's -auto-orient is not a correct solution at all because with that we loose the transparency informations from the original jpeg/png and the image become all buggy with weird imagemagick conversions.  So the orientation will become good but the picture if transparent will become garbage. 

Thanks for the feedback. This sounds like it might be an issue with imagemagick, either in the tool or its use. Do you have an example you can post? You might also try posting the question on ImageMagick's forums:

https://github.com/ImageMagick/ImageMagick/discussions

 

Can be a auto-orient kind of code added into cwebp?  

Le vendredi 31 juillet 2020 à 12:45:40 UTC+2, pascal.m… via monorail a écrit :

Comment #13 on issue 427 by pascal.m...@gmail.com: portrait image gets rotated sometimes
https://bugs.chromium.org/p/webp/issues/detail?id=427#c13

i think the initial conclusion still stands: libwebp, as a codec, has no business looking into the EXIF metadata (or even editing them!)(esp. if they are proprietary data!).
They just pass it on from jpg to webp as a whole.
It's unfortunate that the viewers can't handle this metadata *when they are embedded in a webp file* (since apparently they work ok when it's embedded in a jpg file).

That being said, this EXIF format for orientation seems non-standard.
What device did you use to capture the photo? Looks like the exif is using Makernote proprietary data to overwrite the orientation.

As jzern@ said, your best solution is to use imagemagick's -auto-orient option (it seems exiv2 can do that too).
Additionally, you could try filing a bug-report to the viewers you mentioned, asking for support of exotic EXIF orientations(esp. if they are already OK for JPG decoding).

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

--

You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/8bbd9e1f-9039-4719-8f1a-0ddd48f081e8n%40webmproject.org.