I tried out the workaround and I must say I was not very happy witht the results. The size still differs quite a lot.
But I now found another workaround which seems much more straight forward and gives perfect results:
Instead of masking bands with imageio, I use a child WriteableRaster of the BufferedImage that doesn't use the alpha band and then create a new BufferedImage based on this raster. This BufferedImage is then used to export to a proper JPEG:
// argbBuffer is the ARGB Image that should be written as JPEG:
WritableRaster raster = argbBuffer.getRaster();
WritableRaster newRaster = raster.createWritableChild(0, 0, width, height, 0, 0, new int[] {0, 1, 2});
// create a ColorModel that represents the one of the ARGB except the alpha channel:
DirectColorModel cm = (DirectColorModel)argbBuffer.getColorModel();
DirectColorModel newCM = new DirectColorModel(cm.getPixelSize(), cm.getRedMask(), cm.getGreenMask(), cm.getBlueMask());
// now create the new buffer that is used ot write the image:
BufferedImage rgbBuffer = new BufferedImage(newCM, newRaster, false, null);
J�rg
Am 16.04.2004 um 00:29 schrieb Chris Campbell:
Hi J�rg,
One of our engineers has devised a workaround for this workaround that should work with 1.4.x... It's not optimal, but it is better than the current situation.
The source code for the workaround should show up soon at: http://developer.java.sun.com/developer/bugParade/bugs/5028259.html
(It's not there yet, but will be soon.)
Thanks, Chris
On Apr 8, 2004, at 4:03 AM, J�rg Lehni wrote:Hi Chris,
Very nice, thank you!
Do you think there will be a workaround for current versions of java 1.4 and higher? One that is better than just copying the whole buffer into a RGB BufferedImage before exporting?
I'm asking you because my code will be used in a web application framework (www.helma.org) that is used by quite a few people. I can't ask all of them to install the latest and greatest java version in the future.
I also tried to find bug report 5028259 on http://developer.java.sun.com/developer/bugParade/ without luck. I guess it's not available yet?
J�rg
Am 08.04.2004 um 00:53 schrieb Chris Campbell:
Hi J�rg,
Yes, one of our IIO engineers has looked into this issue and has discovered the cause of the large file sizes for sub-banded JPEG images. He has filed bug report 5028259 for this issue, and has some ideas about how to fix it. It is unlikely that we will be able to get a fix in for 1.5 at this point, but it will be on the list for an update release.
Thanks for reporting this issue. Chris
J�rg Lehni wrote:Dear Chris.
I was wondering wether there was some progression to this problem. Did you have the time to find out more?
Best regards
J�rg
Am 25.03.2004 um 22:19 schrieb Chris Campbell:Hi J�rg,
The output.jpeg file you sent displays properly when viewed with ImageIO, Safari, Mac OS X Preview.app, Netscape 7, and other viewers. It doesn't look correct when viewed with some native viewers, such as xv. So I still believe that side of the issue is related to 4836466 (even though the resulting image does not have an alpha channel).
However, that doesn't explain why we would create a non-standard JPEG file ("non-standard" in the sense that the file size is much larger than expected). It probably has to do with the resulting having a non-sRGB ColorSpace. We can investigate this further to see why the JPEGImageWriter is creating a strange file for what is essentially an INT_RGB image. I'll follow up with you soon.
Chris
On Mar 25, 2004, at 5:25 AM, J�rg Lehni wrote:
Ok, here's the file and a testcase. The app loads an image from the internet, draws it into a ARGB BufferedImage and saves this as a new Jpeg, trying to to get the codec to ignore tha alpha channel.
I'll post this message without attachments to the list as well.
J�rg
<JpegBug.java> <output.jpeg>
Am 23.03.2004 um 20:20 schrieb Chris Campbell:
On Mar 23, 2004, at 11:07 AM, J�rg Lehni wrote:
I do not agree.
Okay. Like I said, please send me (off the list) a small testcase that reproduces the problem. Code snippets are not enough; we prefer to see a full testcase that we can compile easily and run.
If you're interested I can send you on of those images for analysis.
Yes, that would be very helpful, in addition to the testcase.
Thanks, Chris
Best
J�rg
Am 23.03.2004 um 19:40 schrieb Chris Campbell:
Hi J�rg,
This sounds a lot like 4836466, which we closed as "not a bug". See the report for more details:
http://developer.java.sun.com/developer/bugParade/bugs/ 4836466.html
Basically, it appears that many native apps have poor support for JPEG images with an alpha channel. If you can read back one of these images using IIO (ImageIO.read()) and everything displays properly, I'd say your issue is related to 4836466. If not, send me a small testcase containing your sample code (off the list) and I can take a look. Maybe there's a separate issue lurking out there...
Thanks, Chris
On Mar 22, 2004, at 12:39 PM, J�rg Lehni wrote:
Thanks Jim!
That's how my latest code looks like, i simplified it a lot:
param.setSourceBands(new int[] {0, 1, 2});
param.setDestinationType(
ImageTypeSpecifier.createPacked(ColorSpace.getInstance(ColorSp ace. CS_sRGB),
0x00ff0000,
0x0000ff00,
0x000000ff,
0x0,
DataBuffer.TYPE_INT,
false
)
);
But it still produces the same problems. The resulting jpeg files are strange, don't display correctly in some viewers and get much bigger in size than necessary.
If I use the workaround of copying the TYPE_INT_ARGB BufferedImage into a TYPE_INT_RGB BufferedImage and then generate the JPEG by just using the default settings, everything works fine.
It looks to me as if there is a bug in the JPEG codec.
What do you think?
J�rg
Am 17.03.2004 um 01:55 schrieb Jim Graham:
An image of TYPE_INT_ARGB uses a PackedColorModel with a Packed
Raster with a TYPE_INT DataBuffer. It is incompatible with the
Byte-based ComponentColorModel (and SampleModel) that you are
creating. I'm not sure how these two pieces of data would
interact in this case...
...jim
--On 03/15/04 22:40:12 +0100 J�rg Lehni wrote:
if (bi.getType() == BufferedImage.TYPE_INT_ARGB) {
// create a new ColorModel with OPAQUE transparency and no
alpha channel.
ColorModel cm = new
ComponentColorModel(bi.getColorModel().getColorSpace(), false, false,
Transparency.OPAQUE, DataBuffer.TYPE_BYTE);
============================================================= ==== ==========
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".
================================================================= ==== ======
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".
