Re: Batik images and resolution

[Thomas DeWeese]

Hi Manuel,

Manuel Mall wrote:


[...] In addition TIFF is currently supported through BatikImage.
I don't think once Batik has the inputstream decoded, e.g. read 
the TIFF directory, I have access to the raw data required for 
the CCFFilter.


So I suggest the following. We provide two TIFF image implementations. 
One based on JAI as in 0.20.5 which allows native embedding in a PDF 
using the CCFFilter and one through Batik. 


   The Tiff implementation in Batik comes from JAI.  So I would
presume that what ever you were doing with the JAI reader could
be done with the Batik reader.

If JAI is available the JAI TIFF implementation is chosen and 
smaller PDFs are produced in other environments the Batik variant 
is used.






Does that sound OK?

Manuel




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.


Actually 0.20.5 supports direct embedding of TIFF in PDF as well.
This is a very important feature for our application as we have
lots of TIFF images (actually incoming faxes) which we bundle into
PDFs using FOP. Would hate to see that getting lost in the trunk
code. Not sure how this could be done with the Batik stuff as the
PDF renderer would need access to the undecoded stream in that
case.

Manuel


Jeremias Maerki

Re: Batik images and resolution

[Jeremias Maerki]

I haven't looked into it in detail but what you say makes sense. If
possible I'd try to use loadOriginalData() as much as possible even if
I needed to stretch the meaning a bit. I'm sure you'll figure out the
right way.

On 15.08.2005 16:04:00 Manuel Mall wrote:
> 
> On Sun, 14 Aug 2005 09:14 pm, Jeremias Maerki wrote:
> > Oh, right, looks like the CCFFilter needs to be ported from the
> > maintenance branch to the trunk. I didn't remember that one. The
> > Batik codecs are actually not so much involved in this case, since
> > the TIFF doesn't have to be fully decoded. Have a look at how JPEG is
> > handled. The JPEGs are simply analyzed by the JPEGReader and the
> > directly provided as a byte stream (undecoded) in JPEGImage to the
> > renderers.
> >
> > http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_20_2-m
> >aintain/src/org/apache/fop/pdf/CCFFilter.java
> >
> Adding CCFFilter from 0.20.5 is the easy bit and I have done that.
> Unfortunately the JPEG handling model is not quite suitable for TIFF and 
> that's where I am stuck. For JPEG a PDF document can include the whole 
> file as part of the DCTFilter. This is not true for TIFF. Only certain 
> TIFF formats are supported by the CCFFilter and only the actual image 
> data from the TIFF file goes into the filter. All the meta information, 
> e.g. the TIFF directory, is not stored in the PDF file. Therefore I 
> cannot really use the FopImage.loadOriginalData() function because it 
> would load the full data. Of course I could give that function a 
> different meaning in the TIFF context but that may stuff up other 
> render implementations in the future which assume that this function 
> returns all the data but may be thats not such a big deal. In addition 
> TIFF is currently supported through BatikImage. I don't think once 
> Batik has the inputstream decoded, e.g. read the TIFF directory, I have 
> access to the raw data required for the CCFFilter.
> 
> So I suggest the following. We provide two TIFF image implementations. 
> One based on JAI as in 0.20.5 which allows native embedding in a PDF 
> using the CCFFilter and one through Batik. If JAI is available the JAI 
> TIFF implementation is chosen and smaller PDFs are produced in other 
> environments the Batik variant is used.
> 
> Does that sound OK?


Jeremias Maerki

Re: Batik images and resolution

[Manuel Mall]

On Sun, 14 Aug 2005 09:14 pm, Jeremias Maerki wrote:
> Oh, right, looks like the CCFFilter needs to be ported from the
> maintenance branch to the trunk. I didn't remember that one. The
> Batik codecs are actually not so much involved in this case, since
> the TIFF doesn't have to be fully decoded. Have a look at how JPEG is
> handled. The JPEGs are simply analyzed by the JPEGReader and the
> directly provided as a byte stream (undecoded) in JPEGImage to the
> renderers.
>
> http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_20_2-m
>aintain/src/org/apache/fop/pdf/CCFFilter.java
>
Adding CCFFilter from 0.20.5 is the easy bit and I have done that.
Unfortunately the JPEG handling model is not quite suitable for TIFF and 
that's where I am stuck. For JPEG a PDF document can include the whole 
file as part of the DCTFilter. This is not true for TIFF. Only certain 
TIFF formats are supported by the CCFFilter and only the actual image 
data from the TIFF file goes into the filter. All the meta information, 
e.g. the TIFF directory, is not stored in the PDF file. Therefore I 
cannot really use the FopImage.loadOriginalData() function because it 
would load the full data. Of course I could give that function a 
different meaning in the TIFF context but that may stuff up other 
render implementations in the future which assume that this function 
returns all the data but may be thats not such a big deal. In addition 
TIFF is currently supported through BatikImage. I don't think once 
Batik has the inputstream decoded, e.g. read the TIFF directory, I have 
access to the raw data required for the CCFFilter.

So I suggest the following. We provide two TIFF image implementations. 
One based on JAI as in 0.20.5 which allows native embedding in a PDF 
using the CCFFilter and one through Batik. If JAI is available the JAI 
TIFF implementation is chosen and smaller PDFs are produced in other 
environments the Batik variant is used.

Does that sound OK?

Manuel


> > > 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.
> >
> > Actually 0.20.5 supports direct embedding of TIFF in PDF as well.
> > This is a very important feature for our application as we have
> > lots of TIFF images (actually incoming faxes) which we bundle into
> > PDFs using FOP. Would hate to see that getting lost in the trunk
> > code. Not sure how this could be done with the Batik stuff as the
> > PDF renderer would need access to the undecoded stream in that
> > case.
> >
> > Manuel
>
> Jeremias Maerki

Re: Batik images and resolution

[Jeremias Maerki]

AFAIK, the codecs themselves are not affected by the headless issue.
They are simply code to decode and encode the TIFF and PNG formats.
Furthermore, Batik maintains JDK 1.3 compatibility so no worries here,
either. The codecs will probably be moved into XML Graphics Commons
anyway, so no point in duplicating the code in FOP.

On 14.08.2005 18:23:16 The Web Maestro wrote:
> On Aug 12, 2005, at 2:27 AM, 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.
> 
> BTW, I don't know if it 'helps', but since Batik doesn't run headless 
> (w/o workarounds), IMO it would definitely be better to move each 
> format's codec into FOP's *Reader implementations. Ideally, it would be 
> great to ensure FOP's ability to run headless. There's also the desire 
> by those running AIX 4.1 to be able to maintain Java 1.3 compatibility, 
> for those machines which can't run in Java 1.4+ (but that's a different 
> discussion).



Jeremias Maerki

Re: Batik images and resolution

[The Web Maestro]

On Aug 12, 2005, at 2:27 AM, 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.


BTW, I don't know if it 'helps', but since Batik doesn't run headless 
(w/o workarounds), IMO it would definitely be better to move each 
format's codec into FOP's *Reader implementations. Ideally, it would be 
great to ensure FOP's ability to run headless. There's also the desire 
by those running AIX 4.1 to be able to maintain Java 1.3 compatibility, 
for those machines which can't run in Java 1.4+ (but that's a different 
discussion).


Regards,

Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Batik images and resolution

[Jeremias Maerki]

Oh, right, looks like the CCFFilter needs to be ported from the
maintenance branch to the trunk. I didn't remember that one. The Batik
codecs are actually not so much involved in this case, since the TIFF
doesn't have to be fully decoded. Have a look at how JPEG is handled.
The JPEGs are simply analyzed by the JPEGReader and the directly
provided as a byte stream (undecoded) in JPEGImage to the renderers.

http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_20_2-maintain/src/org/apache/fop/pdf/CCFFilter.java

On 13.08.2005 07:46:49 Manuel Mall wrote:
> On Fri, 12 Aug 2005 06:48 pm, Jeremias Maerki wrote:
> > 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.
> >
> Actually 0.20.5 supports direct embedding of TIFF in PDF as well. This 
> is a very important feature for our application as we have lots of TIFF 
> images (actually incoming faxes) which we bundle into PDFs using FOP. 
> Would hate to see that getting lost in the trunk code. Not sure how 
> this could be done with the Batik stuff as the PDF renderer would need 
> access to the undecoded stream in that case.
> 
> Manuel



Jeremias Maerki

Re: Batik images and resolution

[Manuel Mall]

On Fri, 12 Aug 2005 06:48 pm, Jeremias Maerki wrote:
> 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.
>
Actually 0.20.5 supports direct embedding of TIFF in PDF as well. This 
is a very important feature for our application as we have lots of TIFF 
images (actually incoming faxes) which we bundle into PDFs using FOP. 
Would hate to see that getting lost in the trunk code. Not sure how 
this could be done with the Batik stuff as the PDF renderer would need 
access to the undecoded stream in that case.

Manuel

Re: Batik images and resolution

[Jeremias Maerki]

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

Re: Batik images and resolution

[Manuel Mall]

On Fri, 12 Aug 2005 06:00 pm, Thomas DeWeese wrote:
> Jeremias Maerki wrote:

> 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).
>
Thanks Thomas. Yes, I saw that myself, did a quick hack to try it and it 
works. 

Now have to figure out to properly integrate it into FOPs image handling 
as extracting the resolution is obviously image format specific but the 
code is all stuck in the BatikImage class with the PNG and TIFF 
subclasses not having access to the underlying Batik properties stuff. 
Never mind, I'll think of something.

Re: Batik images and resolution

[Thomas DeWeese]

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, 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).


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

Re: Batik images and resolution

[Jeremias Maerki]

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.

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. 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. :-)


[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

Batik images and resolution

[Manuel Mall]

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