PNGs with app1 profile persist data to converted JPG but don't appear to be exposed on MagickImage properties

[etihwddot]

Magick.NET version

14.2

Environment (Operating system, version and so on)

Windows

Description

We have a couple of user PNG images that appear to have density metadata that is persisted when converting to a JPG but isn't loaded when opening the image initially.

The MagickImage initially loads the PNG with Undefined Density but then converts to 300dpi after changing the format to JPG.

I'm not familiar enough with how profiles should or shouldn't be interpreted to know the correct behavior here but it was a little surprising that it was treated differently. For us this causes one situation to render the image at 96dpi and the other to render it at 300dpi in an XPS document thus rendering ~3x smaller than expected.

This does not appear to be a regression from previous versions.

Steps to Reproduce

The following output is from the sample PNG and output code.

0x0
300x300 inch

using var image = new MagickImage(inputFile);
Console.WriteLine(image.Density.ToString());
image.Format = MagickFormat.Jpg;
var bytes = image.ToByteArray();
using var reloadedImage = new MagickImage(bytes);
Console.WriteLine(reloadedImage.Density.ToString());

Image is all red pixels to remove user data.

[dlemstra]

It looks like you are finding all the edge cases 😁The issue here is that the input image contains an app1 profile. And this will be stored in the jpeg image when you encode it. But that jpeg decoder does something extra and checks if the profile starts with an exif header and then treats it as an exif profile. I will need to think about how and if we should patch this. I will get back to this issue once I have more info.

[etihwddot]

Appreciate the confirmation of what I'm seeing. Agree that I don't know how or if you should patch it.

One thought I had was maybe giving API consumers the ability to peek into the app1 data if it has an exif profile. Knowing very little about app1 profiles I did try to load it as an ExifProfile and even as a TIFF image using MagickImage as a way to see if I could determine if it has data that we want to strip prior to the conversion. Neither idea worked and I didn't spend any time trying other ideas.

Example Code

using var image = new MagickImage(inputFile);
var profile = image.GetProfile("app1");
	
var exifProfile = new ExifProfile(profile.ToByteArray());	// appears to create an empty profile

using var tiffImageHeader = new MagickImage();
tiffImageHeader.Ping(profile.ToByteArray()); // fails to load with TIFF directory is missing required "ImageLength" field. `MissingRequired' @ error/tiff.c/TIFFErrors/592

[dlemstra]

That will not create an empty profile? This unit tests passes:

using var image = new MagickImage(inputFile);
var profile = image.GetProfile("app1");

Assert.NotNull(profile);
var data = new ExifProfile(profile.ToByteArray());
Assert.Equal(10974, data.ToByteArray().Length);

[etihwddot]

Sorry, what I meant by empty profile was the data doesn't appear to have any values.

vs what I typically see when calling GetExifProfile on an image that has data.

[dlemstra]

I am getting this result with my local development build that has a patch to make sure the exif profile is found when reading the png file:

using var image = new MagickImage(inputFile);
var profile = image.GetExifProfile();
Assert.NotNull(profile);
Assert.Equal(11, profile.Values.Count);

This will be fixed in the next release.