Resize to print size

[DanAvni]

I want to resize my images not by target width & height but to specific print size (e.g. width will be 13cm). so If I have an image of 200 pixels per centimeter then to get 13cm I would resize it to 2600 pixels. Is there a way to resize to units other than pixels? or alternatively is there a way to get the current density of the image (DPI and such) so I can calculate from that the needed width in pixels?

[saucecontrol]

There isn't a great way to retrieve the DPI or other metadata before processing right now, but that's something I'm starting to plan around. This is an interesting use case I'll keep in mind.

In the meantime, I can recommend MetdataExtractor, which should allow you to grab the DPI and size of the source images so you can do the calculations before passing to MagicScaler.

In your scenario, would you be looking to specify a physical size while preserving the source DPI, or would your target DPI be dependent on print device so that both the size and DPI would be variable?

[DanAvni]

I need to resize to 13cm while preserving the DPI (at least this is my current use case)

[moon6969]

It appears that MagicImageProcessor.ProcessImage() always sets the dpi to ~96 even if the source .png file has a different DPI?

If so, it would be desirable to have an option to keep the source image dpi and/or force a particular dpi in the ProcessImage() output.

My use case is for WPF - the easiest way I've found to stop WPF messing with the scaling is to force the bitmap DPI the same as the Windows effective DPI (eg: 144dpi == user scaling 150%).

Unless there is a better way I can use MagicImageProcessor to scale my image files for use in WPF window?

My workaround currently is to call this on the output of ProcessImage()...

        public BitmapSource SetBitmapDPI(BitmapSource bitmapImage, double dpi)
        {
            int stride = bitmapImage.PixelWidth * bitmapImage.Format.BitsPerPixel;
            byte[] pixelData = new byte[stride * bitmapImage.PixelHeight];
            bitmapImage.CopyPixels(pixelData, stride, 0);

            BitmapSource result = BitmapSource.Create(
                bitmapImage.PixelWidth, bitmapImage.PixelHeight,
                dpi, dpi, bitmapImage.Format, null, pixelData, stride);

            return result;
        }

[saucecontrol]

@moon6969 if you set DpiX = 0, DpiY = 0 explicitly in your ProcessImageSettings, it will preserve any DPI values present in the source image metadata, or you can set those values explicitly to whatever you want.

See: https://docs.photosauce.net/api/PhotoSauce.MagicScaler.ProcessImageSettings.html#PhotoSauce_MagicScaler_ProcessImageSettings_DpiX

I actually originally made it default to 96 DPI because that's the WPF default with 100% monitor scaling, and I was having issues with WPF showing images too small if they had print DPIs. Now that monitor zoom is much more prevalent it would seem to be no default is safe.

[moon6969]

👍

I'm wondering if you actually wanted to write "RTFM" ! I blame my eyes bleeding after days of wrestling with per-monitor DPI awareness and blurry icons.

On balance the default value of 96 is probably valid since so many images have random values.

As a cheeky side-question, do you know how WPF handles fractional print DPIs?
EG: Many PNG have dpi of ~96.12 due to storing dpi as pixels per meter... does this mean WPF rescales my 96.12 dpi image ever so slightly on a 100% scaled 96.0 monitor?

[saucecontrol]

Ha, I actually had to think through that a bit because it's been so long since I had to deal with those WPF DPI issues.

I solved mine using the technique described here: https://docs.microsoft.com/en-us/archive/blogs/dwayneneed/blurry-bitmaps

That solution makes the DPI irrelevant, so I haven't had to think about it since. And yeah, I think 96.12 DPI will cause some subpixel rounding and blurring, but my memory may be faulty there.