Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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  
  Java2D quality issues  (Read 3429 times)
0 Members and 1 Guest are viewing this topic.
Offline javazoid

Junior Duke




Where's Flender?


« Posted 2003-10-31 09:07:58 »

Java2D quality issues

hello,

I'm making deep use of java2d (I simply love it) for the creation of animated desktop video graphics and video titling.

During the development of my applications I have discovered a bug in drawImage() http://developer.java.sun.com/developer/bugParade/bugs/4916948.html that causes incorrect results when drawing images with a translation-only AffineTransform. I also found a workaround for the problem, but I still hope that SUN fixes it asap.

Now I'm facing a pair of issues of which can deeply impact the graphical output quality of any java2d program. Consider that we're drawing with the best rendering hints: interpolation, anti-aliasing etc.

1) drawImage() bilinear interpolation gives ugly results on ARGB images.

consider the 2x2 bitmap pixels :

           X0
           00

where X is completely transparent (let's say a transparent RED -> 0x00FF0000) and 0 is opaque (let's say an opaque WHITE -> 0xFFFFFFFF).

The pixel bilinear interpolation takes the color of the X pixel into consideration. That's completely wrong because the pixel is transparent. When drawing the bitmap at 0.5,0.5 over a clean graphics (0x00000000) the pixel interpolator of java2d gives ugly red artifacts.

2) draw() renders low-quality shapes.

An example: the on-screen quality a simple basicStroke'd text is far from being perfect with font sizes smaller than 30-40 points. Anyone can figure out this by simply comparing the results of java2d with a vector graphics package like CorelDraw.



And the question is: will the situation change in jdk1.5 ?

Cheers,

Michele Puccini - ClassX Development (mik@classx.it)
--

Offline tom
« Reply #1 - Posted 2003-10-31 11:39:27 »

1) This is the correct way of doing bilinear interpolation. The fix is of course to not have contrasting colors in the transparent areas.


Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2003-10-31 12:14:02 »

Isn't there a renderinghint that causes alpha to be treated in a special way?

Cas Smiley

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

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #3 - Posted 2003-10-31 13:53:58 »

Quote
1) This is the correct way of doing bilinear interpolation. The fix is of course to not have contrasting colors in the transparent areas.


Are you certain about that?

I would have expected that the interpolation of the colour data needs to account for the alpha data at the same time.
e.g.:
1  
2  
3  
4  
float L = 0.5; // Linear blend half way between the pixels
Cout = C1 * (L) + C2 *(1-L); // no alpha accounted for
float  F1 = L*(A1/(A1+A2)); // account for alpha
Cbetter = C1 * F1 + C2 * (1-F1); // no spill of transparent colours


I didn't test the above method.  Am I making sense?

Offline javazoid

Junior Duke




Where's Flender?


« Reply #4 - Posted 2003-11-01 08:45:47 »

Well, I posted a little test image:

http://www.classx.it/public/bilerp_test.png

Looking at the image it clearly appears how java2d takes the tint of the red transparent pixels into account. That's a wrong behaviour this causes ugly artifacts when drawing transformed-bilerped transparent images.

Comments ?

How does the new MacOSX java imlementation handle this ? I know that they redirect java2d calls on Quartz.

Cheers,

Mik

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #5 - Posted 2003-11-01 09:23:27 »

I don't know what the official spec for j2d is, but for OpenGL this is normal filtering behaviour. The colours are interpolated as normal, then the alpha in interpolated separatly and applied to the new colour. If you want the behaviour seen in PSP then you just need to duplicate the colours around the edge.

BTW, i'm pretty sure that PSP doesn't do bilinear filtering on its rotations, but it does do anti-aliasing which would give smoother edges like you're seeing.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline tom
« Reply #6 - Posted 2003-11-01 13:12:54 »

I reproduced your test images in both paint shop pro 8 and in java2d. But I got a pink edge in both psp as in java2d. How did you create your psp image?

This is what I did:
1. I programmed an image with the specified source image and source alpha. A wrote the image to disk using my tga saver. It's easier than finding out how to create the image in psp Smiley
2. loaded the tga in psp.
3. loaded mask from image alpha
4. added white layer behind loaded image.
5. rotated layer with loaded image a couple of degrees.
The result is a black square with a pink edge around it.

I took a quick look at the rendering hints, but found no way of removing the bleed without turning off filtering. I can be wrong though, I'm no java2d expert.

It is however possible in opengl. Here you use "glAlphaFunc(GL_EQUAL, 1)" (disclaimer: not tested, and can be wrong  :-/ ). This will remove any color bleed along with half of the opaque pixels bordering with transparent pixels. This will also give a hard edge, and will not look antialiased Sad

The solution is to not have a contrasting color at the bordering transparent pixels. It's even easy to write a routine that fixes the problem:
1  
2  
3  
4  
5  
6  
// use 8 neighbors, not 4
for each pixel in image {
 if (pixel.alpha is transparent) and (a neighboring pixel is opaque) {
  pixel.colorRGB = average color of neighboring opaque pixels
  }
}


Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #7 - Posted 2003-11-01 23:19:28 »

Quote

How does the new MacOSX java implementation handle this ? I know that they redirect java2d calls on Quartz.


I'm not 100% certain that the rotation will be done with quartz, but if you can point me to you test code I'll run it on my Mac and let you know the results.

Offline javazoid

Junior Duke




Where's Flender?


« Reply #8 - Posted 2003-11-02 15:51:36 »

Hi swpalmer,

here's an executable jar (very raw src included).

http://www.classx.it/public/bilerp_test.jar

Give it a run. Should work on MacOSX java ..

The test shows a pair of test graphics. The one at left is bilerped and you can notice those ugly red pixels around.

Cheers,

Mik

Offline javazoid

Junior Duke




Where's Flender?


« Reply #9 - Posted 2003-11-02 16:05:10 »

Quote
I reproduced your test images in both paint shop pro 8 and in java2d. But I got a pink edge in both psp as in java2d. How did you create your psp image?


1) Just donwload the java2d-rendered TGA pic from http://www.classx.it/public/txt.tga

2) load it in PSP

3) do a "selection/load from alpha channel"

4)  hit CTRL-C, create a new white image and hit CTRL-E

5) Rotate the selection with the deformation tool.

And.. yes, your pseudo-code looks correct. Now it's all up to the SUN Java2D team !!

Cheers,

Mik



Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline tom
« Reply #10 - Posted 2003-11-02 18:27:48 »

You are NOT using a transparent image in PSP!!! You are using a selection, which is a vector based shape. So you are comparing apples and oranges Smiley

Offline tom
« Reply #11 - Posted 2003-11-02 18:40:44 »

...and the pseudocode was ment for you Wink

Offline javazoid

Junior Duke




Where's Flender?


« Reply #12 - Posted 2003-11-03 05:09:23 »

Sorry tom, but I think you're wrong.

The outline you see is not a vector, but the edges of the non-transparent pixels. PSP doesn't mistake.

Cheers,

Mik


Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


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

Quote
Hi swpalmer,

here's an executable jar (very raw src included).

http://www.classx.it/public/bilerp_test.jar

Give it a run. Should work on MacOSX java ..


I tried, but the download kept timing out before it got started Sad

Offline javazoid

Junior Duke




Where's Flender?


« Reply #14 - Posted 2003-11-04 05:00:38 »

Gosh! Should work right now. It's only 6kb so I suppose it shouldn't take that much..  Grin

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #15 - Posted 2003-11-04 11:26:24 »

Works fine with no ugly fringes.  (Mac OS X 10.3)

http://www.vaxxine.com/canaan/java2d.png

Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #16 - Posted 2003-11-04 11:40:06 »

time for a bug report then Wink

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

Junior Duke




Where's Flender?


« Reply #17 - Posted 2003-11-05 05:15:23 »

Just another pic. This one compares Windows and MacOSX results.

http://www.classx.it/public/bilerp_test1.png

Offline tom
« Reply #18 - Posted 2003-11-05 08:24:47 »

Bilinear Interpolation Puzzle:
http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0110&L=java2d-interest&F=&S=&P=5800

Image scaling often loses transparency:
http://developer.java.sun.com/developer/bugParade/bugs/4475230.html

The fix is to use a BufferedImage of type TYPE_INT_ARGB_PRE.

Offline javazoid

Junior Duke




Where's Flender?


« Reply #19 - Posted 2003-11-05 12:21:31 »

Many thanks TOM.

Hiroshi Sato also pointed out that ARGB_PRE is somewhat tricky.

http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0110&L=java2d-interest&D=0&P=6112

An improvement is _required_ from SUN.

I'll try to apply the trick to my src and I'll let you know.

In any case, I've posted a bug report about this problem.

Cheers,

Mik

Offline javazoid

Junior Duke




Where's Flender?


« Reply #20 - Posted 2003-11-05 15:41:17 »

TOM & the others,

sadly that ARGB_PRE trick doesn't work at all.
I get even bad results. Bad luck :-/

Let's hope the win32 Java2D team will fix the bug asap.

Offline trembovetski

Senior Duke




If only I knew what I'm talking about!


« Reply #21 - Posted 2003-11-10 05:07:57 »

Well, it's not really a win32-specific issue (the bug is reproducible with -Dsun.java2d.noddraw=true, which pretty much disables any win32-specific hw acceleration), but the way our software loops do it. You don't see it on mac because they're doing it through hw.

Unfortunately, the bug is still there in current build of 1.5.
I'll see if our opengl pipeline on linux/solaris does any better tomorrow..
Offline javazoid

Junior Duke




Where's Flender?


« Reply #22 - Posted 2003-11-10 06:15:48 »

trembovetski,

as you know the bug deeply impacts the quality of all java2d-based programs and it's so sad to hear that it's also in 1.5.

How can I help to fix it for 1.4.3 and 1.5 ?

Cheers,

Mik

Offline trembovetski

Senior Duke




If only I knew what I'm talking about!


« Reply #23 - Posted 2003-11-11 01:21:15 »

Quote

How can I help to fix it for 1.4.3 and 1.5 ?


Well, let me just give you my paypal account =)

Seriously, though, you can vote on the bug. I'll let the engineer who works on this bug know about this thread.

As I've explained in some other thread, the bugs chosen to be fixed in patch releases (_01, _02, etc) have to be escalated, or considered extremely important (like security issues).  It also depends on how risky the fix is.
It can definitely be fixed in the next maintenance relelase (1.5.1), but it's still way off.

There's still some time left for 1.5, so it may get fixed, it depends on a number of factors (how risky is the fix, etc).

In any case, one thing you can do is to vote on the bug, be vocal on 1.5 beta feedback, and suggest a good business case for why this bug is important.
Offline javazoid

Junior Duke




Where's Flender?


« Reply #24 - Posted 2003-11-11 05:30:51 »

This kind of fix should not be _that_ risky  Wink

Seriously, how can I reach the 1.5 mail lists ?

Cheers,

Mik

Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #25 - Posted 2003-11-11 07:23:57 »

Theres no risk at all, so long as the coder doesn't c0ck up the fix Grin

Damn I should be in risk managment Wink

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
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.

Longarmx (39 views)
2014-10-17 03:59:02

Norakomi (30 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (28 views)
2014-10-15 16:18:58

TehJavaDev (57 views)
2014-10-14 00:39:48

TehJavaDev (58 views)
2014-10-14 00:35:47

TehJavaDev (48 views)
2014-10-14 00:32:37

BurntPizza (64 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (78 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!