Re: [JAVA2D] Retiring the package com.sun.image.codec.jpeg
I would vote for #1 - get rid of the classes entirely in Java 7. The warning is already out there when compiling in Java 6.. there is no sense in dragging it on. I would also vote for rewriting the JPEG loaders in Image I/O as they are quite poor performance-wise (and so is com.sun.image.codec.jpeg.JPEGCodec). I expect you could at the very least double the performance. The last I heard the existing codecs did not make use of vector instructions (SSE/MMX/Altivec/whatever), whereas any respectable implementation would. That's one of the primary reasons vector instructions like MMX were added to processors so many years ago. [Message sent by forum member 'swpalmer' (swpalmer)] http://forums.java.net/jive/thread.jspa?messageID=214236 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Retiring the package com.sun.image.codec.jpeg
My results are 18,250ms for ImageIO and 15,172 for JpegEncode. I will try to make a more thorough test and will try JAI. Thank, Carl [Message sent by forum member 'carcour' (carcour)] http://forums.java.net/jive/thread.jspa?messageID=212065 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Retiring the package com.sun.image.codec.jpeg
I received the test image from Carl and it does have an APP2 marker
with an ICC profile so its as I suspected.
com.sun.image.codec.jpeg is faster mainly because its not processing
this.
On my XP PC for 50 loads of the sample image I have
ImageIO : 32 seconds
JPEGDecoder : 13 seconds
But if I allow Image I/O to skip applying the color space conversion
I get 15 seconds - almost on a par ..
The way to 'skip' this is to specify that the returned buffered
image use the color space with the profile, rather than being
converted to sRGB before returning.
This does mean you need to directly invoke the JPEG reader
so you can tell it this. Sample code below :
There's a couple of robustness things lacking (like not
checking for null) but that's pretty much what you need.
IteratorImageReader it = ImageIO.getImageReadersBySuffix(jpg);
ImageReader jpegReader = it.next();
jpegReader.setInput(new FileImageInputStream(file));
IteratorImageTypeSpecifier typeIterator = jpegReader.getImageTypes(0);
ImageTypeSpecifier its = null;
while (typeIterator.hasNext() its == null) {
ImageTypeSpecifier tmp = typeIterator.next();
ColorSpace cs = tmp.getColorModel().getColorSpace();
if ((cs.getType() == ColorSpace.TYPE_RGB) !cs.isCS_sRGB()) {
its = tmp;
}
}
ImageReadParam param = jpegReader.getDefaultReadParam();
param.setDestinationType(its);
BufferedImage bimg = jpegReader.read(0, param);
It used to be the case that this was the default.
However notice that drawing this image will now take
longer as the conversion will be applied then.
This turned out to be a problem too for most people.
So this is probably not going to help if you need to
do that drawing anyway. We've discussed whether applying the
conversion is really necessary if RenderingHint.KEY_RENDERING
is set to VALUE_RENDER_SPEED, and the image types are generally
compatible, so perhaps in the future that will offer a solution.
In the interim you could just create a new BufferedImage
using the Raster from the returned one and a color model
which has an sSRGB color space .. ie essentially dropping
the ColorSpace which has the ICC profile data.
-phil.
Phil Race wrote:
There may be some differences in the way that the two APIs process the
image.
For example I noted recently that the old com.sun.image.codec,jpeg is
completely
ignorant of an APP2 marker with an ICC profile in which case its faster,
but produces incorrect
results. So for many photographic images it probably should not be used
on those grounds
alone. I am not at all sure that's the issue in your case. It would
need investigation .
Can you send me (not the whole list) directly via email your test image.
phil DOT race AT sun DOT com
-phil.
[EMAIL PROTECTED] wrote:
I've run some tests and concluded that JPEGCodec.createJPEGDecoder(new
FileInputStream(file)).decodeAsBufferedImage() is faster than
ImageIO.read(new File(file)) .
I have a test image that's 1978x2500 that loads in 375ms using
JPEGCodec and 735 ms using ImageIO. I set ImageIO.setUseCache(false).
Is there something I'm doing wrong or is the old package faster. I'm
writing an application to read images/slideshow, etc and speed is very
important. Do you have any tips or suggestions?
I'm running Java 6 u1 on Windows XP Media Center. 128MB VRAM, AMD
Athlon 3800 Dual Core X2, 1GB RAM.
Thanks in advance,
Carl Antaki
[Message sent by forum member 'carcour' (carcour)]
http://forums.java.net/jive/thread.jspa?messageID=211620
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST. For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Retiring the package com.sun.image.codec.jpeg
Thanks Phil. I tried it. It it is a faster but not as fast as the old library. It still looks to me that at 400ms this is slow. Shouldn't it be possible to make a multi threaded image reader. Do you know what is really taking most of this time? I have read somewhere that the C library used is not efficient and that the Intel library is faster. Carl [Message sent by forum member 'carcour' (carcour)] http://forums.java.net/jive/thread.jspa?messageID=212003 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Retiring the package com.sun.image.codec.jpeg
I tried it. what is the percentage differential you measure? I trust you ran a benchmark which ran a loop of (say) 50 times? I have read somewhere that the C library used is not efficient and that the Intel library is faster. no idea what that's about. Both APIs use the same C lib. Its the IJG lib which is very widely used and hopefully easily optimised by C compilers. Did you try the jai tools version of image i/o? That has some different code .. supposedly faster. -phil. [EMAIL PROTECTED] wrote: Thanks Phil. I tried it. It it is a faster but not as fast as the old library. It still looks to me that at 400ms this is slow. Shouldn't it be possible to make a multi threaded image reader. Do you know what is really taking most of this time? I have read somewhere that the C library used is not efficient and that the Intel library is faster. Carl [Message sent by forum member 'carcour' (carcour)] http://forums.java.net/jive/thread.jspa?messageID=212003 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Retiring the package com.sun.image.codec.jpeg
There may be some differences in the way that the two APIs process the image. For example I noted recently that the old com.sun.image.codec,jpeg is completely ignorant of an APP2 marker with an ICC profile in which case its faster, but produces incorrect results. So for many photographic images it probably should not be used on those grounds alone. I am not at all sure that's the issue in your case. It would need investigation . Can you send me (not the whole list) directly via email your test image. phil DOT race AT sun DOT com -phil. [EMAIL PROTECTED] wrote: I've run some tests and concluded that JPEGCodec.createJPEGDecoder(new FileInputStream(file)).decodeAsBufferedImage() is faster than ImageIO.read(new File(file)) . I have a test image that's 1978x2500 that loads in 375ms using JPEGCodec and 735 ms using ImageIO. I set ImageIO.setUseCache(false). Is there something I'm doing wrong or is the old package faster. I'm writing an application to read images/slideshow, etc and speed is very important. Do you have any tips or suggestions? I'm running Java 6 u1 on Windows XP Media Center. 128MB VRAM, AMD Athlon 3800 Dual Core X2, 1GB RAM. Thanks in advance, Carl Antaki [Message sent by forum member 'carcour' (carcour)] http://forums.java.net/jive/thread.jspa?messageID=211620 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Retiring the package com.sun.image.codec.jpeg
I've run some tests and concluded that JPEGCodec.createJPEGDecoder(new FileInputStream(file)).decodeAsBufferedImage() is faster than ImageIO.read(new File(file)) . I have a test image that's 1978x2500 that loads in 375ms using JPEGCodec and 735 ms using ImageIO. I set ImageIO.setUseCache(false). Is there something I'm doing wrong or is the old package faster. I'm writing an application to read images/slideshow, etc and speed is very important. Do you have any tips or suggestions? I'm running Java 6 u1 on Windows XP Media Center. 128MB VRAM, AMD Athlon 3800 Dual Core X2, 1GB RAM. Thanks in advance, Carl Antaki [Message sent by forum member 'carcour' (carcour)] http://forums.java.net/jive/thread.jspa?messageID=211620 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Retiring the package com.sun.image.codec.jpeg
The package com.sun.image.codec.jpeg was added in JDK 1.2 (Dec 1998) as a non-standard way of controlling the loading and saving of JPEG format image files. It has never been part of the platform specification and is not part of any compatibility test suite and so compatible Java implementations are not required to include it. The documentation for it has always been buried under a separate 'other API' heading, clearly distinct from the Java platform API specification. The intention was to replace it with a standard API. In JDK 1.4 (FCS/GA 2001) the Java Image I/O API was added (see JSR-15 at http://jcp.org/en/jsr/detail?id=15) as a standard API. This resides in the package javax.imageio. It provides a standard mechanism for controlling the loading and saving of sampled image formats and requires all compliant Java SE implementations to support JPEG as per the Image I/O specification. In JDK 6 to encourage migration to Image I/O several things happened. 1. All documentation of com.sun.image.codec.jpeg was removed although the classes are still present in *Sun* implementations - I can't speak for others - and probably only direct Sun licensees are likely to ship the API assuming they bother to do so. 2. When compiling code using these classes using JDK 6 a warning is emitted : warning: com.sun.image.codec.jpeg.JPEGCodec is Sun proprietary API and may be removed in a future release JPEGCodec.createJPEGDecoder(...); ^ 3. There were substantial performance improvements to Image I/O including JPEG, and overall the performance is now very similar between the two APIs. So we think its time to retire com.sun.image.codec.jpeg so we can focus on the single preferred standard API. However we are aware that applications do still use it, typically because they were written to run on JDK versions prior to 1.4, There are several options, not all exclusive : 1. Remove completely in JDK 7 - the most aggressive option. 2. Warn in JDK 7 release notes that it will be removed completely in JDK8 - this is really just incremental to the existing compilation warning 3. Make further javac changes in JDK 7 so that the classes are not located when compiling. ie the compilation warning turns into an error. Again, with this option the classes *are* still available at runtime so that code compiled with 1.6 or earlier will still find these classes and run on JDK 7 This preserves binary compatibility. 4. Remove the classes completely in a release after JDK 7 after a combination of notifications via release notes and compiler warnings/errors. Ideally this would then happen in JDK8 Implementing 2+3+4 comes down to using JDK 7 to provide a further period of grace to migrate and probably provides the right balance between notice and compatibility (to these non-standard, unsupported APIs). Particularly since JDK 6 already began this process. How long does this give people to migrate? Our historical run rate of releases is one every two years. JDK 1.2 - Dec 1998 ... JDK 6 Nov 2006 Management may try different models and so forth but I think that's a good enough estimate which predicts JDK7 - late 2008 JDK8 - late 2010 Does anyone think they have current code that uses com.sun.image.codec.jpeg that would have a problem with this proposed removal? Any comment on the options? FYI I am sending this to each of : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] so many of you may get this message several times. -Phil Race, Java 2D. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
