I reproduce the issue with version 13.0.0 on Windows 10 x64.
Apparently, the issue arises due to a non-default value of ImageResolution option of img:
Options[img, ImageResolution]
{ImageResolution -> {96., 96.}}
Setting this option to Automatic:
Show[Image[img, ImageResolution -> Automatic], Axes -> True]
Options[%, PlotRange]
{PlotRange -> {{0, 709.}, {0, 251.}}}
According to "Details" section of the Documentation page for ImageResolution,
The default setting ImageResolution->Automatic typically uses a resolution of 72 dpi for bitmap graphics formats.
Let us check:
Show[Image[img, ImageResolution -> {72, 72}], Axes -> True]
Options[%, PlotRange]
{PlotRange -> {{0, 709.}, {0, 251.}}}
We have got exactly the same data inside of the Graphics object. The only exception is that inside of Raster now we have explicit value of the ImageResolution option (which isn't a documented option for Raster!):
Show[Image[img, ImageResolution -> {72, 72}], Axes -> True] //
ResourceFunction["ShortInputForm"]
But for what this options is kept inside of Raster? Let us check how the backward conversion to Image works:
Show[Image[img, ImageResolution -> {72, 72}], Axes -> True] // First // Image // Options
{ColorSpace -> "RGB", ImageResolution -> {72, 72}, Interleaving -> True}
We see that the backward conversion algorithm uses this option and sets it for produced Image object.
The same happens for the original img:
Show[img] // First // Image // Options
{ColorSpace -> "RGB", ImageResolution -> {96., 96.}, Interleaving -> True}
Hence what you have found seems to be an undocumented feature of the Image to Graphics conversion algorithm. Whether this behavior is justified, I'm not sure.
As you show, this feature results in inconsistency when combining the results of image-processing functions like ComponentMeasurements with Graphics obtained by the above conversion method:
cm = ComponentMeasurements[Binarize[img], {"BoundingDiskCenter", "BoundingDiskRadius"}];
Show[img, Graphics[{Red, Circle @@@ Values[cm]}]]
This inconsistency is worth reporting to Wolfram. The above-described feature (I mean exactly PlotRange change upon ImageResolution change) is completely unnecessary for both Image to Graphics and Raster to Image conversion algorithms. I'm not sure for what it is introduced at all. In any case, worth reporting to Wolfram.
But notice that high-level HighlightImage doesn't have this feature:
hi = HighlightImage[img, Graphics[{Red, Circle @@@ Values[cm]}]]
Options[hi, {PlotRange, ImageSize, ImageSizeRaw}]
{PlotRange -> {{0, 709}, {0, 251}}, ImageSize -> {222., Automatic},
ImageSizeRaw -> {531.75, 188.25}}
Image[hi] // Options
{ColorSpace -> "RGB", ImageResolution -> 96., Interleaving -> True}
As we see, HighlightImage not only correctly understands img coordinates, but also sets the option ImageSizeRaw for produced Graphics object. This option may be used later when converting the result back into Image for computing the original ImageResolution. Here is how it can be used:
ImageResolution -> (72 *#[[1, All, 2]]/#[[2]]) &@
Values[Options[hi, {PlotRange, ImageSizeRaw}]]
ImageResolution -> {96., 96.}
(But currently, it isn't used and ImageResolution is taken directly from the Image embedded in produced Graphics as Inset! Notice also that the original ImageSize is lost when converting backward to Image!)
From these considerations we find another workaround:
HighlightImage[img, {}, Axes -> True]
Options[%, {PlotRange, ImageSize, ImageSizeRaw}]
{PlotRange -> {{0, 709}, {0, 251}}, ImageSize -> {222., Automatic},
ImageSizeRaw -> {531.75, 188.25}}
But again, I don't think that this justifies the PlotRange change when converting an Image with non-default ImageResolution into a Graphics object using Show. I see no reason for this feature. Even HighlightImage doesn't change PlotRange, which seems more consistent than the current behavior of Show.
I've wrote a suggestion for improvement on this issue to the support [CASE:4896512]. Here is the response:
From your description, I gather you are noticing a regression with
PlotRange getting changed per ImageResolution specifications for
Image.
I checked and reproduced your issue, and have passed along a report to
our developers on the same. We are always interested in improving
Mathematica and wish to thank you for bringing this issue to our
attention.
If you run into any other unexpected behavior with Mathematica, please
do not hesitate to contact us in the future.
Hence the Wolfram support identifies this issue as a regression bug (I hadn't used such a term in my report).
