DPI Not Respected in UnmanagedImage.ToManagedImage()

[fdncred]

What would you like to submit? (put an 'x' inside the bracket that applies)

• question
• bug report
• feature request

Issue description
I have a 300 DPI bitonal image that I'm trying to process with Accord.Net. The code looks something like this:

    var img2 = Accord.Imaging.Image.FromFile(@"C:\Some\Folder\PCAMatching\haystack.tif");
    var tgtImg = UnmanagedImage.FromManagedImage(img2.Clone(PixelFormat.Format24bppRgb));
.... some other code here
    var tm = new ExhaustiveTemplateMatching(0.9f);
    int padding = 50;
    var cropRect = new Rectangle(bestMatch.X - padding, bestMatch.Y - padding, srcImg.Width + padding * 2, srcImg.Height + padding * 2);
    var cropROI = new Crop(cropRect);
    var cropBmp = cropROI.Apply(tgtImg);
    TemplateMatch[] matchings = tm.ProcessImage(cropBmp, srcImg);
    Bitmap sourceImage = tgtImg.ToManagedImage();

At this point sourceImage is now 96 DPI versus the 300 DPI image that I originally loaded.

I haven't studied the code but I do not see a property on UnmanagedImage for Horizontal or Vertical Resolution. I suspect that's part of the problem.

Thanks,
Darren

[cesarsouza]

Hi Darren,

Thanks for opening the issue.!

Could the issue be mitigated by setting the resolution of the final Bitmap using Bitmap.SetResolution? i.e. something like

sourceImage.SetResolution(300, 300);

just after the call to tgtImg.ToManagedImage()?

Regards,
Cesar

[fdncred]

Yes, it could. And that's what I did, however my point is that I shouldn't have to do that. When I load an image, I expect the image attributes to go with it through the entire processing chain, whatever those steps are. I have enough to remember without having to remember which image attributes appear and disapper. ;)

I noticed in the AForge classes they call CopyResolution() (or something like that) all over the place. Something similar should exist for the UnmanagedImage class as well.

[cesarsouza]

I understand, that's a valid point.

While we are at it, there is also something that I stumbled upon yesterday and qualifies as the framework not carrying some information along the processing chain. If you happen to load 8-bpp color images (not grayscale) into the framework, then their color palette will be ignored by most filters since they will assume the image is plain grayscale instead of color-indexed.

I will try to address those two issues together.

Thanks again,
Cesar

[fdncred]

Thanks! That's a sneaky one.

I understand that certain filters require certain bit depths but that whole thing drives me crazy, especially when dealing with bitonal images. I always forget to change their pixel depth and my software ends up puking. I wish that was more automatic. i.e. if my image is 1-bit and the filter requires 8-bit, why not just convert it instead of throwing and exception. I never understood that. We can save that for a later change, though.