Hyperion Entertainment Message Boards

Hi there,
according with Andreas Falkenhahn we have noticed that there was a bug in OS4.1FE(trye on that) PNG DataTypes, it wont recognize correctly alpha channel in a picture that I have...or better, it recognize the alpha channel but while I will load the image with alpha channel it dont works...
I attach the image with the problem...

Thank you!

What is the problem (apart from the anatomically-absurd young lady)?

Hi!
The problem was that os4 png datatypes wont load the alpha channel of the pic...

EDIT: with internal Hollywood imag loader I get no errors and the pic was loaded correctly...

Tuxedo wrote:Hi!
The problem was that os4 png datatypes wont load the alpha channel of the pic...

EDIT: with internal Hollywood imag loader I get no errors and the pic was loaded correctly...

AmigaOS4 FE
datatypes.library 53.4 (4.11.2009)
png.datatype 53.10 (12.06.2013)

Multiview loads the picture correctly...what exactly isn't working for you and with what programs?
Maybe you aren't using the datatypes correctly?

@Raziel

11.AmigaOS4:> version png.datatype
png.datatype 53.10
11.AmigaOS4:> version picture.datatype
picture.datatype 53.6
11.AmigaOS4:> version datatypes.library
datatypes.library 53.4


That's odd as it doesn't load correctly here, eiter in MultiView or *********** both of which uses datatypes to extract the image data but the second extracts the 32bit data.

But it does show in AWeb (which uses png library directly). PPaint also see the transparency.

Note the image does not have an alpha channel per seh, it's an 8bit palettemapped png with a transparency chunk. Perhaps the datatype doesn't have support for palette mapped alpha values.

Raziel are you sure you are using the OS datatype and not a third party one like WarpDT ?

Raised bug 9208

broadblues wrote:@Raziel

11.AmigaOS4:> version png.datatype
png.datatype 53.10
11.AmigaOS4:> version picture.datatype
picture.datatype 53.6
11.AmigaOS4:> version datatypes.library
datatypes.library 53.4

7.System:> version Classes/DataTypes/png.datatype file full
png.datatype 53.10 (12.06.2013)
7.System:> version Classes/DataTypes/picture.datatype file full
picture.datatype 53.6 (22.08.2010)
7.System:> version Libs/datatypes.library file full
datatypes.library 53.4 (04.11.2009)

Raziel are you sure you are using the OS datatype and not a third party one like WarpDT ?

100% using the OS4 stuff installed with 4.1 FE

I don't even have that WarpDT program installed.

Hehehehe, i just found another one of those weird bugs (albeit it might be another Odyssey problem)

Steps to reproduce:

No Alpha Channel:
1) From Tuxedo's post left-click on the attachment to make the pic open solely on the tab
2) Right-click on the sole picture and "Save image as..." anywhere and call it test1.png
3) Open the file in Multiview --> Alpha Channel not used, background black

Alpha Channel:
1) From Tuxedo's post right-click on the attachment and "Save image as..." anywhere and call it test2.png
2) Open it in Multiview --> Alpha Channel used

What a strange way to puzzle the users

edit: typos

Can you chack that the two files are indentical? Sounds like Odyssey is mosdifying one of them when saving.

What does MultiView say in the about window for the two files?

broadblues wrote:Can you chack that the two files are indentical? Sounds like Odyssey is mosdifying one of them when saving.

What does MultiView say in the about window for the two files?

Sorry, i missed that paet of information.

No, they aren't identical, in fact the differ quite a lot in size, both bytes and measurement

test1.png (no alpha channel) - 19.445 bytes
Multiview information: PNG picture (143 x 283 x 8)

test2.png (alpha channel) - 112-764 bytes
Multiview information: PNG picture (126 x 249 x 32)

It "looks" like as if Odyssey makes a screen copy of the picture attached in Tuxedo's post and downloads that instead, than to load the real picture in the background.
Only if the picture gets displayed on it's own tab it's probably the original...