Is the 200% scaling the OS setting?

If I had to guess, I'd say we consider this HighDPI, which means we double the size of everything, then the 200% doubles it again and you get 4x.

It's not clear to me that there is a bug here, as opposed to us trying to reflect the requested magnification settings.

Yes, the OS magnification is set to 200%. 
When setting the display resolution to FullHD (with 100% magnification) and repeating the steps I get the same result.
If this is the intended behavior, I don't quite understand the logic behind it in the HighDPI context.
If my screen is FullHD and the image is bigger than that, it makes sense to first show me the image fitted to screen, and if I press it, to show the real size of the image with scroll bars, pixel-to pixel, thus achieving maximum quality.
However, on a UHD screen, magnifying an image actually degrades the quality and creates unnecessary scroll bars.
Is it possible to change the Chrome behavior to not magnify the images?

I guess we could achieve this by setting the pixel density of the image == the DPR (so in this case the image viewer/ImageDocument would "pretend" that the image was 1920x1080 w/ a 200%=2x density.) Might be problematic when dimension % dpr != 0, but maybe that would be manageable somehow.

Transforming this into a feature request since it's not obvious there's a bug here, but things could arguably be improved.

I think you're right that we should go pixel-for-pixel on at least some setting, but it's a very ambiguous trade-off.

The HighDPI zoom factor that Chrome applies is to make content appear correctly sized, rather than tiny, on HighDPI screens. In turn, we disable other rendering enhancements that make low resolution screens appear higher resolution, such as sub-pixel text rendering (Windows ClearType). The result is better performance, sizing that meets expectations, yet high resolution.

For images embedded in other HTML content we must scale to maintain the correct relationship between the image and other content.

Only that breaks the feature you're looking for, which is pixel-for-pixel image rendering. Someone will look into this further - I agree we can do better and we certainly shouldn't be going 4x in your situation for an image URL.

Glad to hear that. I will just add my specific use-cases:

1. Reading comics online - images containing text. If Chrome receives an image with such a style: style="height: 3000px; width: 2068px; max-width: 1850px; max-height: 2684px; 
Does it upscale directly the initial image or does it respect the site layout and then upscales it?

2. Image boards: Usually show the images constrained, but  also have a "show original image" function, this case for example:
<img alt="" class="image" height="2673" id="image" large_height="2673" large_width="3803" src="" width="3803" style="display: inline;">
which leads to horizontal scroll bars in case of large images.

The way I interpreted this bug, was that it was about the "image viewer" (what you get when you navigate directly to an image resource - i.e enter its URL in the URL field.) There the constraints are somewhat relaxed, so we can do things like what described in c#5.

For "general content" though we will respect the site layout. "Upscaling" (or scaling in general really) will be based on the site layout. If the site sets width (or height) X and you have a DPR of > 1, then each pixel of an image will contribute to more than one "display pixel". There's no magic pixie dust needed to access this information (the DPR) though, so a site could choose to compute an appropriate size based on it.

You're right of course. If the browser could read the developers' mind, it would be easy, and as I am not a developer, I cannot be sure of what is possible and what is not.
As an example, I could suggest that if the image size is not constrained by the website, like my second point, and the resulting page is more than twice the width of the screen, showing the image pixel-to-pixel would fill the screen and look better, but, again, I don't know if this makes sense.

If we were to do that, we would violate the specification, which defines the size of an image (<img>) - as assuming the dimensions of the underlying image. (Which would mean that a site/page would render differently on different devices if the DPR was factored in.)

I just reworked how viewing an individual image works at hidpi, so I'm marking this as a duplicate. Feel free to reopen if this is actually something different, since there's some discussion of <img> here. I did not touch <img>.