Note that the image texture is not mapped correctly at the lower half of the image. So far, I have only observed this behavior on portrait oriented images. In other words, on images that are taller than wide.
The same happens when using the software renderer, so I guess we can rule out a driver bug.
The reason for broken texture coordinates on portrait oriented images is probably incorrect processing of width and height values. When you look at the … “Image details” panel on a portrait oriented image then width and height are identical to their Exif counterparts, which is fine I guess because the API v4 responds with the exif_orientation member. But, the viewer does not seem to take exif_orientation into account. Imho the … “Image details” panel should display width and height with exif_orientation applied because it is end user facing. I would rather not change the semantics of the API because API consumers can apply exif_orientation whenever they need or want to.
Thank you for letting us know @GITNE. This should now be fixed, please take a look. We appreciate your feedback!
Wow! 
Looks great! Thank you.
However, the “Image resolution” field in the … “Image details” sub-menu still does not apply Exif’s Orientation tag.
Thanks! In terms of the image resolution, do you mean that it should be listed as 3000 x 4000 instead of 4000 x 3000 in your example?
In terms of the image resolution, do you mean that it should be listed as 3000 x 4000 instead of 4000 x 3000 in your example?
Right, that’s at least my humble opinion because it is user facing, unless you explicitly want to display Exif values which is not intuitively apparent. Anyway, that’s just a detail.