Affinity Photo 2 rotates linked resource following external edit of the linked image file

[Granddaddy]

 

The following occurred when the linked resource is in portrait orientation but the APhoto2 document is landscape:

1.) Launch APhoto2 2.0.0
2.) Uncheck "Automatically update linked resources..." in Preferences
3.) Create new document: 18x12, 300 dpi, Prefer Linked 
4.) Save as Collage-New.afphoto
5.) Drag and drop File2.jpg into document from Windows Explorer. It appears in Resource Manager as a linked resource as expected
6.) Resize and position the image
7.) Save collage. All is well so far.
8.) Edit the linked jpg with an external editor and save it (I changed only brightness and contrast)
9.) APhoto2 notifies that a linked resource has been updated.
10.) Click Update in Resource Manager
11.) Image is updated but rotated 90 degrees clockwise.

In this case, the linked image file2.jpg is in portrait orientation whereas the collage I'm trying to make is landscape.

 

 

 

 

 

[SrPx]

I'm curious... Does it happen (the rotation) if you leave as checked the "automatically update the linked resources" ? (I don't mean it's a solution, as it is not. It's just curiosity).

[Granddaddy]

With "Automatically update the linked resources" checked, Affinity Photo vanishes as soon as the linked file is updated, so there is no way to tell how it would have appeared in the collage.

[SrPx]

Oki, for those unaware, we continued the conversation in the other thread (same matters and extra related issues), we reaching  there very good conclusions :

 

[Granddaddy]

Thanks again to SrPx for all his work, knowledge, and insights. He is correct that the "problem" originates with the external editor and he suggested Exiftool to examine Exif tags in the files. 

My conclusion is that this is still a bug in updating linked documents in Affinity Photo 2 (and a different bug in Affinity Photo 1). However, the workarounds are obvious and easy.

Once again I have learned that things are far more complicated than I ever imagined. I've been editing digital photos for 20 years. Never have I had to be concerned about the Exif orientation tag and the different ways it might be treated by different viewers and editors. Then again, never before did I try to make a collage using linked image files.

Below is a summary of what is going on and how you can reproduce the effect. You can decide whether or not this is a bug, whether auto-rotation is a good thing, and whether auto-rotation should be hidden so well from the user. 

We start with FLOWER-ORIGINAL.JPG, a photo of a yellow flower on a squash plant in my garden.

iPhone digital photo: FLOWER-ORIGINAL.JPG taken in portrait orientation,
copied without modification to my desktop computer from iPhone13 Photos app 

We examine the Exif tags in this original file using Exiftool.

===================
FLOWER-ORIGINAL.JPG

Examining EXIF information in the original file as saved by the camera:

Exiftool display includes:
Orientation:     Rotate 90 CW
Image Width:  4032
Image Height: 3024

We view the image in two different way, first in Windows File Explorer and then in Faststone Image Viewer.,

---------------------
Windows File Explorer gives dimensions 3024x4032
Icon displays in portrait orientation
File properties Details shows:
width 3024
height 4032

From viewing the icon in File Explorer, you would think this is a portrait image. Beware. Note that the width and height reported by Windows File Explorer differ from what Exif tool reports for the file. We are led to consider the Orientation tag.

The Exif Orientation tag is not a property that appears in the Windows File Explorer Properties Details tab. 

An explanation of Windows File Explorer auto-rotate and the orientation tag can be found at

https://www.ivertech.com/Articles/Image-Rotation-Issue-With-Windows-10.aspx

Microsoft changed the behavior of File Explorer with Windows 8. 

We can add a column for Orientation to the File Explorer Details window by right clicking the column labels row and checking the box for Orientation. When we do that for FLOWER-ORIGINAL.JPG it shows:

Orientation: Rotate 270 degrees

In normal mathematics this implies CCW rotation. Note that 270 degrees CCW is the same as 90 degrees CW

We see that Windows File Explorer auto-rotates the image to produce the icon view. It also adjusts the height and width to conform to that orientation, even though this differs from the Exif information internal to the jpg file.

The naive user such as myself expects the photo taken in portrait orientation to actually be in portrait orientation. In fact it is not. Simply posting the file to a web page or sending it to a friend might cause it to be viewed as lying on its side in landscape orientation depending on the app used to view the image.

Which brings us to looking at the image in Faststone Image Viewer.

----------------------
Faststone Image viewer (FS)

Orientation of the image will depend on the Auto-rotate setting in Faststone. The setting is just one of several checkboxes on the Settings page. It's existence is easily overlooked, especially if files are displaying as you expect them to display.

FS setting: checked "Auto-rotate by EXIF orientation tag"
File attributes are reported by FS as::
width:   3024
height:  4032
This displays as portrait as expected. Note however that the width and height tags are reversed when compared to the Exif tags read by Exiftool.

FS setting: unchecked "Auto-rotate by EXIF orientation tag"
width:  4032
height: 3024
This displays as landscape

What happens to the Exif tags, if anything, when we now save the file using Faststone? 

=============
FLOWER-FS.JPG

Open FLOWER-ORIGINAL.JPG in Faststone with auto-rotate checked.
Without making any edits, Save As FLOWER-FS.JPG to distinguish it from the original file.

Exiftool now reports 
Orientation:           Horizontal (normal)
Exif Image width:  3024
Exif Image Height: 4032

Note that Faststone has deleted the Image width and Image Height tags we saw in FLOWER-ORIGINAL.JPG. It creates two new tags: Exif Image Width and Exif Image Height. Faststone also changes the value of the Orientation tag.

The images display in portrait mode as expected both in Faststone and in File Explorer.

What happens when we view the files in Affinity Photo 2?

===========================
AFFINITY PHOTO 2 - THIS IS THE BUG

When dragged and dropped as linked resources into an existing APhoto2 document, both jpg images display in portrait mode.

Now edit FLOWER-ORIGINAL.JPG with Faststone and save over the original. 

As expected, the Exif information in FLOWER-ORIGINAL.JPG is changed to 
Orientation: Horizontal (normal)
Image width:  3024
Image Height: 4032

We would expect this to display in portrait orientation in the APhoto2 document.

However, in APhoto2 the linked copy of the now modified FLOWER-OIRIGNAL.JPG is rotated by 90 degrees CW. The linked image in APhoto2 now displays as lying on its side in landscape orientation.

It appears that when updating the linked image, APhoto2 updates the width and height from the modified jpg file but fails to respect the new Orientation tag. It acts on the orientation tag from the previous version of the file befpre the update. That tag called for rotation by 90 degrees CW. The newly saved jpg file does not call for rotation.

This to my mind is a bug. 

A couple of more details are worth noting.

===========================
FLOWER-APHOTO2.JPG

Open FLOWER-OIRGINAL.JPG in APhoto2 and, without making any edits, export it as a jpg to FLOWER-APHOTO2.JPG. 

The Exif tags are altered by APhoto2 in the same way that Faststone altered the tags, namely,
Orientation:           Horizontal (normal)
Exif Image Width:  3024
Exif Image Height: 4032

====================================
AFFINITY PHOTO 1 BEHAVES DIFFERENTLY

Note that Affinity Photo 1 disregards the orientation tag when dragging and dropping a jpg file onto an existing document. The file that is displayed in portrait orientation in Windows File Explorer and in Faststone (with auto-rotate checked) and in APhoto2 (when dropped on an existing document) is displayed in APhoto1 in landscape orientation when dragged and dropped into an existing document in APhoto1.

However, APhoto1 does regard the orientation tag of the original photo when it is dragged and dropped into APhoto1 for editing, as does APhoto2.
 

 

 

[SrPx]

Outstanding research! You really nailed it, to deep detail. Indeed, I remembered vaguely there being an orientation tag in the headers, but was mostly an intuition or blurry memory from many years ago, solving issues, as I have never been versed on metadata, neither photography (yep image editing, though).

Some conclusions, questions and theories here, but (if you wish so) correct me if I am wrong, due to me understanding some matters badly :

- Could there be a setting in iPhone (or any Android phone, but iPhones tend to be very advanced in photography matters) to make  the orientation tag configured the way that benefits better your workflow (or eliminate it if needed)? About this, a great article (I have only read a paragraph) here. Again, I'm no photography expert, and I am a very (extremely) basic phone user  : 

"But no matter how you are holding the camera, if you check the image on your computer, the image is shown in correct orientation. This has something to do with Exif orientation flag. When you are holding the camera with non-upright position, the raw photo you take is stored as a rotated image. The digital device (be a smartphone or digital camera) has a sensor to record the orientation of the camera and writes that information into orientation flag in Exif."

(It's understood way better with the graphics shown in such article)

Do I understand it right that this tag/flag depends a lot in how you hold the camera and that's it ? May  there be a setting to "force" some things, though? (or make some habits...)

https://jdhao.github.io/2019/07/31/image_rotation_exif_info/

I believe reading that article above might help you greatly in the future in many aspects of this, to make your workflow much more practical and comfortable (maybe).

- The orientation issue is a common thing on people importing media from phones, from what I often see.

- Could it be that FastStone is not writing in the most standard way that metadata  tag, and that causes the problem?

- It also could be that the bug is in Affinity's moment of reading the flag, of course.

- Exif allows for batch processing, I believe, at least the command line tool. So, a kind of "hackish" solution -for the already made photos- could be first to process all your photos (even a 200 photos folder or etc)  with exif, in batch mode (so to process all in a second), with a parameter that tells it to extract (exiftool have deep documentation) such tag, or insert it, if needed. The problem is if your photos are ones with one orientation, others with another, others with no tag... In that case I would only see the option of a python (or whatever the language, if you do some coding) script, to consider every case, but  that's surely too much work for what it's worth. There seems to be indeed some python (funnily, I though of python before seeing the article, because I like Python (I am very bad at it; a newbie)) based tool for it, in that article. Also, maybe the very powerful amount of options that exiftool command line provides with, might be enough to consider all cases without any coding. And/or do a bat file with several command calls, etc.

- Something I forgot to mention: You can use exiftool as many times you want over a JPG, it does not make it loose quality, as it does not modify the pixels, just the file header , those text tags (we can set a tag very wrongly and wreck something, though).

- Being (usually) practical for these things, going for the simplest route, I'd just use a viewer/editor that would play nicely with APhoto, maybe IrfanView (btw, it can read metadata, exif data), or more in  the category of Faststone, and also free for personal use, XNViewMP (which is good as a catalog viewer, and I think also handles metadata well), ...whichever does not cause the rotation problem with linked files.

But as I see you are very resourceful, I know you will generate the best possible workflow. It'd be interesting to know how it ends, though.   

 

I'm an absolute ignorant about this whole thing (and photography,  in general), I only know stuff that I needed to learn for solving some specific issues, but that's it, but I am glad if I helped.  
 

[Granddaddy]

I think the iPhone is tagging the photo correctly and that Faststone Image Viewer is handling the Exif information and displaying the photo correctly.

The problem I reported occurs because APhoto2 fails to read updated Exif tags when the external linked resource is edited and saved. APhoto2 continues to use the Exif data that was in the linked resource before it was edited, i.e., the Exif data in the image as it was when first placed in the document. This is an APhoto2 bug. It can be worked around easily. For instance, open the external portrait-oriented file for editing in APhoto2, export it without editing (which will reset the orientation tag and dimensions as I described above, then place that exported file as a linked resource in the collage you are building. Any future edits to that exported image file will not affect the orientation tag. APhoto should then update the placed image correctly because the orientation tag will not have been changed between the original placement of the image and subsequent editing of that image.

I hope I've written that correctly and clearly. It can be more confusing to describe the process while being very easy to do the process.

I guess we could debate whether Faststone should alter the Exif tags when saving the portrait image; but, since APhoto2 does the exact same thing, I have to assume that is some sort of standard industry procedure for handling portrait images from digital cameras. I haven't checked to see what XnView MP does with portrait images from digital cameras. 

As for standard industry procedures, one has to wonder whether there really are standards. Decades ago I heard someone say that he would write a standard user interface if you could show him a standard user. Many standards seem to exist for the purpose of being violated by big companies for their own purposes.

[SrPx]

I am not sure yet if it is Photo2's fault, as I know by experience that some apps don't write formats and standards stuff in  the expected way, so it could be that the tags don't come in the proper format or etc. I mean, I just am not sure. But very easily could be as well that when fast updating the link it's not reading such tag.

I wonder if you could use Photo's batch processing in file menu, to automate the opening of all your files (it lets you add multiple files with shift and ctrl keys) and saving them as tiff/psd, for example, so to do that workaround you mentioned with a single touch of a button, instead of one by one, whatever the number of the pics (well, probably it has a limit of files you can add, to perform well, I suppose). Also, it lets you, similar than in Photoshop, to have a macro ("Action" in Photoshop) applied to all batch of images. One of the default ones added there being "strip metadata". Not recommended for many cases, but stripping metadata for a personal collage might be fine, as anyway it all ends up as another big image. You can also (I guess) apply there a custom made macro you recorded (I just read only the beta allows to include 'place' as a part of the macro (but you can use copy/paste), but this is not needed in your workaround. Just in case you planned it for another workflow). The macro does not allow to record several things yet, so must be aware of it. Still, once knowing the limitations, I think can be extremely useful, specially combined with File/batch processing  (it is in Photoshop).

Photo has since long a panel/studio for metadata. I don't find many options there, but you can change some stuff. I prefer using Exiftool for that, but it's handy  that it's there.

And  yeah, standards... It is very rare to find one working in all applications, and can't remember a single app, 3D or 2D, where all the formats' i/o is working always smoothly.  The worst is when one application holding a monopolistic position uses its native format to keep it  that way. We have seen this in 2D and 3D software. Although, to be fair, some things are simply not portable to other apps as depend totally on the internal structure of the software. 

 

[SrPx]

From a post I just read, if using the batch processing feature, and having problems (infinite loop or sth), un-check  'parallel processing' on the bottom left corner of the batch processing window. Surely won't happen to you as you have an intel CPU, but in case you have a laptop or other PC with an AMD processor as it "could" happen the issue (perhaps it won't even being an AMD).

[Dan C]

Hi @Granddaddy,

Thanks for your report and our sincerest apologies for the delayed response here. We are exceptionally busy following the release of V2 and we thank you for your continued patience and understanding here.

I've been testing this here with sample images (https://www.galloway.me.uk/2012/01/uiimageorientation-exif-orientation-sample-images/) and thus far I've been unable to replicate this issue - are you able to provide a copy of the image file and perhaps an .afphoto document also, so that I can further test this here?

Many thanks in advance!

[Granddaddy]

Thanks @Dan C for your reply. Here are some screen captures showing the problem. Follow my original post from December 15, 2022,  to reproduce it using the file Flower.jpg as it came out of my iPhone 13. I hope the forum software doesn't mess with Flower.jpg. Just in case, I'm also uploading Flower.zip. 

Flower.jpg - original, unretouched file from my iPhone 13 taken in portrait mode. 

Flower.zip - ZIP file produced by Windows 10 containing Flower.jpg.

Collage.afphoto - APhoto2 (2.0.3) file created by dragging and dropping Flower.jpg into a new afphoto file as described in my original post. 

1-LinkedImagePlaced.jpg - Screen capture of APhoto2 window after placing Flower.jpg into the blank document. Resource Manger shows the image is linked (not embedded).

2-LinkedImageModifiedExternalEditor.jpg - Screen capture of APhoto2 window after using Faststone Image Viewer to modify brightness and contrast in Flower.jpg and saving it with those changes. Note that APhoto2 recognizes the external linked file has been modified. There was also a warning pop-up appearing in APhoto2 when that change was made to Flower.jpg by Faststone. So far everything is working as it should.

3-LinkedImageUpdated.jpg - Screen capture of APhoto2 window after clicking Update button in Resource Manager. Notice that the image has been rotated 90 degrees in APhoto2. 

On December 16, 2022, I provided an exhaustive description and analysis of what is happening and what I think APhoto2 is doing wrong when it updates an image modified by an external editor.

As mentioned above, APhoto1 behaves differently. Simply dragging Flower.jpg into a new APhoto1 document results in the image being presented in landscape format.  It appears that APhoto1 ignores the orientation tag.

APhoto2 does regard the orientation tag during the initial placement of the image. However, it appears that APhoto2 ignores the Orientation tag in the EXIF information after the jpg file is modified by an external program and updated in Resource Manager.

Also as noted above, my other image viewers display the file correctly both before and after modification.

Collage.afphoto Flower.zip

[Dan C]

Many thanks for your files and exhaustive description provided, this is certainly helpful!

I've been able to replicate this issue when editing the JPEG file in multiple apps externally, including directly within Affinity and then updating the resource, which results in resetting the EXIF rotation - so I'll be logging this as a bug with our team now

[Granddaddy]

Thanks @Dan C for verifying this bug. I had fun working through it.