Hmm, I am getting a different result from you, one that is even worse: the image comes out 1 x 1px, with a variety of different settings tested. What are the precise settings you are using, and what size of an image should I target for (10mb doesn’t tell me much all by itself)—image file type might also matter (I was testing with PNG-24).
Also a feature request in relation to this bug: please could we have a 96 DPI option? 72 DPI is fine for old readers, but 96 DPI would be better for more recent hires ones, without having to go all the way to 150 DPI that more than doubles the size (for no visible gain). I think 96 DPI would be the sweet spot for many users.
This is a fairly complicated matter, one that was discussed several years ago. Ultimately the DPI setting of an image is largely ignored by HTML-based rendering systems such as ebook readers and web browsers. All that matters is the physical raster size and the HTML declaring the intended visual size. One achieves “high resolution images” in an HTML environment by providing more pixels than you stipulate for the width. These two factors create an effective PPI in the display, but this is not coming from the image’s properties itself. And as noted, even the concept of a “pixel” is a bit abstracted when it comes to HTML/CSS size declarations, and to a degree the physical size of a pixel is determined by the relationship between the physical display and the software.
The settings in the compiler are an abstraction, in other words, or a way of saying these two things using print jargon (why, I don’t know, but I guess it’s fairly common even in ebooks to think in terms of “DPI”). The DPI setting in other words allows you to select how many pixels to overload into the image’s requested width, set to the right. The 72 setting creates a 1:1 balance between raster size and requested display size, which we could consider a “standard resolution” image. A 150 DPI setting would be closest to what we would consider a “high resolution” screen image, such as one optimised for Retina (144 DPI, or twice the size of 72). Amazon has been recommending overloading by an equivalent of 300 DPI for some years now, given how many eInk and mobile LCD/OLED devices meet or exceed that resolution.
Whether or not there is a tangible gain from using higher resolution images is perhaps subjective, but I would not agree with you that there is no difference! Nobody would buy high-res screens if there was no difference, and displaying a standard-res image on a high-res screen at the same scale is noticeably blurry to me. No doubt the subject matter makes a big difference. A photograph of a lake may be passable at low-res on a high-res screen, but a wireframe figure of a machine part would look pretty bad in those conditions.
It’s worth reiterating that the discussion I linked to has less to do with the image’s physical properties, and more to do with how Scrivener should determine and set the HTML for its intended visual display size in the rendering agent. As noted there, it uses 72 pt/in based calculations for determining the size, which in my testing correlates very closely to visual parity between input and output, where possible. The argument being raised there is that HTML user agents might more commonly be using 96 pt/in calculations, and so Scrivener would be theoretically more accurate by using that to set the HTML sizes. As for why 72pt-based seems more accurate, it’s probably down to how Scrivener’s text engine is rooted in print-based scaling, where 72pt/in is the standard and has nothing to do with screen resolutions.
In practice that did not seem to be the case back then, but it is again all somewhat irrelevant to the physical image itself.
I can find the time to help, but I’m not willing to waste it until the devs are available to spend some serious time on the compiler as a whole.