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:

1. fix(png): round dpi resolution to nearest 0.1 #4347 Addresses weird roundoff issue in dpi pitch. Not sure why relevant, but you never know.

2. feat(jpeg): output hint "jpeg:iptc" #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!

Here's a.jpg, which PS likes, and aa.jpg, which it does not.

@lgritz I was building the latest version of OpenImageIO and remembered this issue. I did some more digging and it turns out the source of the problem is the IPTC:OriginatingProgram metadata that oiiotool adds. After deleting that metadata Photoshop open the image without complaint.

Aha! That was just the clue I needed!

I had assumed that all the fields described by the IPTC spec that were of type "string" could be... you know... any length. Because there's no excuse for a computer to impose any particular limitation. But it had escaped my notice that the IPTC spec gives maximum lengths for the different string fields, and this one is 32 chars. Ugh.

OK, now I feel like I have a handle on how to fix this. Thanks for following up. Stay tuned.

Fix proposed in #4568