Jeremias Maerki wrote:
Ideally, the *Reader implementations (analyser package) for each format
should actually read the extents and the bitmap resolution already. It
should not be deferred to the actual codec, if possible. That makes it
possible to work with the image (during layout) without fully loading it

   Well IMO the right thing is for the image codec to defer the loading
of the image data until requested.  This way you only need one set of
parsing code to get right and maintain.  It can also simply the coding
as you don't have to switch between multiple representations.

   This is the way the imageio classes work.  Also some of the
Batik codec's work this way (Tiff).

Of course, that means that someone has to have a deeper understanding of
a bitmap format to be able to write the code that extracts the necessary

On the other side, the Batik codecs actually parse the resolution
information. For PNG, see parse_pHYs_chunk() in [1]. Unfortunately, it
doesn't expose that information.

   Yes it does.  It uses the 'properties' interface to expose this
(and lots of other) information.  The properties in question are
"x_pixels_per_unit", "y_pixels_per_unit" & "pixel_units".

   The TIFF reader exposes the entire tiff directory (property
"tiff_directory").  You can get the resolution info from that
using the constants in TIFFImageDecoder (TIFF_X_RESOLUTION,

It's interesting to note, that
PNGImageDecoder [2] does almost the same as PNGRed. That confuses me.
Again, PNGImageDecoder doesn't expose the resolution info, either,
although it has it. We may need to ask the Batik guys if they know what
this is about. This almost screams for a patch. :-)

   Hmm, I think PNGImageDecoder can be removed, at some point
the PNGRed class was created as part of the Batik image hierarchy
from the PNGImageDecoder which was donated by Sun.  I'm not sure
why the PNGImageDecoder wasn't deleted at the time...


On 12.08.2005 10:56:18 Manuel Mall wrote:

I was looking at issues related to images not being displayed with their correct resolution. As far as I understand all image formats apart from GIF (which defaults to 72dpi) do carry resolution information. However, it only works for JPEG at the moment. I managed to fix it for BMP images by reading / interpreting the appropriate header fields. TIFF and PNG are more complicated as the information is buried in the file so you actually have to load the image to get to the information. Both TIFF and PNG are currently implemented using BatikImage. However, it appears that the Batik decoder doesn't make the resolution information available. At least its not set in BatikImage.loadImage() and I couldn't find a field in the org.apache.batik.ext.awt.image.rendered.CachableRed class which looks like holding the x and y resolutions.

Any one knows how to get to the resolution settings for the Batik images?



Jeremias Maerki

Reply via email to