ÇØ°áÃ¥Àº ¸ð¸£Áö¸¸, ¿øÀÎÀº ¾Ð´Ï´Ù.


[ ´ÙÀ½ ±Ûµé ] [ À̾ ±Û¿Ã¸®±â(´äÇϱâ) ] [ ÀÚ¹Ù ¹¯°í ´äÇϱâ ]

±Û¾´ÀÌ :È¥¼ö»óÅ 2000³â 5¿ù 23ÀÏ 12:26:08

In Reply to: [Áú¹®]´õºí ¹öÆÛ¸µ À̹ÌÁö°¡ ÆĶþ°Ô µÇ´Â ÀÌÀ¯? posted by ¹ÚÁ¾¼± on 2000³â 5¿ù 20ÀÏ 14:14:07:


Àúµµ ¶È°°Àº ¹®Á¦·Î °í»ýÇÏ°í ÀÖ´Â »ç¶÷ÀÔ´Ï´Ù.
Á¦°¡ ¾Æ´Â ¹Ù·Î´Â ÀÚ¹Ù°¡»ó¸Ó½ÅÀÇ Â÷ÀÌ Å¿ÀÔ´Ï´Ù.
±ÍÇÏÀÇ ¾ÖÇø´À» ´Ù¸¥ Àåºñ¿¡¼­ Å×½ºÆ®ÇØ º¸½Ê½Ã¿À.
±×·¡µµ ÆĶþ°Ô ³ªÅ¸³­´Ù¸é,
±× PCÀÇ ÀÚ¹Ù°¡»ó¸Ó½ÅÀ» MS º»»ç ȨÆäÀÌÁö¿¡¼­ ´Ù¿î·ÎµåÇؼ­,
ÀÚ¹Ù°¡»ó¸Ó½ÅÀ» ¾÷µ¥ÀÌÆ®¸¦ ÇØ º¸½Ã¸é ±¦ÂúÀ» °Ì´Ï´Ù.
ÇÏÁö¸¸, ÇÁ·Î±×·¡¸Ó ÀÔÀå¿¡¼­ º»´Ù¸é »ç¿ëÀÚ(º¸´Â ÀÌ)µé¿¡°Ô
°¡»ó¸Ó½ÅÀ» ÀÏÀÏÀÌ ¾÷µ¥ÀÌÆ®Ç϶ó°í ÇÒ ¼ö´Â ¾øÁö ¾Ê½À´Ï±î...

Á¦°¡ Á¶»çÇÏ´ø Â÷¿¡ ÇÁ·Î±×·¡¹ÖÀûÀ¸·Îµµ ÇØ°áÇÒ ¼ö ÀÖ´Â
°¡´É¼ºÀ» ¾Ë¾Æ³Â½À´Ï´Ù. pixelGrabberÀÇ Bug°¡ ÀÖ´Ù´Â Á¤º¸¿Í
¸î¸î ¾ÖÇø´¿¡¼­´Â À̸¦ ±³¹¦È÷ ÇÇÇسª°¡´Â ¹æ¹ýÀ» »ç¿ëÇÏ´Â
°ÍÀ¸·Î ¾Ð´Ï´Ù.

Àúµµ Á¤È®ÇÑ ÇØ°áÃ¥Àº ¸ð¸£¸ç, ´Ù¸¸ ÃßÃøÄÁ´ë...

1. MemoryImageSourceÀÇ setAnimated(true)¿Í, newPixels()¸¦ ÀÌ¿ëÇÏ´Â ¹æ¹ý.

2. pixelGrabber·Î ¾ò¾î³½ int[] ¹è¿­°ªµé¿¡ OR¿¬»ê(| 0xff000000)À» ÇÏ´Â ¹æ¹ý.

ÀÌ ÀÖ´Â °ÍÀ¸·Î ¾Ð´Ï´Ù¸¸ ½ÇÁ¦ ½ÃµµÇؼ­ ¸ðµÎ ½ÇÆÐÇß½À´Ï´Ù. T.T

¾Æ¿ï·¯,

http://developer.java.sun.com/developer/bugParade/bugs/4147328.html

½ã»ç¿¡¼­ ¿î¿µÇÏ´Â ¹ö±×¸®Æ÷Æ®¿¡µµ À§ ¹®Á¦°¡ ¾ð±ÞµÅ ÀÖ½À´Ï´Ù.
·Î±×ÀÎÀÌ ÇÊ¿äÇÑ °ü°è·Î Á¦°¡ Á÷Á¢ ±× ³»¿ëÀ» ¾Æ·¡¿¡ ÷ºÎÇÕ´Ï´Ù.


Bug Id 4147328

Votes 17

Synopsis Pixels extracted from an off-screen image using PixelGrabber use wrong palette

Category java:classes_awt

Reported Against 1.1.6

Release Fixed

State In progress, bug

Related Bugs

Submit Date Jun 10, 1998

Description This bug is WIN95 specific (it does not appear on NT). It manifests only when
a different color scheme is in effect (Control Panel -> Display -> Appearance)
for example Eggplant instead of Windows Default.


On JDK 1.2beta4H it still is a problem, however the distortion looks different.


// Demo of bug in JDK 1.1.5 & 1.1.6. (not in 1.2beta)
//
// Run under Win95 in 256-color mode, giving an image file as parameter.
// Any reasonably complex image will do (any image that needs dithering).
//
// The code:
// * loads the image,
// * allocates an off-screen image of the same size,
// * copies the loaded image onto it
// * extracts the pixel information from the off-screen image
// * creates a new image using this pixel info
// * displays this recreated image in a frame.
// Result:
// The image is displayed with the wrong palette
//
// Bug summary 1: Pixels extracted from an off-screen image using PixelGrabber
// in 256-color mode use a completely wrong palette.
//
// or, equivalently,
//
// Bug summary 2: the ImageProducer obtained from an off-screen image using
// getSource() in 256-color mode produces pixels using the wrong palette.
//


import java.awt.*;
import java.awt.image.*;
import java.awt.event.*;


public class PixelSource extends Frame
{
Image _img, img;
Insets _ins;


public PixelSource(String imgFile)
{
_ins = getInsets();
// Load image from file
img = Toolkit.getDefaultToolkit().getImage(imgFile);
MediaTracker mt = new MediaTracker(this);
mt.addImage(img, 1);
try {mt.waitForAll();} catch (InterruptedException e){}


// Display frame, so we can create off-screen images
setSize(640,480);
setVisible(true);


try { Thread.sleep(5000); } catch (InterruptedException e) {}
// Create an off-screen image of the same dimensions, and copy original
// image to it
Image backImg = createImage(img.getWidth(null), img.getHeight(null));
Graphics g = backImg.getGraphics();
g.drawImage(img, 0, 0, null);


// Extract pixel info from offscreen image
PixelGrabber pg = new PixelGrabber(backImg, 0, 0, -1, -1, true) ;
try
{
pg.grabPixels();
}
catch (InterruptedException e)
{
System.out.println("pixel grabber interrupted: " + e) ;
}
int[] pixels = (int[])pg.getPixels() ;


// Rebuild an image from this pixel info
MemoryImageSource mis =
new MemoryImageSource(pg.getWidth(), pg.getHeight(), pixels, 0,
pg.getWidth());
_img = Toolkit.getDefaultToolkit().createImage(mis);
_ins = getInsets();
repaint();
}



public void paint(Graphics g)
{
int y = _ins.top;
if (img != null) {
g.drawImage(img, _ins.left, y, this);
y += img.getHeight(this) + 10;
}
if (_img != null) {
g.drawImage(_img, _ins.left, y, this);
y += _img.getHeight(this) + 10;
}
}


public void update(Graphics g)
{
paint(g);
}


public static void main(String[] args)
{
Frame f = new PixelSource(args[0]);
f.addWindowListener(new WindowAdapter()
{public void windowClosing(WindowEvent ev) { System.exit(0);
}});
}
}


(Review ID: 33087)




Workaround Do not use windows 95, use NT instead or use more than 8bit/pixel color mode.




Evaluation None.

Your Comments & Work-arounds
(These are NOT written by Sun!)
Include a link with my name & email


Fri Sep 11 11:54:22 PDT 1998
ggendel



I've seen a similar situation under NT! Using
PixelGrabber on a Truecolor display, PixelGrabber
is returning Grayscale values. The code works
correctly under Solaris.



Fri Nov 06 20:40:51 PST 1998
moushengxu


I tried PixelGrabber.grabPixels(), the return code after
5 minutes is still 43 for a 338x600 image, while
ImageObserver.ALLBITS=32.
I did not have the patient to wait longer.
It's a surprise that a claimed-to-be image smart
language is so awkward in image handling.
-- Mousheng Xu



Thu Nov 12 14:50:25 PST 1998
TimLavers


This is a similar, simpler problem, that I have encountered
under NT. The following code gives different results on two
different NT machines!
public class FillRectTest {
public static void main ( String[] args ){
int width = 4;
int height = 3;
Frame kludge = new Frame();
kludge.setVisible( true );
kludge.show();
kludge.setForeground( Color.magenta );
Image offscreen = kludge.createImage( width, height );
Graphics g = offscreen.getGraphics();
System.out.println( "GRAPHICS COLOUR AFTER GETGRAPHICS: " +
g.getColor() );
Color back = Color.magenta;
System.out.println( "back = " + back );
System.out.println( "GRAPHICS COLOUR JUST BEFORE FILLING RECT: "
+ g.getColor() );
g.fillRect( 0, 0, width, height );
int[] pixelArray = new int[width * height];
int loop = width * height;
for (int i=0; i<loop; i++) {
pixelArray[i] = i;
}
PixelGrabber pgrab = new PixelGrabber( offscreen, 0, 0, width, height,
pixelArray, 0, width);
try {
pgrab.grabPixels();
} catch (InterruptedException ie) {
System.out.println(ie.toString());
}
for (int i=0; i<loop; i++) {
System.out.println( "Pixel colour " + i + ": "
+ (new Color(pixelArray[i])));
}
kludge.dispose();
}
}
On my machine, the output is:
back = java.awt.Color[r=255,g=0,b=255]
GRAPHICS COLOUR JUST BEFORE FILLING RECT: java.awt.Color[r=255,g=0,b=255]
Pixel colour 0: java.awt.Color[r=255,g=0,b=255]
Pixel colour 1: java.awt.Color[r=255,g=0,b=255]
Pixel colour 2: java.awt.Color[r=255,g=0,b=255]
....etc,
which is to be expected. On another machine in our
office, we get
java.awt.Color[r=255,g=255,b=255]
in place of
java.awt.Color[r=255,g=0,b=255].
Even if I compile the code on my machine, and then run it
on the other machine, the results differ. This happens
with JDK1.1.6, JDK1.1.7A but not with JDK1.2B4.
I guess the fact that it works with JDK1.2 is great and obviates
the need for a bug fix, but I'd really love to know why it
happens. P.S. My machine runs 65k colours or true colour
and gives the same results, the other machine gave the dodgy
result under true colour.
Any ideas would be welcome.



Tue Nov 17 15:56:52 PST 1998
mrhanson


I've had this problem under NT as well, using the test case provided by
TimLavers above. A workaround was to switch from 24 bit to 16 bit... then the
test case works properly.





´ÙÀ½ ±Ûµé:



À̾ ±Û¿Ã¸®±â(´äÇϱâ)

À̸§:
E-Mail:
Á¦¸ñ:
³»¿ë:
HTML ÅÂ±× Æ÷ÇÔ ¿©ºÎ: HTML ¹®¼­ÀÏ °æ¿ì üũ
°ü·Ã URL(¼±ÅÃ):
URL Á¦¸ñ(¼±ÅÃ):
°ü·Ã À̹ÌÁö URL:


[ ´ÙÀ½ ±Ûµé ] [ À̾ ±Û¿Ã¸®±â(´äÇϱâ) ] [ ÀÚ¹Ù ¹¯°í ´äÇϱâ ]