Skip to main content

[JAVA2D] Saving ARGB BufferedImages as JPEG with ImageIO

1 reply [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
J�rg Lehni

Dear Chris

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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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 listserv@java.sun.com and
>>>>>>>>>>> include in the body
>>>>>>>>>>> of the message "signoff JAVA2D-INTEREST". For general help,
>>>>>>>>>>> send email to
>>>>>>>>>>> listserv@java.sun.com and include in the body of the message
>>>>>>>>>>> "help".
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ==============================================================
>>>>>>>>>> ==== =========
>>>>>>>>>> To unsubscribe, send email to listserv@java.sun.com and
>>>>>>>>>> include in the body
>>>>>>>>>> of the message "signoff JAVA2D-INTEREST". For general help,
>>>>>>>>>> send email to
>>>>>>>>>> listserv@java.sun.com and include in the body of the message
>>>>>>>>>> "help".
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ===============================================================
>>>>>>>>> ==== ========
>>>>>>>>> To unsubscribe, send email to listserv@java.sun.com and
>>>>>>>>> include in the body
>>>>>>>>> of the message "signoff JAVA2D-INTEREST". For general help,
>>>>>>>>> send email to
>>>>>>>>> listserv@java.sun.com and include in the body of the message
>>>>>>>>> "help".
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> =================================================================
>>>>>>> ==== ======
>>>>>>> To unsubscribe, send email to listserv@java.sun.com and include
>>>>>>> in the body
>>>>>>> of the message "signoff JAVA2D-INTEREST". For general help,
>>>>>>> send email to
>>>>>>> listserv@java.sun.com and include in the body of the message
>>>>>>> "help".
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".