leonbloy/pngj

Compatibility with BufferedImage

Closed this issue · 6 comments

leonbloy commented

From dernashe...@gmail.com on May 15, 2013 03:07:59

I'm rewriting critical part of image processing from BufferedImage to pngj. However I prefer to leave BufferedImage in some image-processing parts of program.

I have the following flow:

  1. Load bufferedimage from bytes
  2. Copy line-by-line bytes from BufferedImage to .png file with alpha using pngj.

{{{
int[] array = new int[3];
bufferedImage.getRaster().getPixel(x, y, array);

    iline.scanline[j++] = array[0]; // R
    iline.scanline[j++] = array[1]; // G
    iline.scanline[j++] = array[2]; // B
    iline.scanline[j++] = 0xFF; // alpha

}}}

In the example above a have sample .jpg 24-bit image.
3. Check result .png is the same as input .jpg
4. Read result image with BufferedImage (for further processing).

Expected:
At step 4: The BufferedImage type is 2 (TYPE_INT_ARGB)

The actual result:
Depends on platform.
On Windows 7 (64bit): type is 0 (TYPE_CUSTOM)
On Linux (Ubuntu 12.04 64bit): type is 6 (TYPE_4BYTE_ABGR)

So I have several questions in here:

  1. How I could archive cross-platform compatibility? Is it something related to BufferedImage/awt native code?
  2. How I could specify for pngj the desired color order, ie. ARGB instead of RGBA?
  3. Why do I receive 4BYTE type in Linux instead of INT?

Original issue: http://code.google.com/p/pngj/issues/detail?id=25

leonbloy commented

From hgonzalez@gmail.com on May 15, 2013 04:33:58

ImageIO.read() returns a BufferedImage with an arbitrary type, you can't control that. The goal (rather different than PNGJ, which is lower-level) is to abstract you from the concrete raster format. If you want to work with a given predictable type (say, TYPE_INT_ARGB), you can convert it simply (but not very efficiently), see eg http://stackoverflow.com/a/10392050/277304 Currently PNGJ does not support other color order (or raster formats), it's by design decoupled from BufferedImage

BTW, this is not really an issue. Next time you have such a question you can ask in http://stackoverflow.com/ (include the png tag).

leonbloy commented

From hgonzalez@gmail.com on May 15, 2013 04:34:39

Status: Accepted
Owner: hgonzalez@gmail.com
Labels: -Priority-Medium Priority-Low

leonbloy commented

From dernashe...@gmail.com on May 15, 2013 04:52:38

Thank you for reply.

I agree that this is not an issue (google code cannot let me raise a question here).

As for convertion, this is exact what I'm trying to improve. The answer on stackoverflow suggests "new BufferedImage(...)" which generates 20Mb array of integers for ~2.2 Mb .png file. It's unacceptable for my project.

I'm trying to add alpha channel for non-alpha .png files.

leonbloy commented

From hgonzalez@gmail.com on May 15, 2013 04:55:33

Then I'd try to read the image with PNGJ instead of ImageIO.read() , and create the BufferedImage by hand (filling it with the data from PNGJ. Perhaps I'll add some support for this - the problem is that there are so many PNGJ color models and possible BufferedImage types, it's difficult to implement something general.

leonbloy commented

From dernashe...@gmail.com on May 22, 2013 22:59:18

I noticed, that type is 0 (TYPE_CUSTOM) for jdk1.6 only. FOr jdk1.7 type is 6 which is fine. Seems like issue in jdk's BufferedImage and PNGReader.

Also, converting from .jpg to .png using BuffferedImage gives the same result, which is type = 6.

So please close this issue.

leonbloy commented

From hgonzalez@gmail.com on May 23, 2013 07:43:51

Status: Invalid