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 461 times
- GraphicConverter Resolution Metadata in Finder.png (147.35 KiB) Viewed 461 times
- GraphicConverter Resolution Metadata in HoudahSpot.png (181.17 KiB) Viewed 461 times
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).
Output doesn't have any Exif at all. Hence also no resolution in Exif.