Re: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18
Ognjen, You may well have it, depending on where you got your Java installation. I see you're on windows, so it's probably already included. With linux, I used to have to install it myself, but I've been using OS X for a while now, so I don't know about either Windows or linux any more. The others will tell you if it's necessary. Peter West "Why do you seek the living among the dead? He is not here, but is risen." On 04/05/2011, at 11:24 PM, Ognjen Blagojevic wrote: > Hi Peter, > > I didn't install anything other than regular JDK for Linux. > > Do you mean "JAI library" or "JAI Image I/O tools"? They are both mentioned > in FOP docs [1], but from what I understand neither is necessary for PNG > image manipulation: > > "(BMP, TIFF) Requires the presence of JAI Image I/O Tools (or an equivalent > Image I/O compatible codec) in the classpath. JAI Image I/O Tools also adds > support for JPEG 2000, WBMP, RAW and PNM. Other Image I/O codecs may provide > support for additional formats.". > > Do I need to install it, anyway? > > Regards, > Ognjen > > [1] http://xmlgraphics.apache.org/fop/1.0/graphics.html#support-overview
Re: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18
Hi Peter, I didn't install anything other than regular JDK for Linux. Do you mean "JAI library" or "JAI Image I/O tools"? They are both mentioned in FOP docs [1], but from what I understand neither is necessary for PNG image manipulation: "(BMP, TIFF) Requires the presence of JAI Image I/O Tools (or an equivalent Image I/O compatible codec) in the classpath. JAI Image I/O Tools also adds support for JPEG 2000, WBMP, RAW and PNM. Other Image I/O codecs may provide support for additional formats.". Do I need to install it, anyway? Regards, Ognjen [1] http://xmlgraphics.apache.org/fop/1.0/graphics.html#support-overview On 4.5.2011 14:08, Peter B. West wrote: I suppose you have JAI installed in both 6u17 and 6u18/24? Peter West "Why do you seek the living among the dead? He is not here, but is risen." On 04/05/2011, at 8:17 PM, Ognjen Blagojevic wrote: Hi, To keep issue alive, I reported a bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=51149 Regards, Ognjen
Re: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18
I suppose you have JAI installed in both 6u17 and 6u18/24? Peter West "Why do you seek the living among the dead? He is not here, but is risen." On 04/05/2011, at 8:17 PM, Ognjen Blagojevic wrote: > Hi, > > To keep issue alive, I reported a bug: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=51149 > > Regards, > Ognjen
Re: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18
Hi, To keep issue alive, I reported a bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=51149 Regards, Ognjen On 19.3.2011 12:30, Ognjen Blagojevic wrote: Jeremias, For this particular image, with Java 6u17 I get: [DEBUG] New ImageAdapter created for key: (snip)/image-with-color-profile.png [DEBUG] Image returns ICC profile: sRGB IEC61966-2.1, default sRGB=false Image processing is fast, program execution time is 7s. However, with JDK 6u24, I get [DEBUG] New ImageAdapter created for key: (snip)/image-with-color-profile.png [DEBUG] Image returns ICC profile: sRGB IEC61966-2.1, default sRGB=true Image processing is slow, program execution time is 52s. This seems to be contrary to what is expected? Here is PNG attached (if the list accepts it). -Ognjen On 18.3.2011 16:32, Jeremias Maerki wrote: Ognjen, sorry for the late answer. Could you please set the following log level to FINE/DEBUG: org.apache.fop.render.pdf.AbstractImageAdapter If you get the line "Image returns ICC profile: sRGB, default sRGB=true", your PNG is a normal sRGB bitmap. This will (normally) allow FOP to dump the bitmap data efficiently to the output file. In your case, the encoded color model seems to differ from the original one which is why the ImageEncodingHelper (from XML Graphics Commons) falls back to encoding sRGB data which has to go through color management. And that's what's making the process very slow. Every pixel is converted to sRGB by the color profile associated with the BufferedImage that has been built from the PNG file. But...I cannot reproduce your problem. With all PNGs I've tested I get optimized encoding (Sun Java 6.0_24). Could you please send me your PNG? Maybe there's something peculiar about it. On 18.03.2011 09:20:34 Ognjen Blagojevic wrote: On 11.3.2011 12:54, Ognjen Blagojevic wrote: Having said all this, my proposal is: 1. if someone can help me to track bug further (remember, 1.6.0_17 was working just fine) we could file the bug report to Oracle, or 2. we could just add the info in FOP/xmlgraphics docs that color profile in PNG images introduces significant slowdown on JDK 1.6.0_18+. Ok, since it seems that it is too hard to track this down, I suggest we add to PNG Graphics page [1] something like: "Note: PNG images with color profile are on certain JDKs (most notably Oracle JDK 6u18+) processed as much as 20 times slower than same images without color profile. This slowdown is introduced by JDK image manipulation classes." Thoughts? -Ognjen [1] http://xmlgraphics.apache.org/fop/1.0/graphics.html#png Jeremias Maerki
Re: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18
A color profiles how pixel data is supposed to be interpreted. XSL-FO and SVG, by default, work in the sRGB color space which is a standardized RGB color profile. If you don't have a color profile, you don't know exactly what the color will look like on screen or paper when, for example, you have a color rgb(123,166,45). This is being referred to as an uncalibrated color. OTOH, if you know that this RGB color is in the sRGB color space, the appearance of that color is closely defined and is therefore called calibrated You can read more about color management here: http://en.wikipedia.org/wiki/Color_management Yes, you can get color output without a color profile resulting in uncalibrated (i.e. not necessarily correct colors). But you're using PNGRenderer and since Java internally works with sRGB and PNG does, too, you'll get calibrated sRGB colors. On 18.03.2011 14:10:16 Eric Douglas wrote: > What is this color profile? Can I get color output without it? I am > using the PNGRenderer, currently running JDK 6u17 about to install u24 > today. > > -Original Message- > From: Ognjen Blagojevic [mailto:ognjen.d.blagoje...@gmail.com] > Sent: Friday, March 18, 2011 4:21 AM > To: fop-dev@xmlgraphics.apache.org > Subject: Re: 20x slowdown in PNG processing when switching from JDK > 1.6.0_17 to 1.6.0_18 > > On 11.3.2011 12:54, Ognjen Blagojevic wrote: > > Having said all this, my proposal is: > > > > 1. if someone can help me to track bug further (remember, 1.6.0_17 was > > > working just fine) we could file the bug report to Oracle, or 2. we > > could just add the info in FOP/xmlgraphics docs that color profile in > > PNG images introduces significant slowdown on JDK 1.6.0_18+. > > Ok, since it seems that it is too hard to track this down, I suggest we > add to PNG Graphics page [1] something like: > > "Note: PNG images with color profile are on certain JDKs (most notably > Oracle JDK 6u18+) processed as much as 20 times slower than same images > without color profile. This slowdown is introduced by JDK image > manipulation classes." > > Thoughts? > > -Ognjen > > [1] http://xmlgraphics.apache.org/fop/1.0/graphics.html#png Jeremias Maerki
Re: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18
Ognjen, sorry for the late answer. Could you please set the following log level to FINE/DEBUG: org.apache.fop.render.pdf.AbstractImageAdapter If you get the line "Image returns ICC profile: sRGB, default sRGB=true", your PNG is a normal sRGB bitmap. This will (normally) allow FOP to dump the bitmap data efficiently to the output file. In your case, the encoded color model seems to differ from the original one which is why the ImageEncodingHelper (from XML Graphics Commons) falls back to encoding sRGB data which has to go through color management. And that's what's making the process very slow. Every pixel is converted to sRGB by the color profile associated with the BufferedImage that has been built from the PNG file. But...I cannot reproduce your problem. With all PNGs I've tested I get optimized encoding (Sun Java 6.0_24). Could you please send me your PNG? Maybe there's something peculiar about it. On 18.03.2011 09:20:34 Ognjen Blagojevic wrote: > On 11.3.2011 12:54, Ognjen Blagojevic wrote: > > Having said all this, my proposal is: > > > > 1. if someone can help me to track bug further (remember, 1.6.0_17 was > > working just fine) we could file the bug report to Oracle, or > > 2. we could just add the info in FOP/xmlgraphics docs that color profile > > in PNG images introduces significant slowdown on JDK 1.6.0_18+. > > Ok, since it seems that it is too hard to track this down, I suggest we > add to PNG Graphics page [1] something like: > > "Note: PNG images with color profile are on certain JDKs (most notably > Oracle JDK 6u18+) processed as much as 20 times slower than same images > without color profile. This slowdown is introduced by JDK image > manipulation classes." > > Thoughts? > > -Ognjen > > [1] http://xmlgraphics.apache.org/fop/1.0/graphics.html#png Jeremias Maerki
RE: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18
What is this color profile? Can I get color output without it? I am using the PNGRenderer, currently running JDK 6u17 about to install u24 today. -Original Message- From: Ognjen Blagojevic [mailto:ognjen.d.blagoje...@gmail.com] Sent: Friday, March 18, 2011 4:21 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18 On 11.3.2011 12:54, Ognjen Blagojevic wrote: > Having said all this, my proposal is: > > 1. if someone can help me to track bug further (remember, 1.6.0_17 was > working just fine) we could file the bug report to Oracle, or 2. we > could just add the info in FOP/xmlgraphics docs that color profile in > PNG images introduces significant slowdown on JDK 1.6.0_18+. Ok, since it seems that it is too hard to track this down, I suggest we add to PNG Graphics page [1] something like: "Note: PNG images with color profile are on certain JDKs (most notably Oracle JDK 6u18+) processed as much as 20 times slower than same images without color profile. This slowdown is introduced by JDK image manipulation classes." Thoughts? -Ognjen [1] http://xmlgraphics.apache.org/fop/1.0/graphics.html#png
Re: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18
On 11.3.2011 12:54, Ognjen Blagojevic wrote: Having said all this, my proposal is: 1. if someone can help me to track bug further (remember, 1.6.0_17 was working just fine) we could file the bug report to Oracle, or 2. we could just add the info in FOP/xmlgraphics docs that color profile in PNG images introduces significant slowdown on JDK 1.6.0_18+. Ok, since it seems that it is too hard to track this down, I suggest we add to PNG Graphics page [1] something like: "Note: PNG images with color profile are on certain JDKs (most notably Oracle JDK 6u18+) processed as much as 20 times slower than same images without color profile. This slowdown is introduced by JDK image manipulation classes." Thoughts? -Ognjen [1] http://xmlgraphics.apache.org/fop/1.0/graphics.html#png
