[Added] Ability to save 72 PPI into PNG file vs explicitly stripping PPI info (PNG-pHYs value)

[porg]

Status Quo of PNG-pHYs

Changing the resolution in the editor (Menu > Picture > Resolution) or via batch (named "Resolution") to exactly 72 PPI does not save the PPI as 72 into the PNG's resolution attribute "PNG-pHYs" but instead strips the "PNG-pHYs" altogether.

This is ok for most use cases, where this is synonymous.

But in a current use case I really want to differentiate images as "This is explicitly a 72 PPI image" (PNG-pHYs = 72 PPI) vs. "This image has no PPI information" (no PNG-pHYs attribute found in file). Spotlight too differentiates that information in its "Resolution Height" and "Resolution Width" attributes as "72" vs "--" (no information found).

Proposal

The dialog and the batch get this hint:

Hint: Changing to the special value of 0 PPI removes the respective resolution attribute from the file altogether on save.
Upon next opening it will be treated with the default fallback resolution (72 PPI usually).
Setting a resolution value to 72 PPI explicitly sets the resolution value to 72 PPI in the file metadata.

And both dialog and batch do exactly what that hint explains.

I'd appreciate feature parity in "Resolution" via menu dialog vs. batch action
1) The batch action "Resolution" only supports integer numbers whereas Menu > Picture > Resolution allows decimal numbers too.
- Both should accepting decimal numbers
2) And ideally also allowing you to select the unit (inch, mm, cm, m)
- Because the unit it is eventually stored to may differ. And some rounding may inadvertently occur, and if you need to get to an exact number per unit, it would be fine if you could specify it as such, and not fall victim to a rounding problem, which avoids you getting your exactly needed outcome number.
- EXIF ResolutionUnit can be in inches or cm
- JFIF untis for Xdensity / Ydensity can be inches or cm
- PNG-pHYs is either relative (aspect ratio of pixels) or if absolute it only supports pixels per meter.
(Yes finally a metric system victory! Imperial units suck. That be said. )
3) The menu dialog has a "unified" option (both X and Y resolution). Batch should have that too. Is convenient to not need to enter the same number twice.

Resolution gets written to both PNG-pHYs and to Exif's XResolution and YResolution

Opened file "Monaco 16pt @4x original created in Snagit.png"

---- IFD0 ----
X Resolution: 288
Y Resolution: 288
Resolution Unit: inches
---- ExifIFD ----
Exif Image Width: 416
Exif Image Height: 64
---- PNG-pHYs ----
Pixels Per Unit X: 11339
Pixels Per Unit Y: 11339
Pixel Units: meters

288 PPI / 2.54 inToCm * 100 cmToM = 11339 PPM

Duplicated filed in Finder and then opened in GC nd edited resolution to 123.56 PPi and saved it appropriately as:
Monaco 16pt @4x dupe opened into editor and then changed resolution to 123.56 PPI saved with Exif.png

---- IFD0 ----
X Resolution: 123.45
Y Resolution: 123.45
Resolution Unit: inches
---- ExifIFD ----
Exif Image Width: 416
Exif Image Height: 64
---- PNG-pHYs ----
Pixels Per Unit X: 4860
Pixels Per Unit Y: 4860
Pixel Units: meters

123.45 PPI / 2.54 inToCm * 100 cmToM = 4860 PPM

Resolution gets written to PNG-pHYs and to Exif's XResolution and YResolution BUT only if a file had an Exif header before editing

If a batch contains step "Remove Metadata" with XMP, Exif, COM, ICC all selected for removal and later step "Resolution" and the file format is PNG with file options "Metadata" and "Exif" activated then resolution information is nevertheless only written to PNG-pHYs. And there you have the problem of getting the PNG-pHYs stripped if PPI = 72 (described above).

If you disable "Remove Metadata" but keep the rest of the batch and also the file options the same then the resolution information is written to PNG-pHYs (specified in pixels per meter) and also to the EXIF group "IFD0" the parameters "X Resolution" and "Y Resolution" get written with the "Resolution Unit" specified in "pixels per inch".

So the activating of "Store EXIF" in the file format options alone seems to not add an EXIF header. These file format options seem to only work in a reductive fashion, but not in an additive fashion, or only in a minimally additive fashion at most. If EXIF is selected and the image gets some attributes during the batch which could qualify to be stored in EXIF too, no EXIF header gets created freshly and newly qualifying attributes written there. Having EXIF active only results in EXIF being written out if the file had some EXIF attributes prior and no action step removed EXIF altogether. Then the attribute gets changed (or possibly even added? if at least some intact EXIF was there in the beginning?).

GraphicConverter supports to store resolution info for WebP files in the EXIF chunk of the RIFF container that WebP uses

- I added that info to https://en.wikipedia.org/wiki/Pixel_den ... at_support under WebP
- Mostly handled correctly except little display bug: Resolution of WEBP files shows correctly in Editor & Browser. But not in column of Browser's List View.
- macOS 11 Big Sur's Spotlight Importer for WebP does not yet parse the resolution info in the EXIF chunk of the WebP files (see HoudahSpot screenshot below). Does Spotlight in your current macOS already parse kMDItemResolutionWidthDPI kMDItemResolutionHeightDPI for WEBP files? Just mdls the file fo find out please.

Conducted Experiments

- Files sent to you via email
- Screenshots of batch (in GraphicConverter) and outcome (in Finder and in HoudahSpot where you can display arbitrary Spotlight columns):

GraphicConverter Resolution Metadata Experiments.png (604.21 KiB) Viewed 1796 times

GraphicConverter Resolution Metadata in Finder.png (147.35 KiB) Viewed 1796 times

GraphicConverter Resolution Metadata in HoudahSpot.png (181.17 KiB) Viewed 1796 times

[forum_adm]

I added now an option for storing the resolution (pHYs tag):

Screenshot 2022-11-23 at 10.08.jpg (181.74 KiB) Viewed 1790 times

[porg]

I added now an option for storing the resolution (pHYs tag):

Tried build 5671, sent you my resulting files via email for inspection if needed.

Reproduction, all use cases seem to work fine:

1) Duplicated file in Finder which has 288 PPI in Exif and the corresponding 11339 PPM in PNG-pHYs and changed filename to reflects the desired outcome. The file will be opened and then manipulated and overwritten in steps 2 + 3, which I varied.

234.56 PPI to PNG-pHYs
2) PNG file format options: [√] Resolution
3) Menu > Picture > Resolution > Changed uniformly to 234.56 PPI
Saved file has resolution in PNG-pHYs (shown in GC as 234.57 PPI due to rounding as technically stored in PNG-pHYs as 9235 PPM).
File has no Exif at all.

345.67 PPI to PNG-pHYs and Exif
2) PNG file format options: [√] Resolution [√] Exif
3) Menu > Picture > Resolution > Changed uniformly to 345.67 PPI
Saved file then has resolution both in Exif (exactly as 345.67 in ResolutionUnit PPI) and PNG-pHYs (13609 PPM)

To 72 PPI and Metadata None
2) PNG file format options: None ticked
3) Menu > Picture > Resolution > Changed uniformly to 72 PPI
Saved file has no resolution at all. This is correct as neither PNG-pHYs nor Exif were ticked.

To 72 PPI and Exif
2) PNG file format options: [√] Exif
3) Menu > Picture > Resolution > Changed uniformly to 72 PPI
Saved file has resolution in Exif (exactly as 72 in ResolutionUnit PPI).

To 72 PPI and PNG-pHYs
2) PNG file format options: [√] Resolution
3) Menu > Picture > Resolution > Changed uniformly to 72 PPI
Saved file then has resolution in PNG-pHYs as 2835 PPM. Check: 2835 PPM * 2.54 / 100 = 72.01 PPI.
Update Note: I earlier warned here that this value is wrong and maybe a leftover from an outdated variable in GC.
Rather it was an outdated value from my math calculation, which I did not refresh. Sorry for the false alarm!

To 72 PPI and PNG-pHYs and Exif
2) PNG file format options: [√] Resolution [√] Exif
3) Menu > Picture > Resolution > Changed uniformly to 72 PPI
Saved file then has resolution in PNG-pHYs and Exif
Exif resolution correctly is 72 PPM
PNG-pHYs correctly is 2835 PPM
Update Note: Earlier had a false bug report here! Was my miscalculation

For clarity please improve label and subtext like this
The described behavior is what I conducted from my testing. The bug put aside for now.

Code: Select all

[√] Store resolution in PNG specific attribute PNG-pHYs
     Note: Independent from this setting, if Exif is checked ON,
           resolution will be stored in Exif's respective tags
           XResolution, YResolution, ResolutionUnit.

[porg]

What about my other more general proposals regarding resolution info in image file metadata?
1) Need for differentiation "this file has 72 PPI" vs "This file's PPi is unknown/unspecified"
a) Your new option "Store resolution in PNG specific attribute PNG-pHYs" solved this for PNG-pHYs.
a) "Store PNG-pHYs" ON --> Stores PPI, also if 72 PPI (in dialog and batch)
with the proposed solution setting special value 0 PPI in dialog or batch strips respective PPI atttribute(s) (Xresolution and/or Yresolution and/or ResolutionUnit) from the respective resolution metadata (in Exif AND the file format specific attribute).
2) Achieving feature parity between dialog and batch action.
3) Possibility for user to specify value in dimension unit of own choice

What about my research question:
4) Does your contemporary macOS 13 Ventura's Spotlight Importer already parse resolution info in Exif of WebP files?

[forum_adm]

Files without a valid resolution value always default to 72 ppi.

[forum_adm]

I can't reproduce the PNG saving issue.

I opened a file with 144 ppi.
Changed to 72 ppi.
Saved as PNG without XMP and Exif - only pHYs.
File shows 72 ppi.

What are your save settings?

Can I maybe get the source file?

[porg]

Files without a valid resolution value always default to 72 ppi.

• Yes in run time interpretation of course.
• But for storing there should be the possibility to "store as 72 PPI explicitly" vs "Store as unknown and strip resolution information" for other software or own scripting usage which differs on that basis.

I can't reproduce the PNG saving issue.

• Please respect my efforts by at least reading what I write.
• I don't write lengthy for fun, but to be as transparent as possible what steps are performed, which is sometimes complex.
• All that I did is EXACTLY described in the reproduction above. And I had sent you the resulting files via email.
• You should be able to get all information needed from this.

[porg]

Update: Added use case To 72 PPI and PNG-pHYs and Exif to the reproduction post and sent you the file via email.
Note between all these tests I did not quit GC. That's the reason why that incorrect value is still in memory and assigned.
If I quit and got right to 72 PPI I may get another result. I will also try this.

[porg]

False alarm. I had a calculation error. You can stop your investigation.

Will inform in detail here when confirmed

[porg]

Also tested the batch action "Resolution" now with the renewed PNG file format options.

1) Convert & Modify with a single file which has 288 PPI in Exif and the corresponding 11339 PPM in PNG-pHYs.
2) Batch always contains these steps:
a) Remove Metadata: {XMP, Exif, COM, ICC}
b) Resolution: Change X to 72 PPI and Y to 72 PPI, no resampling
c) Text Replacement (not relevant for testing, just for me to keep order)
3) Different PNG format options per each test run:
a) Metadata: None selected
Output file contains no resolution info in PNG-pHYs and has no Exif at all.
b) Metadata: Resolution
Output file has PNG-pHYs with 2835 PPM (which is approximately 72 PPI)
c) Metadata: Resolution + Exif
Output file has PNG-pHYs with 2835 PPM (which is approximately 72 PPI)
Output doesn't have any Exif at all. Hence also no resolution in Exif.
c) Metadata: Exif
Output file has no PNG-pHYs. Having it would be wrong.
Output doesn't have any Exif at all. Hence also no resolution in Exif.

So as I wrote earlier, removing Exif in a batch, and then manipulating values, and then having Exif ON in file format, does not re-create Exif and fills it with those values which are then known.

Ad 1) Differentiation "explicit 72 PPI" vs "unspecifed PPI" is totally satisfying in Editor and somehow satisfying in Batch now too:
• For PNGs certainly: I can strip EXIF and also ICC and only give it the minimal resolution tag.
• If you want both Exif and PNG-pHYs, then simply make sure to have no Exif Metadata removal step in your batch, and both will be set.
• More detailed Exif manipulation than "kill it all" is not possible in batch, see proposal point 5.

What about?
2) Achieving feature parity between dialog and batch action.
3) Possibility for user to specify value in dimension unit of own choice
4) Research question: Does your contemporary macOS 13 Ventura's Spotlight Importer already parse resolution info in Exif of WebP files?
5) More detailed Exif manipulation in batch.
• Approaches like "Nullify Exif, and then add only selected values" or "Delete Exif attributes X, Y, Z" or "Delete all Exif attributes but A, B, C" are possible to some degree in GraphicConverter's Editor via the dedicated metadata menu.
• But not in the Batch, where it would make sense! e.g. "Keep all but remove Location, Camera Serial Number" to share interesting harmless Exif on purpose but save privacy. Exif attribute wiping (all, all but) and attribute adding (x, y, z) would be great additions to the batch engine.