Bug 46468 - PNG's - warn if resolution can't be determined
Summary: PNG's - warn if resolution can't be determined
Status: NEEDINFO
Alias: None
Product: XMLGraphicsCommons - Now in Jira
Classification: Unclassified
Component: image codecs (show other bugs)
Version: Trunk
Hardware: All All
: P3 enhancement (vote)
Target Milestone: --
Assignee: XML Graphics Project Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-04 03:25 UTC by Jason Harrop
Modified: 2012-04-10 21:58 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Harrop 2009-01-04 03:25:17 UTC
If, for a PNG image, ImageMagick's identify says:

  Resolution: 320x320
  Units: Undefined <----------------

then ImageInfo will use a default value, using Toolkit.getDefaultToolkit().getScreenResolution(), which in my case is 160.

Nothing wrong with that I suppose, but it would be helpful if a warning was logged or something, so you knew to fix the image.

When PreloaderImageIO.preloadImage does:

        ImageIOUtil.extractResolution(iiometa, size);

it is finding the Dimension child, but not "HorizontalPixelSize" or VerticalPixelSize (these are null).
Comment 1 Max Berger 2009-01-21 01:04:27 UTC
I haven't taken this bug yet as I am still unsure about the proper solution.

Currently:

getDefaultResulution is called, result stored.
Resultion of image is determined if possible, and overwrites default resolution.

The problem:
this happens in multiple different places (PNG is just one). A proper solution would handle all of them.

We could add the warning to each case, but that would not make much sense. Instead, a common function should warn, which means:

in each case:
resolution = null;
determine resolution from image;
fallbackIfneeded(resolution)

and fallbackifneeded would do:
if resolution == null
  emit warning
  resolution = defaultResolution.

The problem here: Other calculations, such as the image size, depend on the resultion being set beforehand. Each of the cases would need to be examined if the resultion could be safely set AFTER the other image info is parsed.

Second issue: Not all image formats support resultion. 

minor issue: Some images support different x,y resolutions, this should also be taken into account.

Max
Comment 2 Jeremias Maerki 2009-02-09 13:38:14 UTC
Sorry for being late here (being the original author of the thing). The issue here shows that someone was able to make use of the image loading framework outside the FOP context which makes me happy. Mission accomplished. ;-) As for the missing resolution information:

If using Toolkit.getDefaultToolkit().getScreenResolution() for the fallback resolution is a problem, you can always use your own implementation of the ImageContext interfaces. I'm also doing that in FOP where the default source resolution if configured in an XML file.

If it is important to be notified if an image resolution is missing, I think the most straight-forward solution is to introduce a listener interface which can be made available through the ImageContext. Something like the following maybe:

public interface ImageLoaderListener {
    void notifyMissingImageResolution(Object source, String uri, String mime);
}

I can imagine that, in time, we may add additional features either to the listener or the Image(Session)Context.

Max noted different resolutions for X and Y. Some formats support that. Personally, I've never seen an image with different X and Y resolutions, yet. So if there's no need I wouldn't complicate things prematurely. That can always be easily added in a backwards-compatible way if it's really needed. At any rate, ImageInfo supports separate resolutions, just in case. But I don't believe it's needed for the fallback.

WDYT?
Comment 3 Glenn Adams 2012-04-10 21:58:27 UTC
jason, if you would like to submit a patch following Jeremias' recommendation in comment 2, then i'd be happy to apply it; otherwise, i will mark this as resolved+later due to lack of action