nanogui: Thread: jpeg show

hi,
      I find a bug with jpeg show, If define FASTJPEG   0, then draw image would be leak some points or draw some bad points, FASTJPEG =1 is 256 colors ,it's normal. I think and test decode jpeg is right, may be draw pixel occur error, Any patch or suggestion can help me?
  I test load jpeg file and show as follow codes:
  if (!(ImageWid = GrLoadImageFromFile("./jpgdemo.jpg",0)) )
  {
   fprintf(stderr, "Can't load image file: %s\n", "./jpgdemo.jpg");
   exit(1);
  }
 GrDrawImageToFit(wid, gc, 0,0, 200,200, ImageWid);
  best regards 
    dq

		
---------------------------------
 雅虎1G免费邮箱百分百防垃圾信
 雅虎助手-搜索、杀毒、防骚扰  

:       I find a bug with jpeg show, If define FASTJPEG   0, then draw image
would be leak some points or draw some bad points, FASTJPEG =1 is 256 colors
,it's normal. I think and test decode jpeg is right, may be draw pixel occur
error, Any patch or suggestion can help me?

What format framebuffer are your running?  If you're
running palette mode, then the decode could not match
your loaded palette.  When FASTJPEG is set, then the
image decode always includes a palette, and it is
then reloaded when displayed.  The same problem
may occur if you're running a low res mode, like 332
truecolor.

Explain a little more about the "leak", as well as your
hardware fb format.

Regards,

Greg

I believe I have a similar problem with PNG images using TRUECOLOR565 on PC with VGA.
I do not think this has anything to do with PNG or JPEG but with conversions in nxutil.c::GrNewBitmapFromData() or somewhere in the area.

My problem is that my images (icons) have black edges and the background is transparent and the shown picture is correct except I get some extra or missing (I did not check which yet) black pixels at the image edges. I guess, with other color schemes the black pixels could be white.
Most of the time the problem is on the alternating scan lines and looks like this:
___xx+++xx___
____x+++xxx__
___xx+++xx___
____x+++xxx__

where '_' is background, 'x' is black part of image, '+' is other image data.
As you can see, the image is correctly lined up but the edges are wrong.
Could it be that the clipping rectangles for the scan lines are calculated wrong (sometimes off by one pixel)?

I was going to report this but I did not get to this problem yet.
I was fixing the: "[nanogui] Images not drawn (FLTK+nxlib app with nano-X)" bug.

Martin


-----Original Message-----
From: DQ ####@####.####
Sent: Friday, February 17, 2006 12:40 AM
To: Greg Haerr; ####@####.####
Subject: [nanogui] ??: Re: [nanogui] jpeg show


hi,greg:
      I test many times find only white color occur error, other color is right.
best regards
  dq
Greg Haerr ####@####.#### 写道：
  : I find a bug with jpeg show, If define FASTJPEG 0, then draw image
would be leak some points or draw some bad points, FASTJPEG =1 is 256 colors
,it's normal. I think and test decode jpeg is right, may be draw pixel occur
error, Any patch or suggestion can help me?

What format framebuffer are your running? If you're
running palette mode, then the decode could not match
your loaded palette. When FASTJPEG is set, then the
image decode always includes a palette, and it is
then reloaded when displayed. The same problem
may occur if you're running a low res mode, like 332
truecolor.

Explain a little more about the "leak", as well as your
hardware fb format.

Regards,

Greg

Martin -
    This sounds very close to the issue you
just fixed with GrNewBitmapFromData().  I would
investigate nxutil.c, there's a couple other functions
that do the same thing, but not for monochrome images.

The transparent color bug has been fixed, I'll send
you DQ's fix for older code (you're running CVS, right?)

WRT clipping regions, normally there are no clip regions
setup for images (although using FLTK, who knows).  Your
previous bug was related to FLTK using a mono image
for an icon, and using XSetClipMask to allow it to
be drawn in color.

Regards,

Greg


I believe I have a similar problem with PNG images using TRUECOLOR565 on PC
with VGA.
I do not think this has anything to do with PNG or JPEG but with conversions
in nxutil.c::GrNewBitmapFromData() or somewhere in the area.

My problem is that my images (icons) have black edges and the background is
transparent and the shown picture is correct except I get some extra or
missing (I did not check which yet) black pixels at the image edges. I
guess, with other color schemes the black pixels could be white.
Most of the time the problem is on the alternating scan lines and looks like
this:
___xx+++xx___
____x+++xxx__
___xx+++xx___
____x+++xxx__

where '_' is background, 'x' is black part of image, '+' is other image
data.
As you can see, the image is correctly lined up but the edges are wrong.
Could it be that the clipping rectangles for the scan lines are calculated
wrong (sometimes off by one pixel)?

I was going to report this but I did not get to this problem yet.
I was fixing the: "[nanogui] Images not drawn (FLTK+nxlib app with nano-X)"
bug.

Martin


-----Original Message-----
From: DQ ####@####.####
Sent: Friday, February 17, 2006 12:40 AM
To: Greg Haerr; ####@####.####
Subject: [nanogui] ??: Re: [nanogui] jpeg show


hi,greg:
      I test many times find only white color occur error, other color is
right.
best regards
  dq
Greg Haerr ####@####.#### 写道：
  : I find a bug with jpeg show, If define FASTJPEG 0, then draw image
would be leak some points or draw some bad points, FASTJPEG =1 is 256 colors
,it's normal. I think and test decode jpeg is right, may be draw pixel occur
error, Any patch or suggestion can help me?

What format framebuffer are your running? If you're
running palette mode, then the decode could not match
your loaded palette. When FASTJPEG is set, then the
image decode always includes a palette, and it is
then reloaded when displayed. The same problem
may occur if you're running a low res mode, like 332
truecolor.

Explain a little more about the "leak", as well as your
hardware fb format.

Regards,

Greg

---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####