You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: unspecified Reported for operating system, platform: Mac OS X (All), All
Comments on the original bug report:
On 2009-10-29 08:06:06 +0000, Vittorio Giovara wrote:
starting from 1.2.14 with the new ImageIO backend, some images (we use pngs) have problems in setting the alpha channel correctly. The surface is loaded and converted correctly, as the colors match the ones in the other OSes, but when blending an alpha area, the alpha color is completely ignored.
we have a strong suspect that one area might be doing ABGR, and the other area expecting the alpha to be the last byte and reading the R as an A.
On 2009-10-29 08:06:58 +0000, Vittorio Giovara wrote:
Created attachment 435
correct behaviour (1.2.13)
On 2009-10-29 08:09:16 +0000, Vittorio Giovara wrote:
Created attachment 436
wrong behaviour (1.2.14 + 1,3)
On 2009-10-29 08:10:41 +0000, Vittorio Giovara wrote:
Created attachment 437
correct behaviour with background red channel as alpha
On 2009-10-29 08:33:45 +0000, Vittorio Giovara wrote:
Created attachment 438
another (more evident) screenshot of the wrong behaviour
On 2009-10-29 09:13:05 +0000, Sam Lantinga wrote:
Are you able to reproduce this with showimage, or is this a problem in your application?
There were a few color issues in some games that turned out to be the game assuming the order of the RGB channels, but once they started checking the masks in the screen->format, everything was fine.
On 2009-10-29 10:30:50 +0000, Vittorio Giovara wrote:
(In reply to comment # 5)
Are you able to reproduce this with showimage, or is this a problem in your
application?
There were a few color issues in some games that turned out to be the game
assuming the order of the RGB channels, but once they started checking the
masks in the screen->format, everything was fine.
We're quite sure that the order of the channels are correct because the other images are displayed correctly -- the problem only arise when images with alpha are blended.
On 2009-10-29 13:13:06 +0000, Vittorio Giovara wrote:
hm we noticed that by stripping color profiles from the png helped with the background image.
perhaps our theory was wrong, but does sdlimage handles color profiles correcly in the new backend?
On 2009-10-29 13:47:03 +0000, Vittorio Giovara wrote:
Ok, dumping the first column of a buggy SDL surface, we noticed an interesting pattern:
A B G R
SDL on OSX
206 | 177 | 131 | 125
GIMP
206 | 220 | 163 | 155
SDL on OSX
14 | 8 | 5 | 4
GIMP
14 | 157 | 92 | 84
Pattern seems to be that if you take:
177 * (255/206) ~ 219
and
8 * (255/14) ~ 146
Now, that 2nd one is not so accurate. But.
157 / (255 / 14) = 8.58 which if truncated is 8.
220 / (255 / 206) = 177.72 = 177
So we could be dealing with some curious modification proportional to alpha and a floor operation to boot.
Fortunately the fix for that is fairly trivial, until SDL is fixed, we can ifdef DARWIN to reverse the damage.
The truncation means some accuracy is lost, but hopefully not too much.
On 2009-11-10 10:24:36 +0000, Vittorio Giovara wrote:
ok now it works fine, thanks!
there is just one thing that worries me is that by looking at the code
Uint8 *p = (Uint8 *)surface->pixels;
Uint8 A = p[3];
so we are using 8 bits for Alpha, 8 for Red, 8 for Green and 8 for Blue; then we make a division and save it on an eight bit variable
if the result of the operation is something like 99.99 then the result stored would be 99, truncating the .99, making the color a little darker -- not noticable -- but different from an alpha-free surface; every computation on color value would be likely to fail with this code.
What do you think of this possibility?
On 2009-11-10 13:11:28 +0000, Vittorio Giovara wrote:
PowerPC loading is broken
normal pngs work fine but pngs with alpha segfault
showimage's output is
showimage(52993) malloc: *** error for object 0x837200: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
(attached BlueWater.png)
On 2009-11-10 13:12:27 +0000, Vittorio Giovara wrote:
Created attachment 448
test image used in showimage to test ppc code
On 2009-11-10 23:09:44 +0000, Sam Lantinga wrote:
The crash is fixed, thanks!
As for the inaccuracy in the multiplication, we might be able to solve it by using 256 instead of 255, although that might break things the other direction.
The text was updated successfully, but these errors were encountered:
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Mac OS X (All), All
Comments on the original bug report:
On 2009-10-29 08:06:06 +0000, Vittorio Giovara wrote:
On 2009-10-29 08:06:58 +0000, Vittorio Giovara wrote:
On 2009-10-29 08:09:16 +0000, Vittorio Giovara wrote:
On 2009-10-29 08:10:41 +0000, Vittorio Giovara wrote:
On 2009-10-29 08:33:45 +0000, Vittorio Giovara wrote:
On 2009-10-29 09:13:05 +0000, Sam Lantinga wrote:
On 2009-10-29 10:30:50 +0000, Vittorio Giovara wrote:
On 2009-10-29 13:13:06 +0000, Vittorio Giovara wrote:
On 2009-10-29 13:47:03 +0000, Vittorio Giovara wrote:
On 2009-10-29 21:03:12 +0000, Sam Lantinga wrote:
On 2009-10-29 21:55:37 +0000, Sam Lantinga wrote:
On 2009-11-09 19:45:09 +0000, Vittorio Giovara wrote:
On 2009-11-09 20:38:05 +0000, Sam Lantinga wrote:
On 2009-11-09 20:40:13 +0000, Sam Lantinga wrote:
On 2009-11-09 22:02:11 +0000, Sam Lantinga wrote:
On 2009-11-09 23:33:52 +0000, Sam Lantinga wrote:
On 2009-11-10 00:45:42 +0000, Sam Lantinga wrote:
On 2009-11-10 10:24:36 +0000, Vittorio Giovara wrote:
On 2009-11-10 13:11:28 +0000, Vittorio Giovara wrote:
On 2009-11-10 13:12:27 +0000, Vittorio Giovara wrote:
On 2009-11-10 23:09:44 +0000, Sam Lantinga wrote:
The text was updated successfully, but these errors were encountered: