How does WordPress or plugin determine PPI resolution of uploaded image?

It’s a lot of questions, and I am a bit busy at the moment, so I will just to give you a minimum of answers… from my point of view, and with my limited knowledge ??

1) How does WordPress (and/or Perfect Image or other similar plugins) determine whether an uploaded image is already @2x or @3x?

It doesn’t, there is no Retina support in WordPress. Only my plugin does it. They just added a “Medium Large Image” size to try to add more images in the src-set in case it helps. Strange decision.

a) Does it expect a signifier in the filename?

My plugin uses the @2x suffix, which is pretty the standard (it was decided by Apple, when they updated their website to Retina, a few years ago).

b) Does it inspect the PPI info in the PNG metadata header?

For a screen, only the resolution matters. The browser knows the screen, and its PPI, and depending on that, will pick the best image available for it in the srcset. Feed the srcset with the right images, and the browser will do the rest. This plugin allows you to choose which image sizes you want (or do not want), and which retina sizes you would like to add on top of it.

a) Can it perform the auto-generation in a RELATIVE manner? By relative I mean if it detects the upload to be a @3x, it only creates a @2x @1x of that same version. So only a resolution-reduction at full multiples. Not scaling to some fixed pixel-width tiers.

Have a look here: https://meowapps.com/wp-retina-2x/. Basically, it takes the image you upload, WordPress creates the sizes (which are also controlled by this plugin), then this plugin creates the retina sizes.

The Pro Version allows something a bit different, a different way to upload, with Full Size retina support. You can upload a @2x file directly (no need to respect the extension convention, the plugin will rename everything the right way). From this @2x file, the full-size image (which will be half) will be created. That way, you have a @2x version of the full-size (so that gives you absolute control on it).

Don’t think about @3x, @4x and so on, you don’t need; first, there are no screens which are strictly x2 or x3, they are 1.4, 1.8, 2.8, it all depends. The idea is just to have enough sizes in your srcset that will fit a factor of 2.

Thanks that you took the time to answer this! My evaluation how I plan to deal with responsive images is still in motion. Will answer back to you when those thoughts cleared and when I can followup clearly. Thank you!

Ok. Meanwhile I learned more on the subject and also conducted intensive testings, and can therefore hopefully better articulate myself:

Findings & Facts

1. Perfect Images allows you to manage WordPress image sizes: Add more, remove default ones.
2. If you choose the default delivery method “Responsive Images” then what it does is just that the srcset contains your “Retina Sizes” too in the srcset catalog. But you could just as well create that special “Retina Sizes” as regular sizes by manually calculating the dimensions accordingly. So this is just a convenience extra. But something that you can achieve with any plugin that allows you to manage the image sizes.
3. You image appears with the CSS pixel dimensions that the width and height attributes of the IMG tag have.
   Block Editor (Gutenberg) > Select Image > Inspector:
   a) Image Size: Full Size, Medium, Thumbnail, and possible further similar names. These are the names of your image sizes as defined for your media library. The one you choose here determines the maximum size offered in the srcset. (Can be used as a rudimentary method to protect higher resolution image variants for a particular image)
   b) Image Dimensions: Either directly edit the pixel values in Width or Height or click the percentage buttons 25% 50% 75% 100% in the segmented control below, which in effect then set the pixel values. Note: The percent sets nothing in the markup at all! Nor is it linked to the pixel values during the Gutenberg session. It’s a oneshot action. A convenience auxilliary function only. Just that no-one is confused about it.
   c) You may have some other means that influence the CSS dimensions, such as a column/flexbox/css-grid wrappers around it or a CSS theme override. But what’s set in the HTML attributes Width and Height is what the browser starts for its layout calculation on page load (long before the images are really fetched). This are the base fallback values, kinda crucial.
4. With the “Responsive Image” delivery method, the web browser alone decides which src from the srcset it fetches. It can do it as it wants, and browser implementations vary (I studied it in detail, to which events they react, and what they consider as “density saturated”), but basically: I want to fill X CSS pixels and want to saturate my hardware display resolutions (as the OS tells me about the HW). If the image width in the srcset does not saturate anymore, take the next higher one.

Considerations & Practise

3 & 4 is totally agnostic of a screenshot or screen design at a certain resolution. If you want that you as the creator have to handle that yourself. Neither Perfect Images nor Gutenberg has a mechanism to support you with this.

You drop in a source image. By default WordPress Gutenberg editor takes 1 source pixel as 1 CSS pixel. If you know your source image is @1x then you leave this as-is. If you know your source image is @2x then you use the 50% button. WidthCSS = WidthSource * 0.5. With the Responsive Images delivery method on @2x screens the web browser will fetch that original @2x. On screens lower it will load the next lower version. But that will unlikely be exactly an @1x version of it which is exactly half the width of the uploaded @2x version. It will take the next nearest width available in the srcset. And that srcset is constructed in the fixed image size tiers (absolute widths, height resized with original aspect ratio). Not in image dimension multiples!

Image Resizing in full multiples — A feature to support high resolution screenshots / screendesigns being displayed “true to size”

Could Perfect images introduce this totally new (and independent additional system) of image sizes? The process would be like this:

1. You define your relative image sizes catalog :
   1 | @1x in filename or 72 PPI or undefined resolution in image metadata header
   1.5 | @1.5x in filename or 108 PPI in image metadata header, not valid for upload, only for server side size creations.
   2 | @2x in filename or 144 PPI in image metadata header
   3 | @3x in filename or 200-220 PPI in image metadata header
   4 | @4x in filename or 288-300 PPI in Exif metadata header
   
   You can also define what signal is stronger in case of contradicttions among the allowed signals, e.g. “filename or metadata” or “which metadata tag is stronger (e.g PNG-PhYS vs. Exif)” globally for the whole catalog and/or individually per relative size in the catalog.
   
2. You upload an image which signals to the CMS “I have this/that screen resolution” (in the filename or image metadata).
3. The plugin does this:
   a) Sets the initial Width and Height attributes accordingly, with which your WYSIWYG block editor works with.
   b) Backend creates the relative sized images. Relative means: It does not resize into WordPress fixed size buckets of image widths (maintaining the original aspect ratio ofc). But it resizes strictly to the multiples.
   – With our given catalog from step #1: If an image gets uploaded @3x, then @2x @1.5x and @1x get created automatically. No @4x as no upscaling is performed.
   c) In the srcset deliver put the concrete pixel widths that the resizing of THIS particular image yielded? With our given catalog from step #1: When uploading an image tagged as @4x which has a width of 2000 source pixels: Step 2 would insert is as 500 CSS pixels wide (@1x is the CSS standard). The srcset would be: 500w, 750w, 1000w, 1500w, 2000w. A @2x screen device would pick the 1000w image (half of the original @4x) for rendering. When zooming in via trackpad it would possibly fetch the next higher version. These relative sizes will almost never be aligned with WordPress “absolute pixels widths image buckets”.

The use case is “true to size” presentation of screenshots, screen designs, etc.

For my project at hand it is too late to wait for this feature.

I will simply achieve it by utilizing the percentual buttons in Gutenberg. Not much effort.

And I will not have full multiples (which would have the least interpolation and thus ideally for pixel art presentation, very crisp, exact representation) but I will live with that.

But I wanted to at least outline the ideal scenario. And show you a potential market niche. Maybe you want to offer or experiment with that feature.

Image Resizing in full multiples?> 3c)

In the?srcset it puts the concrete pixel widths that the resizing of THIS particular image yielded.