On 12.08.2005 12:00:05 Thomas DeWeese wrote:
> 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
> > already.
> 
>     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, but we have to deal with a mix of different image sources
here which don't all support that kind of stuff. That's why the analyser
package exists. Also, it is necessary to support direct embedding of
JPEG and EPS graphics into PDF and PS, for example. I hope I understood
you right.

> > 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
> > values.
> > 
> > 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,
> TIFF_Y_RESOLUTION, TIFF_RESOLUTION_UNIT).

Cool. Thanks for the info. I've already implemented it. I didn't realize
that there was a getProperty() method exposed RenderedImage and the
Batik codecs support these.

Sorry, Manuel, while looking through this information it was so easy to
hack in so I just committed it. 
http://svn.apache.org/viewcvs?rev=232263&view=rev

> > 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...
> 
> > [1] 
> > http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/apache/batik/ext/awt/image/codec/PNGRed.java
> > [2] 
> > http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/apache/batik/ext/awt/image/codec/PNGImageDecoder.java
> > 
> > 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?
> >>
> >>Thanks
> >>
> >>Manuel
> > 
> > 
> > 
> > 
> > Jeremias Maerki
> > 



Jeremias Maerki

Reply via email to