Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (481)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (548)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Either PSP or Java has a broken gif codec :S  (Read 3291 times)
0 Members and 1 Guest are viewing this topic.
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Posted 2003-08-18 10:05:32 »

I've got here 2 gifs, identical in every way, *except* the bitmask color is at index 0 in image B, and index 12 in image A.

Image B loads fine, Image A *appears* to load fine.
However, when I apply a rotation tranform to it during drawing, I get an ugly opaque band across the top few rows of the image Huh
The color of the band is dependant on the color at palette entry 0 :S

And yes, I am absolutely positive it is not my code Wink
here are the 2 images

Image a =
Click to Play
Image b =
Click to Play


and the results of rotating the 2 images (using the *same* code) :-



1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
import java.awt.*;
import java.awt.image.*;
import java.awt.geom.*;
import javax.imageio.*;
import javax.swing.*;
public class GifTest extends JFrame
{
   BufferedImage a,b;
   public GifTest()
   {
      setDefaultCloseOperation(EXIT_ON_CLOSE);
      try
      {
         a = ImageIO.read(getClass().getResource("broken.gif"));
         b = ImageIO.read(getClass().getResource("fixed.gif"));
      }
      catch(Exception e){}
   }

   public void paint(Graphics g)
   {
      Graphics2D g2d = (Graphics2D)g;

      AffineTransform af = AffineTransform.getRotateInstance(Math.PI/4, 50,50);
      g2d.setTransform(af);
      g2d.drawImage(a,50,50,null);

      AffineTransform af2 = AffineTransform.getRotateInstance(Math.PI/4, 150,50);
      g2d.setTransform(af2);
      g2d.drawImage(b,150,50,null);
   }

   public static void main(String [] args)
   {
      GifTest gf = new GifTest();
      gf.setBounds(50,50,300,300);
      gf.show();
   }
}


Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Max Pesce

Junior Member




Nil tam arduum quod non ingenio vincas


« Reply #1 - Posted 2003-08-18 12:33:25 »

Very strange effect! Shocked

I've tried with PSP and you're right, probably it's a Java problem (I've always used the first color as transparent).

Probably with 256 colors Java will give different results...

I'm now using rotation in my new game using PNG images and no problem with color 0 as transparent.

I've tried using PNG images (4 bit) with 13th color as transparent, all is OK...

Maybe it's really a problem with GIF codec.
:-/

Offline campbell

Junior Member




Java games rock!


« Reply #2 - Posted 2003-08-18 18:19:41 »

Quote
I've got here 2 gifs, identical in every way, *except* the bitmask color is at index 0 in image B, and index 12 in image A.

Image B loads fine, Image A *appears* to load fine.
However, when I apply a rotation tranform to it during drawing, I get an ugly opaque band across the top few rows of the image Huh
The color of the band is dependant on the color at palette entry 0 :S

And yes, I am absolutely positive it is not my code Wink
here are the 2 images


Hi Abuse,

That looks like a bug to me, but I'm not sure whether it a Java 2D problem or an IIO bug.  Either way, it's something for our team to look at... So if you could submit a bug report (with your source code and images included), we'll be sure to check it out.

Thanks!
Chris
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #3 - Posted 2003-08-18 19:18:20 »

done.

I believe its a bug with ImageIO, cos if I load the same images with toolkit.createImage/MediaTracker, the problem goes away.

Which kinda suprised me actually, I would have thought both would have used the same underlying codec -
the AWT utility classes must be in a real mess Shocked

btw, are we going to see a mass-deprecation in 1.5, finally saying goodbye to all the old ways of creating/loading/managing and rendering of images?

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #4 - Posted 2003-08-18 20:21:11 »

The AWT image loading and the ImageIO loading are still very separate at this time, as far as I know.

Offline campbell

Junior Member




Java games rock!


« Reply #5 - Posted 2003-08-18 20:51:28 »

Quote
done.

I believe its a bug with ImageIO, cos if I load the same images with toolkit.createImage/MediaTracker, the problem goes away.

Which kinda suprised me actually, I would have thought both would have used the same underlying codec -
the AWT utility classes must be in a real mess Shocked

btw, are we going to see a mass-deprecation in 1.5, finally saying goodbye to all the old ways of creating/loading/managing and rendering of images?


Probably no deprecation in 1.5, but we've been trying to steer people away from those APIs for a while now.  IIO is definitely the preferred method for loading images, and we're doing everything we can to make it behave/perform as well as the old 1.1-era Toolkit image APIs.

Chris
Offline GergisKhan

Junior Member




"C8 H10 N4 O2"


« Reply #6 - Posted 2003-08-18 21:19:23 »

Chris, is there any chance in 1.5 that ImageIO will return "Managed" images?  Where they're automatically grabbing VRAM if/when appropriate?

gK

"Go.  Teach them not to mess with us."
          -- Cao Cao, Dynasty Warriors 3
Offline campbell

Junior Member




Java games rock!


« Reply #7 - Posted 2003-08-18 21:51:18 »

Quote
Chris, is there any chance in 1.5 that ImageIO will return "Managed" images?  Where they're automatically grabbing VRAM if/when appropriate?


What an excellent question... Smiley  The answer is an emphatic "yes".  We just completed that work a couple weeks ago, so that all BufferedImages (even those returned by ImageIO) can now be considered "managed images".  Of course, it's still best (as always) to use GraphicsConfig.createCompatibleImage() so that we pick the most optimal format for your device.  But at least now you don't have to go through trickery to get your IIO images "managed", as we take care of that for you under the hood.

I hope this makes things easier for you guys...

Chris
Offline GergisKhan

Junior Member




"C8 H10 N4 O2"


« Reply #8 - Posted 2003-08-18 22:39:42 »

OH YES!

Yeah, Chris, that helps.  Up on the Wiki is a tip on how to create a managed image from and ImageIO loaded image.  Essentially, as I am SURE You know, we end up redrawing the image we just loaded!

I appreciate the reply.

gK

"Go.  Teach them not to mess with us."
          -- Cao Cao, Dynasty Warriors 3
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #9 - Posted 2003-08-18 23:31:25 »

Quote


Of course, it's still best (as always) to use GraphicsConfig.createCompatibleImage() so that we pick the most optimal format for your device.


um.....so.... we are still going to have to copy the image into an 'optimal' managed image?

Can't we just specify where we intend to render the image at load time?

i.e.

1  
ImageIO.read(URL image, GraphicsConfiguration intendedDestination)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #10 - Posted 2003-08-19 02:54:03 »

There is already a way to specify loading into an already existing image.

Look up ImageReadParam.setDestination(BufferedImage);

You will have to use a ImageReader directly, rather than the ImageIO.read() method.

I was going to use this in a project at work, but unfortunately there are some leaks in ImageIO that caused huge problems for me... I needed to stream video as JPEGs (JMF is so flakey and worked so poorly that it was unusable). ImageIO seems to make a lot temp files that it never gets rid of. (Why it is making temp files at all is another question. Maybe I needed a setUseCache(false)? )  There is also a memory leak that happens when reusing a reader the only work around has other problems.
I was forced to go back to AWT image loading.. which is also buggy.. failing to decode occasionally where ImageIO had no problems.  Seems to be related to thinking it is done reading and yet the image isn't ready... sigh...

Oh yeah, why isn't there a ImageIO.read(ByteBuffer) method?  I had to do hacks to wrap my buffer with an InputStream

Offline campbell

Junior Member




Java games rock!


« Reply #11 - Posted 2003-08-19 03:23:11 »

Quote


um.....so.... we are still going to have to copy the image into an 'optimal' managed image?

Can't we just specify where we intend to render the image at load time?

i.e.

1  
ImageIO.read(URL image, GraphicsConfiguration intendedDestination)


I'm sorry, I wrote two completely separate thoughts in nearby sentences.

The first thought is:
BufferedImages are now all managed by default, so all you have to do is call ImageIO.read().  You can render the returned image immediately to any surface (other BufferedImages, the Swing backbuffer, the screen), and we'll cache that image in hardware as appropriate (it's "managed" under the hood, you don't have to worry about anything).  So no need to copy the image returned by IIO into another image.

The second thought is:
If you are creating an image yourself (say you want to do some custom rendering into it), and you will be rendering that image to a screen or backbuffer surface, it's still best to call GraphicsConfig.createCompatibleImage().  That's what we've been telling folks all along, and that remains unchanged.

Hopefully that clears up some confusion.  We really need to finish up that elusive "Java 2D Images Explained" document, which should be a good reference.  I know that the various image types and creation methods have been mysterious in the past.  This new managed image work should clear things up a bit, because the answer is always simply "BufferedImage".  No matter how it was created, or what ColorModel it uses, we'll try to accelerate it under the hood.

Chris
Offline campbell

Junior Member




Java games rock!


« Reply #12 - Posted 2003-08-19 03:42:25 »

Quote

I was going to use this in a project at work, but unfortunately there are some leaks in ImageIO that caused huge problems for me... I needed to stream video as JPEGs (JMF is so flakey and worked so poorly that it was unusable). ImageIO seems to make a lot temp files that it never gets rid of. (Why it is making temp files at all is another question. Maybe I needed a setUseCache(false)? )


Yes, if you call setUseCache(false), we won't create a temp file (in some cases, the temp file can help improve performance, but in your case you'll be reading so many images that it's best to disable the cache).

Quote

There is also a memory leak that happens when reusing a reader the only work around has other problems.
I was forced to go back to AWT image loading.. which is also buggy.. failing to decode occasionally where ImageIO had no problems.  Seems to be related to thinking it is done reading and yet the image isn't ready... sigh...


I think there may be one or two outstanding bugs related to "leaks" in JPEGImageReader reuse that were fixed for 1.5... Are you calling ImageReader.reset() between each reuse?  That should ensure that the reader cleans up any resources used for the last image decoding.

Quote

Oh yeah, why isn't there a ImageIO.read(ByteBuffer) method?  I had to do hacks to wrap my buffer with an InputStream


Hmm... You might want to look at the new JAI/IIO Tools package, which includes a couple Image{In/Out}putStreams based on NIO:
http://java.sun.com/products/java-media/jai/forDevelopers/jai-imageio-1_0-rc-docs/com/sun/media/imageio/stream/package-summary.html

If this doesn't suit your needs, or if you have any ideas about how NIO/IIO interaction could be made easier for developers, please submit an RFE.

Thanks,
Chris
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #13 - Posted 2003-08-19 14:31:43 »

Quote
Are you calling ImageReader.reset() between each reuse?  That should ensure that the reader cleans up any resources used for the last image decoding.

That was the 'workaround'.. the problem is that the performance degrades way too much...
http://developer.java.sun.com/developer/bugParade/bugs/4867874.html
and the original problem:
http://developer.java.sun.com/developer/bugParade/bugs/4868479.html

Quote
Hmm... You might want to look at the new JAI/IIO Tools package, which includes a couple Image{In/Out}putStreams based on NIO:
http://java.sun.com/products/java-media/jai/forDevelopers/jai-imageio-1_0-rc-docs/com/sun/media/imageio/stream/package-summary.html


Thanks I wasn't aware that NIO ImageIO streams were part of that package.  I may be able to use that if the overall leaks/speed issues can be solved.

IMHO the JPEG decoder should be using SSE2 instructions on Intel (where available) since it will result in a drastic performance increase..  It seems you are using a vanilla C JPEG decoder or something.  The time spent decoding images for what I was doing was just WAY out there - I'm talking an order of magnitude slower than it should be.  Intel makes a nice JPEG library that works well, and is free as far as I know.  (It is what I am using on my encoding side in my video streaming application, since I needed native code to fetch the images from hardware anyway, I just fetch "JPEG" buffers.)

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #14 - Posted 2003-08-19 18:57:28 »

I just checked out that NIO stuff for ImageIO.  I see that it will make an ImageInputStream from a ReadableByteChannel, but not a ByteBuffer.  Looking at the various implementations of ReadableByteChannel, I don't see one that works like a ByteArrayInputStream but on a ByteBuffer instead, so it won't be that simple to make this work for my purposes.
There is a ByteArrayImageSource in AWT, but no ByteBufferImageSource for either AWT or ImageIO.
For AWT I can back my ByteBuffer with an array and coax AWT into reading my image.  For ImageIO I have to jump through a couple extra hoops to do that.  A more direct path to the ByteBuffer for ImageIO is what I want. (along with the memory leak fixed Smiley )

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (26 views)
2014-08-19 09:29:53

Tekkerue (24 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (14 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (60 views)
2014-08-11 02:49:23

BurntPizza (38 views)
2014-08-09 21:09:32

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!