tuxpaint-devel

[Tuxpaint-devel] some more investigation on grass plugin

[Alessandro P. <apa...@gm...>]

Hi,

I'm still having problem but maybe I've found where to look for errors.

I seems like the function getpixel() return wrong values.

If I've got it right, the plugin reads a rgba pixel value from
grass_data.png, then applies some transformations on that value and
draws the new pixel on the canvas.

I put some printf in the code

printf("Getpixel %d %d img_grass rgba : %d %d %d %d\n", xx + src.x, yy
+ src.y, r, g, b, a);

and I see this output (alternatively):

Getpixel 124 63 img_grass rgba : 82 180 0 0
Getpixel 125 63 img_grass rgba : 17 0 0 0

the pixel values in the image have a fixed rgb and a variable alpha
channel, the bytes are hence

82 180 17 xx

where xx is the alpha and changes from 0% to 100% among the image.

Perhaps the problem is the following:

the api passes to the plugin a getpixel function pointer chosen from
the getpixels pool with the canvas color depth, which could be
different from the color depth of the image.

Since I'm running the test in a Xephyr maemo SDK emulator, the color
depth is probably lower than a standard true color X display.

Any comment?

-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Albert C. <aca...@gm...>]

On Dec 10, 2007 10:53 AM, Alessandro Pasotti <apa...@gm...> wrote:

> the api passes to the plugin a getpixel function pointer chosen from
> the getpixels pool with the canvas color depth, which could be
> different from the color depth of the image.
>
> Since I'm running the test in a Xephyr maemo SDK emulator, the color
> depth is probably lower than a standard true color X display.

Maybe we need two getpixel functions. Maybe we need to go
back to the old way, where the getpixel function looks at the
surface to determine the type. The decision could be made with
an array of function pointers or with if..else; best performance
will depend on the CPU. Some things to consider are:

If the user data is not kept as 8:8:8, it will get mangled when
the drawings are opened and saved. Mangling data is rude.

Keeping data in 8:8:8 format requires more memory.

We need 8:8:8 when we want to add an alpha channel.
(it is of course 8:8:8:8 then) We thus can not escape
dealing with this format, even if we wish to.

Working with 8:8:8 data is generally fast. This is because
the CPU can address individual bytes, but can not address
the components of a 5:5:5 or 5:6:5 pixel.

A rapidly declining number of systems use a display depth
that is not 8:8:8.

We can not avoid color problem if we use 5:6:5. There are
operations, such as blur, that will tend to make things turn
purple or green if the number of bits is not balanced.

For internal use, 16:16:16 has some advantages. It can hold
8:8:8 sRGB while being linear. This would let us avoid conversion
to float in various places.

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Alessandro P. <apa...@gm...>]

2007/12/11, Albert Cahalan <aca...@gm...>:
> On Dec 10, 2007 10:53 AM, Alessandro Pasotti <apa...@gm...> wrote:
>
> > the api passes to the plugin a getpixel function pointer chosen from
> > the getpixels pool with the canvas color depth, which could be
> > different from the color depth of the image.
> >
> > Since I'm running the test in a Xephyr maemo SDK emulator, the color
> > depth is probably lower than a standard true color X display.
>
> Maybe we need two getpixel functions. Maybe we need to go
> back to the old way, where the getpixel function looks at the
> surface to determine the type.

Thanks Albert for the insight, so do you agree that we have a bug here?

I'm sorry but I dont' feel skilled enough to fix this problem, I agree
with you that low color depth is quite rare nowaday, but I'm trying to
port tp to a Linux embedded device wich probaly has limited graphics
capabilities.

The strange thing is that the previous version .17 is working fine on
this device (just a bit slow with grass tool).

Can anybody help to solve this problem? I really like the grass tool
and I don't want to leave it out.

Many thanks in advance.

-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Albert C. <aca...@gm...>]

On Dec 11, 2007 12:24 PM, Alessandro Pasotti <apa...@gm...> wrote:
> 2007/12/11, Albert Cahalan <aca...@gm...>:
> > On Dec 10, 2007 10:53 AM, Alessandro Pasotti <apa...@gm...> wrote:
> >
> > > the api passes to the plugin a getpixel function pointer chosen from
> > > the getpixels pool with the canvas color depth, which could be
> > > different from the color depth of the image.
> > >
> > > Since I'm running the test in a Xephyr maemo SDK emulator, the color
> > > depth is probably lower than a standard true color X display.
> >
> > Maybe we need two getpixel functions. Maybe we need to go
> > back to the old way, where the getpixel function looks at the
> > surface to determine the type.
>
> Thanks Albert for the insight, so do you agree that we have a bug here?

Sure.

> I'm sorry but I dont' feel skilled enough to fix this problem, I agree
> with you that low color depth is quite rare nowaday, but I'm trying to
> port tp to a Linux embedded device wich probaly has limited graphics
> capabilities.

Me too. The OLPC XO uses a 5:6:5 framebuffer. I'll probably
use 8:8:8 internally though. If I had a really fast CPU and not
much RAM, then I'd consider using 5:5:5 (not 5:6:5). I hate
that option though, because merely loading and saving an image
would reduce the colors.

> The strange thing is that the previous version .17 is working fine on
> this device (just a bit slow with grass tool).

Probably you changed VIDEO_BPP.

Maybe VIDEO_BPP should always be 32.
That's 8:8:8 with padding for alignment.
Lots of things can be simplified this way.

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Alessandro P. <apa...@gm...>]

2007/12/12, Albert Cahalan <aca...@gm...>:
> On Dec 11, 2007 12:24 PM, Alessandro Pasotti <apa...@gm...> wrote:
> > 2007/12/11, Albert Cahalan <aca...@gm...>:
> > > On Dec 10, 2007 10:53 AM, Alessandro Pasotti <apa...@gm...> wrote:
> > >
> > > > the api passes to the plugin a getpixel function pointer chosen from
> > > > the getpixels pool with the canvas color depth, which could be
> > > > different from the color depth of the image.
> > > >
> > > > Since I'm running the test in a Xephyr maemo SDK emulator, the color
> > > > depth is probably lower than a standard true color X display.
> > >
> > > Maybe we need two getpixel functions. Maybe we need to go
> > > back to the old way, where the getpixel function looks at the
> > > surface to determine the type.
> >
> > Thanks Albert for the insight, so do you agree that we have a bug here?
>
> Sure.

Do we have a bug tracking system and should I file this bug?

[...]

> > The strange thing is that the previous version .17 is working fine on
> > this device (just a bit slow with grass tool).
>
> Probably you changed VIDEO_BPP.

No, everything is the same SDK and same color depth.

>
> Maybe VIDEO_BPP should always be 32.
> That's 8:8:8 with padding for alignment.
> Lots of things can be simplified this way.
>


BTW I managed to make it work (quick and dirty hack):

in grass.c

#include "../../src/pixels.h"

then adjusted magic makefile to link pixels.o

and used getpixel32 on grass image instead of the getpixel passed by
the plugin api.

I'm complete newbie in SDL, but perhaps a good solution would be to
have a generic getpixel function wrapper and let this function decide
which getpixelXX function to call depending on the image type, is this
possible?

What do you think?


-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Alessandro P. <apa...@gm...>]

>
> BTW I managed to make it work (quick and dirty hack):
>
> in grass.c
>
> #include "../../src/pixels.h"
>
> then adjusted magic makefile to link pixels.o

With the same hack the calligraphy tool is working too.

In this case a putpixel32 is needed in addition to getpixel32.

I'm waiting for input before committing any change.

Regards.

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Bill K. <nb...@so...>]

On Wed, Dec 12, 2007 at 05:39:41PM +0100, Alessandro Pasotti wrote:
> 
> I'm complete newbie in SDL, but perhaps a good solution would be to
> have a generic getpixel function wrapper and let this function decide
> which getpixelXX function to call depending on the image type, is this
> possible?

That was what it was SUPPOSED to do, but I guess I botched it.
(Usually working from on a train, usually in a hurry.)

And yes, we have a bug tracker; see http://www.sf.net/projects/tuxpaint/

Thanks!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Alessandro P. <apa...@gm...>]

2007/12/12, Bill Kendrick <nb...@so...>:
> On Wed, Dec 12, 2007 at 05:39:41PM +0100, Alessandro Pasotti wrote:
> >
> > I'm complete newbie in SDL, but perhaps a good solution would be to
> > have a generic getpixel function wrapper and let this function decide
> > which getpixelXX function to call depending on the image type, is this
> > possible?
>
> That was what it was SUPPOSED to do, but I guess I botched it.
> (Usually working from on a train, usually in a hurry.)
>
> And yes, we have a bug tracker; see http://www.sf.net/projects/tuxpaint/

Bug filed:

https://sourceforge.net/tracker/index.php?func=detail&aid=1850170&group_id=66938&atid=516295


Thanks.
-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Bill K. <nb...@so...>]

On Thu, Dec 13, 2007 at 05:35:34PM +0100, Alessandro Pasotti wrote:
> 
> Bug filed:
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=1850170&group_id=66938&atid=516295

Thanks, I'll look into this as soon as I can.

-bill!