width options and the related
\resizebox actually calculate a scale factor and then use some internal form of
\scalebox to do the scaling. Because this calculation requires a division (which is implemented using a loop in
graphic/x) a numeric error is introduced. The size of the error depends on the original and requested size. If the scale factor is an integer there is no error. The equation is (IIRC) like follows:
(requested size / original size) * original size ~ requested size
(..) factor suffers unfortunately from the limited resolution of TeX.
~ = approximately)
Also the actually scaling is done by the driver or the output format itself, i.e. the image is added to the PDF as it is and the viewer does the scaling as ordered. I don't think you can get a smaller error. I myself tried other ways for the division and didn't got a better precision.
In order to have an official size in TeX a box with the given size is inserted.
graphic/x takes the calculated scale factor to produce the box, not the requested width and height. It would be possible to rewrite the code to do it differently, then the image should still have the same size as before in the PDF viewer but the official TeX size would be "correct", i.e. as requested.
This could be done by simple setting the width and height explicitly to the requested sizes. I did some research and work in this direction for my
adjustbox package, which is based on
graphicx. However, I didn't dared patching
graphics/x so far to not risk any hidden comparabilities etc.
You could also check the PDF standard if it is possible to include the scaled image with the given requested size (converted to bp) instead of a scale factor, and then rewrite the pdftex driver accordantly.
graphics) scales items in big points (
bp) rather than some smaller length unit.