When attempting to downsize an image for conservation of disk space, I've noticed that the GetThumbNail function does not allow precise control over the resulting file size. My objective is to determine if an image is above a target Filesize (in this case 200k) and if so, reduce it to the target size (approximately, allowing some wiggle room for rounding, file compression, etc).
Whenever a new pixel dimension is specified for GetThumbnail, the function performs some very questionable handling of the new image.
In my Capture 1, an image is being "thumbnailed" to it's actual size, and retains the same file size (563k at 180 DPI).
In Capture 2, the horizontal resolution requested has been reduced by 1 pixel. The resulting file size has plummeted to 162k, and the actual DPI has been factored down from 180 to 72.
I come from a graphic arts background, and have a decent understanding of image file properties (pixels, inches and DPI). This result seems to fly in the face of most image editing software (Photoshop). The pixel dimensions are unrelated to the DPI, the DPI relating to the dimension in inches ( Pixels / DPI = Inches ) of the image.
I'd like to report this as a bug, unless anyone can offer something I'm missing here. Any input is appreciated.
FMPA 13.05 and 14.04
Windows 2008 R2 Server