Able to disable JOGL's PNG decoder?

We have imagery coming from many places and some of it is PNG interlaced and PNG indexed. We have no control over the format of this imagery. The built-in JOGL TextureIO PNG decoder does not support PNG interlaced or indexed, but ImageIO does (as did JOGL 1's TextureIO). Since ImageIO is a built-in fallback in TextureIO, we want to disable the JOGL PNG decoder so ImageIO is used. Is there a way to do this?

I am aware that we could use ImageIO ourselves and pass TextureIO a BufferedImage, but we're porting code from JOGL 1 that uses TextureIO in many places.

Hi

Simply use ImageIO with input streams until we update PNGJ (it supports interlaced and indexed PNG). Look at the documentation, you can build textures and texture data yourself, you can load the buffered images with ImageIO and use them to create your textures.

On 01/05/2013 02:32 AM, tag [via jogamp] wrote: Instead of using AWT's ImageIO, I like us to 'fix' outstanding issues w/ PNGJ.

We updated PNGJ 0.85 -> 1.12 (w/ interlace read support):
  <http://jogamp.org/git/?p=jogl.git;a=commit;h=921b33825340d27deec2883ded21cb7434decc94>
  <https://code.google.com/p/pngj/>

Hence you can use interlaced PNG input streams.

Please file a bug : 'Indexed PNGJ Support missing'

Reason: We provide PNG input streams w/o the requirement of AWT
to give you same experience on mobile and desktop devices.
The latter is our whole story!
This will also allow you and your customer to utilize WWJ2 w/ JOGL2
on environments w/o AWT (Android, headless, ..) if you support
NEWT and separate your renderer code.


~Sven

I've opened a bug about missing support for indexed color PNGs: https://jogamp.org/bugzilla/show_bug.cgi?id=660

Thank you for this complete bug report.

"It appears that the alpha channel is rendered instead of the indexed color channel."

There is no "alpha channel" in a PNG indexed image. What happens here is that the palette is being ignored by JOGL, and the pixels values (indexes into the palette) are interpreted as grayscale values - or, equivalently, a grayscale palette is being assumed. The current result (screenshot in the issue attachment) can be reproduced by this PNGJ-only code:

        public static void main(String[] args) {
                indexedToG("C:/temp/indexed.png","C:/temp/indexed2.png");
        }

        private static void indexedToG(String src, String tgt) {
                PngReader pngr =FileHelper.createPngReader(new File(src));
                ImageInfo imi1 = pngr.imgInfo;
                ImageInfo imi2 = new ImageInfo(imi1.cols,imi1.rows,8,false,true,false); // grayscale
                PngWriter pngw = FileHelper.createPngWriter(new File(tgt),imi2,false);
                for(int i=0;i<imi1.rows;i++) {
                        ImageLine line = pngr.readRow(i);
                        pngw.writeRow(line,i);
                }
                pngr.end();
                pngw.end();
        }


Hernan
https://code.google.com/p/pngj/

On 01/08/2013 03:21 PM, Hernan [via jogamp] wrote:
> "It appears that the alpha channel is rendered instead of the indexed color
> channel."
>
> There is no "alpha channel" in a PNG indexed image. What happens here is that
> the palette is being ignored by JOGL,

Yes, have to add code to 'explode' it to RGBA.

> and the pixels values (indexes into the
> palette) are interpreted as grayscale values - or, equivalently, a grayscale
> palette is being assumed. The current result (snapshot in the issue
> attachment) can be reproduced by this PNGJ-only code:

Thank you!

~Sven

Sven Gothel wrote

Yes, have to add code to 'explode' it to RGBA.

In case this helps, the logic (included transparency handling, which might come in the TRNS chunk, outside the palette)  is implemented in ImageLineHelper.palette2rgb, see SampleConvPalToTrueColor. The method returns a RGB or RGBA depending on wheter transparency is present, perhaps I should add a flag argument to force RGBA mode...

On 01/08/2013 03:50 PM, hernan [via jogamp] wrote:
>     Sven Gothel wrote
>     Yes, have to add code to 'explode' it to RGBA.
>
> In case this helps, the logic (included transparency handling, which might
> come in the TRNS chunk, outside the palette)  is implemented in
> ImageLineHelper.palette2rgb, see SampleConvPalToTrueColor
> <https://code.google.com/p/pngj/source/browse/pnjg/src/ar/com/hjg/pngj/test/SampleConvPalToTrueColor.java>.
> The method returns a RGB or RGBA depending on wheter transparency is present,

That information is very helpful, thank you very much Hernán!

> perhaps I should add a flag argument to force RGBA mode...

Not required by us, i.e. we serve it in either RGB or RGBA format
w/o modifications.

~Sven