Problem loading png on Mac OS 10.7.3 using latest Hg version

[Winston]

Images don't render on my machine. I wonder if others are having this
problem? I've tracked the problem down to the QuartzImageDecoder--it
returns image data of all zeros. If I delete that decode and use the
pyglet.image.codecs.png.PNGImageDecoder, it works. Any ideas on this
problem?

The commit of Pyglet I'm using is in HG:
67[tip] d88c2ed1d638 2012-03-03 22:05 -0800 winstonw
Working on python2.7 64-bit by using Pyglet 1.2dev and pyobjc v2.2

Mac OS X 10.7.3

Below is a test-program that illustrates the problem, and here is the
output:
-------------
% python /tmp/tspyglet.py
Demonstration of failing PNG decoder on Mac OS 10.7.3
Here are the current image decoders available, and the ones for PNGs:
get_decoders: [<pyglet.image.codecs.quartz.QuartzImageDecoder
object at 0x10b2a9050>, <pyglet.image.codecs.png.PNGImageDecoder
object at 0x10b2a9390>, <pyglet.image.codecs.dds.DDSImageDecoder
object at 0x1087d3450>, <pyglet.image.codecs.bmp.BMPImageDecoder
object at 0x10b2a9490>]
_decoder_extensions[.png]=
[<pyglet.image.codecs.quartz.QuartzImageDecoder object at
0x10b2a9050>, <pyglet.image.codecs.png.PNGImageDecoder object at
0x10b2a9390>]

Load an image using the default decoder, i.e. QuartzImageDecoder.
Notice that the returned Image
has zeros for it's data.
raw png data: '\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x01,'
image data:
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

Now remove the QuartzImageDecoder so we use the
pyglet.image.codecs.png.PNGImageDecoder.
It creates good Image.data
_decoder_extensions[.png]=
[<pyglet.image.codecs.png.PNGImageDecoder object at 0x10b2a9390>]
raw png data: '\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x01,'
image data: '\xff\xff\xff\x00\xff\xff\xff\x00\xff\xff\xff\x00\xff
\xff\xff\x00\xff\xff\xff\x00'
---------------
import pyglet
window = pyglet.window.Window()
filename = ('/tmp/SimpsonsWinston.png')

print '''Demonstration of failing PNG decoder on Mac OS 10.7.3
Here are the current image decoders available, and the ones for
PNGs:'''
print ' get_decoders:', pyglet.image.codecs.get_decoders(filename)
print ' _decoder_extensions[.png]=',
pyglet.image.codecs._decoder_extensions['.png']

print '''
Load an image using the default decoder, i.e. QuartzImageDecoder.
Notice that the returned Image
has zeros for it's data.'''
image = pyglet.image.load(filename)
print ' raw png data:', repr(open(filename).read()[:20])
print ' image data:', repr(image.data[:20])

print '''
Now remove the QuartzImageDecoder so we use the
pyglet.image.codecs.png.PNGImageDecoder.
It creates good Image.data'''
del pyglet.image.codecs._decoder_extensions['.png'][0]
print ' _decoder_extensions[.png]=',
pyglet.image.codecs._decoder_extensions['.png']
image = pyglet.image.load(filename)
print ' raw png data:', repr(open(filename).read()[:20])
print ' image data:', repr(image.data[:20])



# @window.event
# def on_draw():
# window.clear()
# image.blit(10, 10)

# pyglet.app.run()

[Phillip Nguyen]

> Load an image using the default decoder, i.e. QuartzImageDecoder.

>     raw png data: '\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x01,'

>     image data: '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00'

>
> Now remove the QuartzImageDecoder so we use the
> pyglet.image.codecs.png.PNGImageDecoder.

>     raw png data: '\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x01,'
>     image data: '\xff\xff\xff\x00\xff\xff\xff\x00\xff\xff\xff\x00\xff\xff\xff\x00\xff\xff\xff\x00'

The QuartzImageDecoder premultiplies the color components by their
alpha value during the decoding process. Unfortunately, there doesn't
seem to be any alternative in cocoa to premultiplying alpha if you
also want to be able to handle image data that might not be in nice
formats. The pixels that you are looking at have zero alpha value,
and so they become all zeros. You should be able to still render the
image however. What happens when you run

python image_display.py pyglet.png

in the pyglet/examples directory?

--phillip

[Winston Wolff]

Hi Phillip-

Thanks for taking the time to examine my problem. My example then is probably a bad one because the corners are indeed transparent, but there are non-transparent pixels later on. 

What happens when you run

python image_display.py pyglet.png

Attached is a screenshot which shows that pyglet.png does not show up when rendered by pyglet, but does appear with Preview.app.

Winston Wolff
Stratolab - Games for Learning
tel: (917) 543 8852
web: www.stratolab.com

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To post to this group, send email to pyglet...@googlegroups.com.
To unsubscribe from this group, send email to pyglet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.

[Winston Wolff]

I've spent another day digging into this problem. I made a test png with just four pixels so I can see the data. It is indeed being decoded as all zeros.

I was able to get QuartzImageDecoder to work one time, but I can't reproduce it. I was experimenting running the OSX default python2.6 instead of my framework build 2.7.2 in virtualenv.

I'm using virtualenv and pyobjc v2.2. Does anybody know of incompatibilities with pyglet, virtualenv, and pyobjc2.2?

Winston Wolff
Stratolab - Games for Learning
tel: (917) 543 8852
web: www.stratolab.com

On Apr 6, 2012, at 5:27 PM, Winston Wolff wrote:

> Hi Phillip-
>
> Thanks for taking the time to examine my problem. My example then is probably a bad one because the corners are indeed transparent, but there are non-transparent pixels later on.
>
>> What happens when you run
>> python image_display.py pyglet.png
>
> Attached is a screenshot which shows that pyglet.png does not show up when rendered by pyglet, but does appear with Preview.app.
>
> Winston Wolff
> Stratolab - Games for Learning
> tel: (917) 543 8852
> web: www.stratolab.com

> <image_display_of_pyglet_png.png>

[Phillip Nguyen]

On Apr 13, 7:29 pm, Winston Wolff <winst...@stratolab.com> wrote:
> I've spent another day digging into this problem. I made a test png with just four pixels so I can see the data. It is indeed being decoded as all zeros.
>
> I was able to get QuartzImageDecoder to work one time, but I can't reproduce it. I was experimenting running the OSX default python2.6 instead of my framework build 2.7.2 in virtualenv.
>
> I'm using virtualenv and pyobjc v2.2. Does anybody know of incompatibilities with pyglet, virtualenv, and pyobjc2.2?

Winston,

Could you send me your test png image and I'll see what happens on my
end. Also could you try running your example with the evil-phillip-
cocoa-ctypes2 pyglet clone here:

http://code.google.com/r/evilphillip-cocoa-ctypes2/

and see if there is any difference? Pyglet has issues with PyObjC
2.2. However it works with the default PyObjC installed with OS X
10.6 which is version 2.2b3 (beta 3). If you're using your own
installation of pyobjc, you should try to use version 2.3 or greater.
If it does turn out to be a PyObjC issue, I can possibly rewrite the
quartz image decoder to not use it.

--phillip

[Winston Wolff]

Hi Phillip-

Attached is my test png -- 2x2 pixels (It's really small):

I'll try out your code next Friday. Thanks.

Winston Wolff
Stratolab - Games for Learning
tel: (917) 543 8852
web: www.stratolab.com

[AdamGriffiths]

I've had issues with the Quartz loader too (same versions as you, OS-X
Lion, Py2.7.2, pyglet from HG head, pyobjc2.2, virtualenv)
I've had dropped back to the PIL decoder for the time being.

Sorry for not adding anything constructive, just +1'ing the issue.

On Apr 15, 6:32 am, Winston Wolff <winst...@stratolab.com> wrote:
> Hi Phillip-
>
> Attached is my test png -- 2x2 pixels (It's really small):
>

[Winston Wolff]

Phillip--

Yay, your version of the quartz image loader works great! Thank goodness.

I'll just comment on a funny effect of the pre-multiplying, but I'm not complaining--your fix is great and I can start working on my prototype again. I have one image with a white background, but different alphas in different parts of the solid-white background as a result of erasing parts of my original image in my image editor. That makes funny dark lines appear. I can fix my image.

-Winston

[Winston Wolff]

Phillip--

Are there plans to roll this version of the quartz image decoder back into the regular pyglet repository?

>>>> http://code.google.com/r/evilphillip-cocoa-ctypes2/


-Winston

On Apr 20, 2012, at 10:41 AM, Winston Wolff wrote:

> Phillip--
>
> Yay, your version of the quartz image loader works great! Thank goodness.
>
> I'll just comment on a funny effect of the pre-multiplying, but I'm not complaining--your fix is great and I can start working on my prototype again. I have one image with a white background, but different alphas in different parts of the solid-white background as a result of erasing parts of my original image in my image editor. That makes funny dark lines appear. I can fix my image.
>
> -Winston
>
>>>

>>>> On Apr 13, 7:29 pm, Winston Wolff <winst...@stratolab.com> wrote:
>>>>> I've spent another day digging into this problem. I made a test png with just four pixels so I can see the data. It is indeed being decoded as all zeros.
>>>
>>>>> I was able to get QuartzImageDecoder to work one time, but I can't reproduce it. I was experimenting running the OSX default python2.6 instead of my framework build 2.7.2 in virtualenv.
>>>
>>>>> I'm using virtualenv and pyobjc v2.2. Does anybody know of incompatibilities with pyglet, virtualenv, and pyobjc2.2?
>>>
>>>> Winston,
>>>
>>>> Could you send me your test png image and I'll see what happens on my
>>>> end. Also could you try running your example with the evil-phillip-
>>>> cocoa-ctypes2 pyglet clone here:
>>>
>>>> http://code.google.com/r/evilphillip-cocoa-ctypes2/
>>>
>>>> and see if there is any difference? Pyglet has issues with PyObjC
>>>> 2.2. However it works with the default PyObjC installed with OS X
>>>> 10.6 which is version 2.2b3 (beta 3). If you're using your own
>>>> installation of pyobjc, you should try to use version 2.3 or greater.
>>>> If it does turn out to be a PyObjC issue, I can possibly rewrite the
>>>> quartz image decoder to not use it.
>>>
>>>> --phillip
>
>

[Phillip Nguyen]

Yes, sorry I haven't been able to get back to you. I have some free
time coming up in a week or so. I thinking that it might be a good
time to just bring all of the code from the cocoa-ctypes clone into
the normal repository and drop PyObjC. I can't really think of any
good reasons anymore for keeping it.

--phillip


On May 11, 11:13 am, Winston Wolff <winstonwo...@cal.berkeley.edu>
wrote:

[Steve]

I thinking that it might be a good
time to just bring all of the code from the cocoa-ctypes clone into
the normal repository and drop PyObjC.  I can't really think of any
good reasons anymore for keeping it.

Ditto. I clone that branch every time I start a new project. It would be nice for it to be the official version. 

[Tristam MacDonald]

On Fri, May 11, 2012 at 2:42 PM, Phillip Nguyen <evil.p...@gmail.com> wrote:

Yes, sorry I haven't been able to get back to you.  I have some free
time coming up in a week or so.  I thinking that it might be a good
time to just bring all of the code from the cocoa-ctypes clone into
the normal repository and drop PyObjC.  I can't really think of any
good reasons anymore for keeping it.

--phillip

I'm all for dropping PyObjC at the first chance, but I haven't tried the ctypes branch in a little while - are all the features working as expected?

It would be fantastic to ship a pyglet release that worked out of the box on vanilla OS X Lion installs.

--

Tristam MacDonald

System Administrator, Suffolk University Math & CS Department

http://swiftcoder.wordpress.com/

[Richard Jones]

On 12 May 2012 04:42, Phillip Nguyen <evil.p...@gmail.com> wrote:
> Yes, sorry I haven't been able to get back to you.  I have some free
> time coming up in a week or so.  I thinking that it might be a good
> time to just bring all of the code from the cocoa-ctypes clone into
> the normal repository and drop PyObjC.  I can't really think of any
> good reasons anymore for keeping it.

+1 !!


Richard

[Nathan]

On Fri, May 11, 2012 at 3:13 PM, Tristam MacDonald <swift...@gmail.com> wrote:
> It would be fantastic to ship a pyglet release that worked out of the box on
> vanilla OS X Lion installs.

Amen.

Ditto for AVbin...working on that...

~ Nathan