Rotation metadata

[the-database]

Hi, thanks for this project, it is much faster than cv2 for loading small patches from large images for deep learning. I am trying to use it as a drop in replacement for cv2, but I found that the behavior differs from cv2 with respect to PNG images containing rotation metadata. Sample:

import pyvips
import cv2

image_path = r".\0.615461_9766635431_20.png"

im = cv2.imread(image_path)
cv2.imwrite("test_cv2.png", im)

im_vips = pyvips.Image.new_from_file(image_path)
im_vips.write_to_file("test_pyvips.png")

Input file with the rotation metadata: 0.615461_9766635431_20.zip

When I view test_cv2.png in my image viewer, it is in portrait orientation, while test_pyvips.png is rotated 90 degrees clockwise. Am I doing something wrong, or is this behavior a bug with pyvips?

[jcupitt]

Hello @the-database,

Yes, by default, pyvips will always present pixels to you as they are in the file. This means it can start processing sooner -- if it obeyed the rotation flag, it would need to decode the whole thing before it could give the first pixel to your program.

If you must have pixels in display order, you can pass images through autorot(). This will examine any rotation metadata and spin the image upright, but it'll make processing a lot slower in some cases.

[the-database]

Thanks for the info, I didn't know about autorot(). Unfortunately it doesn't seem to affect the result of my test. Also, I just tried the same test on a jpg with rotation metadata and pyvips and cv2 produce the same result when using the jpg. Is it possible pyvips is only reading the rotation metadata for JPEG but not PNG?

[jcupitt]

Ah you're right, your file has 8bim, xmp and iptc metadata encoded in PNG comment fields:

$ vipsheader -a 0.615461_9766635431_20.png 
0.615461_9766635431_20.png: 1165x874 uchar, 3 bands, srgb, pngload
width: 1165
height: 874
bands: 3
format: uchar
coding: none
interpretation: srgb
xoffset: 0
yoffset: 0
xres: 2.834
yres: 2.834
filename: 0.615461_9766635431_20.png
vips-loader: pngload
png-comment-0-Raw profile type 8bim: 
8bim
     124
3842494d03ed000000000010004800000001000100480000000100013842494d04040000
000000381c015a00031b25471c0200000200041c0237000832303139303530361c023c00
063032313232381c02dd000c303a303a303a3030303336303842494d0425000000000010
562ab8a2c87603123a...
png-comment-1-Raw profile type iptc: 
iptc
      56
1c015a00031b25471c0200000200041c0237000832303139303530361c023c0006303231
3232381c02dd000c303a303a303a303030333630

png-comment-2-Raw profile type xmp: 
xmp
    3937
3c3f787061636b657420626567696e3d22efbbbf222069643d2257354d304d7043656869
487a7265537a4e54637a6b633964223f3e203c783a786d706d65746120786d6c6e733a78
3d2261646f62653a6e733a6d6574612f2220783a786d70746b3d2241646f626520584d50
20436f726520352e362...
bits-per-sample: 8
background: 255 255 255 

libvips doesn't decode these values, though it does pass them along. Your orientation value will be in an EXIF block inside one of these.