Pfff...sorry for the noise.
I'll double check my measurements on MacOS and will also try to
measure on Debian (where the app is in production). I can live with
the slowdown on Mac and so hopefully it does not show up on Debian
Thanks again!
Peter
On 13 Apr 2008, at 11:19, Jeremias Maerki
That's why I provided two different measurements for the 0.95 branch:
once with JAI's codec and once with Commons' TIFF codec ("internal TIFF
codec") which is enabled by my fix from Friday. You can see that the
internal TIFF codec adds about 0.4 seconds in my environment compared to
the JAI codec.
Thanks Jeremiasas always, very thorough work/analysis.
Is it correct you always used JAI TIFF codec in your measurements and
never the xmlgraphics fix you added on Friday. The one that supports
tiff without jai at all?
If so, any chance at all you could measure the performance of that f
Peter sent me one of his large TIFF images to test with. Thanks, Peter.
I used his FO snippet he posted at the beginning of the thread so the
firgures below are including Batik into the picture.
The TIFF file: RGB, LZW compression, 1327x3682 pixels, 2.73MB
I couldn't see a factor 6 increase of ti
On 12 Apr 2008, at 13:09, Andreas Delmelle wrote:
On Apr 11, 2008, at 23:30, Peter Coppens wrote:
Hi Peter
I don't like the jai dependancy (don't like native Java libraries)
Very rightly so. As demonstrated by this particular case, if one
platform lacks native support, it seriously break
On Apr 11, 2008, at 23:30, Peter Coppens wrote:
Hi Peter
I don't like the jai dependancy (don't like native Java libraries)
Very rightly so. As demonstrated by this particular case, if one
platform lacks native support, it seriously breaks the usability of
the library as a platform-indep
On 11.04.2008 19:26:55 Andreas Delmelle wrote:
> On Apr 11, 2008, at 18:20, Peter Coppens wrote:
> >
> >>
> >>> Given my non existent knowledge on tiff (and image formats in
> >>> general) and (I am sure recognizable) chronic lack of time to
> >>> dive into image formats at this moment, I am af
YeahI wrote my first jai program earlier today
import javax.imageio.*;
public class ListImageDecoders {
public static void main (String args[]) {
String rfn[]=ImageIO.getReaderFormatNames();
for(String rf:rfn) {
System.out.println(rf);
On Apr 11, 2008, at 19:26, Andreas Delmelle wrote:
On Apr 11, 2008, at 18:20, Peter Coppens wrote:
Well, did a very quick test here, and without Jeremias' change, any
TIFF that is produced by Preview indeed fails with the message you
provided earlier.
Seems the issue is isolated to OS X. I
although the fact that 0.94 is faster than 0.95beta-jeremias-tiff
would make that weird.
Not really. It would be much weirder IMO if FOP (or any software for
that matter) were to offer increased flexibility/functionality/
features without any performance penalty whatsoever. If that wer
On Apr 11, 2008, at 18:20, Peter Coppens wrote:
Given my non existent knowledge on tiff (and image formats in
general) and (I am sure recognizable) chronic lack of time to
dive into image formats at this moment, I am afraid I would not
even know with which tiff parameters to play
Whi
On 11 Apr 2008, at 17:48, Andreas Delmelle wrote:
On Apr 11, 2008, at 07:18, Peter Coppens wrote:
Tried 2 more tiffs (but from the same 'source'). They gave the
similar results for relative performance. 1 (0.94) vs 30 (0.95beta)
vs 6(0.95beta-jeremias-tiff)
Given my non existent knowledge
On Apr 11, 2008, at 07:18, Peter Coppens wrote:
Tried 2 more tiffs (but from the same 'source'). They gave the
similar results for relative performance. 1 (0.94) vs 30 (0.95beta)
vs 6(0.95beta-jeremias-tiff)
Given my non existent knowledge on tiff (and image formats in
general) and (I am
Tried 2 more tiffs (but from the same 'source'). They gave the similar
results for relative performance. 1 (0.94) vs 30 (0.95beta) vs
6(0.95beta-jeremias-tiff)
Given my non existent knowledge on tiff (and image formats in general)
and (I am sure recognizable) chronic lack of time to dive in
On Apr 10, 2008, at 23:19, Andreas Delmelle wrote:
According to what I found, the problem could be not so much JAI
ImageIO itself, but the codecs.
Apparently, Apple does not provide native codecs for all formats,
(After some more reading) They do for a TIFF reader, however... maybe
their
On Apr 10, 2008, at 22:55, Peter Coppens wrote:
Well...I did the test with only a tif.
0.94 --> 4sec
0.95beta --> 78sec
Somewhat worrying to be honest (although I guess it might be due to
the fact that I am using a jai image io jar extracted from a linux
package)
I guess, next is to try
Well...I did the test with only a tif.
0.94 --> 4sec
0.95beta --> 78sec
Somewhat worrying to be honest (although I guess it might be due to
the fact that I am using a jai image io jar extracted from a linux
package)
I guess, next is to try Jeremias's version that gets rid of the jai
ima
On 10 Apr 2008, at 22:11, Andreas Delmelle wrote:
On Apr 10, 2008, at 22:00, Andreas Delmelle wrote:
No idea why the install would fail on your system, though. Maybe a
bug, due to the fact that, as you suggested, the install-package is
quite old, and no longer works on more recent versions
On Apr 10, 2008, at 22:11, Andreas Delmelle wrote:
On Apr 10, 2008, at 22:00, Andreas Delmelle wrote:
No idea why the install would fail on your system, though. Maybe a
bug, due to the fact that, as you suggested, the install-package
is quite old, and no longer works on more recent versions
On 10 Apr 2008, at 22:00, Andreas Delmelle wrote:
On Apr 10, 2008, at 21:37, Peter Coppens wrote:
On 10 Apr 2008, at 20:47, Andreas Delmelle wrote:
Now, I've been looking deeper into my local setup, and IIC, then
for Java 1.5, the JAI libraries are already distributed /with/ the
install
On Apr 10, 2008, at 22:00, Andreas Delmelle wrote:
No idea why the install would fail on your system, though. Maybe a
bug, due to the fact that, as you suggested, the install-package is
quite old, and no longer works on more recent versions of OS X (?)
Unfortunately, I don't know how the i
On Apr 10, 2008, at 21:37, Peter Coppens wrote:
On 10 Apr 2008, at 20:47, Andreas Delmelle wrote:
Now, I've been looking deeper into my local setup, and IIC, then
for Java 1.5, the JAI libraries are already distributed /with/ the
install package. At least, I do not remember ever having to
On 10 Apr 2008, at 20:47, Andreas Delmelle wrote:
On Apr 10, 2008, at 20:09, Peter Coppens wrote:
Now...for the more problematic part - I am on MacOS...anybody any
luck getting the 0.95beta fop/batik to work on macos when using
tif images? It is unclear from my intial www wanderings what th
There's now such an implementation available in XG Commons Trunk:
http://svn.apache.org/viewvc?rev=646931&view=rev
On 10.04.2008 17:06:37 Jeremias Maerki wrote:
> But I guess it makes sense to write an additional implementation for the
> built-in TIFF codec we ship. I wanted to get away from tha
On Apr 10, 2008, at 20:01, Peter Coppens wrote:
You can use the Java-only part of JAI Image I/O Tools. The
platform-specific parts are not necessary for TIFF. In the worst
case,
you can extract the JAR from an installation done on a Windows
machine
I hope you'll have around.
That works..
On Apr 10, 2008, at 20:09, Peter Coppens wrote:
Now...for the more problematic part - I am on MacOS...anybody any
luck getting the 0.95beta fop/batik to work on macos when using
tif images? It is unclear from my intial www wanderings what the
state of jai on mac os is.
I've not really tes
Now...for the more problematic part - I am on MacOS...anybody any
luck getting the 0.95beta fop/batik to work on macos when using
tif images? It is unclear from my intial www wanderings what the
state of jai on mac os is.
I've not really tested TIFF yet, but I do know that JAI is
definit
You can use the Java-only part of JAI Image I/O Tools. The
platform-specific parts are not necessary for TIFF. In the worst case,
you can extract the JAR from an installation done on a Windows machine
I hope you'll have around.
That works...kind of...
If I 'time' the pdf rendering of 'the' sty
On Apr 10, 2008, at 16:58, Peter Coppens wrote:
Hi Peter
As to the cause of the error...can't really see where else it is
coming from (but in the end that might be a 'detail'). Below the
complete stack trace...perhaps you find it 'interesting'
Now...for the more problematic part - I am on
Oh, I didn't remember we load the images inside SVG over the
new image loader through a special bridge in FOP.
You can use the Java-only part of JAI Image I/O Tools. The
platform-specific parts are not necessary for TIFF. In the worst case,
you can extract the JAR from an installation done on a Wi
Thanks Jeremias
As to the cause of the error...can't really see where else it is
coming from (but in the end that might be a 'detail'). Below the
complete stack trace...perhaps you find it 'interesting'
Now...for the more problematic part - I am on MacOS...anybody any luck
getting th
The error message comes from the FOP part, so I don't think that the
snippet you posted is really the source of the error. The solution here
is simple: Please install JAI Image I/O Tools in your classpath:
http://jai-imageio.dev.java.net/
This will add an Image I/O codec for TIFF. The new image lo
Dearest FOP/Batik fans (I am unclear where to post...sorry),
With FOP 0.94/Batik 1.6, the fo/svg fragment listed lower worked ok. I
switched to FOP0.95beta (which seems to come with a newer batik
version, 1.7) and get
SEVERE: SVG ErrorCannot load image (no suitable loader/converter
combin
33 matches
Mail list logo
