Open BrianHanke opened 4 months ago
Is this a recent change, or has it always been like this? Do you know which versions of OIIO exhibit the problem? And do you know which metadata specifically seems to be damaged?
I've noticed it for a little while, a few months, but can't say if it's a problem going back many versions. I'm using OpenImageIO 2.5.11.0 and Photoshop 24.7.4.
Here's the --info output for a problematic oiiotool JPG and the same file exported from Affinity which PS is fine with. I notice a few differences in the metadata they share, but not sure which ones might be significant:
C:\Users\Brian\Desktop\oiiotool.jpg : 1284 x 901, 3 channel, uint8 jpeg
channel list: R, G, B
ResolutionUnit: "none"
Software: "OpenImageIO 2.5.11.0 : oiiotool.exe C:/Users/Brian/Desktop/el_greco_study.png -o C:\\Users\\Brian\\Desktop\\oiiotool.jpg"
XResolution: 96
YResolution: 96
Exif:ColorSpace: 1
Exif:ExifVersion: "0230"
Exif:FlashPixVersion: "0100"
Exif:ImageHistory: "oiiotool.exe C:/Users/Brian/Desktop/el_greco_study.png -o C:\\Users\\Brian\\Desktop\\oiiotool.jpg"
IPTC:OriginatingProgram: "OpenImageIO 2.5.11.0 : oiiotool.exe C:/Users/Brian/Desktop/el_greco_study.png -o C:\\Users\\Brian\\Desktop\\oiiotool.jpg"
jpeg:subsampling: "4:2:0"
oiio:ColorSpace: "sRGB"
PS C:\Users\Brian> oiiotool --info -v C:\Users\Brian\Desktop\affinity.jpg
Reading C:\Users\Brian\Desktop\affinity.jpg
C:\Users\Brian\Desktop\affinity.jpg : 1284 x 901, 3 channel, uint8 jpeg
channel list: R, G, B
DateTime: "2024:07:14 22:40:45"
ICCProfile: 0, 0, 2, 84, 108, 99, 109, 115, 4, 48, 0, 0, 109, 110, 116, 114, ... [596 x uint8]
ResolutionUnit: "in"
XResolution: 96
YResolution: 96
Exif:ColorSpace: 1
Exif:PixelXDimension: 1284
Exif:PixelYDimension: 901
ICCProfile:attributes: "Reflective, Glossy, Positive, Color"
ICCProfile:cmm_type: 1818455411
ICCProfile:color_space: "RGB"
ICCProfile:copyright: "No copyright, use freely"
ICCProfile:creation_date: "2024:07:15 02:40:16"
ICCProfile:creator_signature: "6c636d73"
ICCProfile:device_class: "Display device profile"
ICCProfile:flags: "Not Embedded, Independent"
ICCProfile:manufacturer: "0"
ICCProfile:model: "0"
ICCProfile:platform_signature: "Microsoft Corporation"
ICCProfile:profile_connection_space: "XYZ"
ICCProfile:profile_description: "sRGB IEC61966-2.1"
ICCProfile:profile_size: 596
ICCProfile:profile_version: "4.3.0"
ICCProfile:rendering_intent: "Perceptual"
IPTC:MetadataDate: "2024-07-14T22:40:45-04:00"
IPTC:ModifyDate: "2024-07-14T22:40:45-04:00"
jpeg:subsampling: "4:4:4"
oiio:ColorSpace: "sRGB"
photoshop:ColorMode: 3
photoshop:ICCProfile: "sRGB IEC61966-2.1"
stEvt:action: "produced"
stEvt:softwareAgent: "Affinity Photo 2 2.5.3"
stEvt:when: "2024-07-14T22:40:45-04:00"
Did a little more testing. The Photoshop issue arises when converting a PNG to JPG using oiiotool.
For example, with oiiotool A.png -o B.jpg
PS doesn't like B.jpg.
But if I reprocess the file with oiiotool B.jpg -o C.jpg
then PS is fine with C.jpg. Interestingly, C.jpg is 589 bytes smaller than B.jpg.
I don't suppose you could send me the three files A.png, B.jpg, C.jpg so I can directly compare them to understand what's being added or deleted?
You can send directly to me privately if there's any issue with not being able to make them public. (Or, alternately, if you can reproduce the problem with black images or something else that has no IP issues, that's fine, too.)
Sure, it's just a random El Greco painting ref on had on my desktop. 🙂 Files are attached.
I'm on vacation with little internet connectivity, but I looked at those files (B.jpg and C.jpg) and there is almost no difference! I only spotted two things, not sure why either one would be a problem for photoshop, but I just posted two PRs related to them that maybe you could try on your end and see if either helps:
https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4347 Addresses weird roundoff issue in dpi pitch. Not sure why relevant, but you never know.
https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4346 This gives the jpeg writer an optional hint to direct it not to output the IPTC block. So in that case, you might try applying it like:
oiiotool A.png -attrib jpeg:iptc 0 -o B.jpg
If you can possibly apply these patches one by one on your end and give a spin, letting me know if either one helps the problem, that might give me a clue about what to try next.
Thanks! I'll test these out next week and let you know the results.
Great, let me know how it goes. I don't necessarily have a lot of confidence that it'll fix it, but they address the only two obvious things I saw different about B and C, so maybe that will help?
Well, I feel like I'm losing my mind here! I tried the patches, but no change. However, in the process I did discover that it seems to matter how many characters are in the filename. Converting to a.jpg, bad, aa.jpg, good, aaa.jpg bad, aaaa.jpg good.
I've been using an older version of Photoshop to avoid the AI stuff, but I did install the latest one today to test. It has the same problem. I attached a video showing what's happening. Bizarre!
https://github.com/user-attachments/assets/e09fa510-435d-4d66-9cc2-47dbd697e1ee
Here's a.jpg, which PS likes, and aa.jpg, which it does not.
I first noticed this issue using Gaffer and since Gaffer uses OIIO for image writing I checked oiiotool and found the same behavior. What happens is that Photoshop objects to JPGs exported with oiiotool: "This document contains Adobe Photoshop data which appears to be damaged." You can just go ahead and click OK and it opens fine. Affinity Photo or any other picture viewer are fine too, so this is mostly just about the inconvenience of having to click the warning in PS. Is there a workaround, maybe an oiiotool parameter? Thanks!