|
|
|||||||
Banned
[+4 01.02.09]
[+1 01.02.09] |
Цитата:
Цитата:
trace("getPixel32>> = 0x"+(myBitmapData.getPixel32(10,10)>>24).toString(16)+(myBitmapData.getPixel32(10,10) & 0xFFFFFF).toString(16)) // 0x70ff // т.е. на самом деле 0x700000ff Цитата:
Итак getPixel опять ошибся на единицу в красном канале, а вот getPixel32 круто наврал... Цитата:
getPixel = 0x400ff т.е. на самом деле 0x0400ff - ошибки нет getPixel32>> = 0x-1400ff т.е. на самом деле 0x-10400ff - ошибка только в альфа канале Хотя и непонятно почему - мы же проверили побитовый сдвиг вправо? Но тождество налицо - до значения 0x7F определяется верно, более - ошибка. Цитата:
Цитата:
А ведь битмапа с прозрачностью - наиболее востребованная, разве нет? add: Ступил с трейсом на getPixel32, там надо было побитовый сдвиг без знака делать, тогда toString(16) правильный альфа канал показывает ВСЕГДА! trace("getPixel32>> = 0x"+(myBitmapData.getPixel32(10,10)>>>24).toString(16)+(myBitmapData.getPixel32(10,10) & 0xFFFFFF).toString(16)) вроде нашел причину http://flasher.ru/forum/showpost.php...25&postcount=3 ПУстячок, а приятно, что я верно предположил, что все дело в том, как НА САМОМ ДЕЛЕ ХРАНИТЬСЯ цвет в модели ARGB. Последний раз редактировалось chingachgoog; 26.01.2009 в 12:54. |
|
|||||
Регистрация: Dec 2008
Сообщений: 87
|
Ребята, спасибо за эту тему. Тоже на днях ломал голову над похожей задачей при использовании Threshold.
В результате, причину проблемы нашел в мануале по getPixel: Все цветовые пикселы в объекте BitmapData хранятся уже умноженными на значение альфы (premultiplied color values). И в мануале даже упомянуто, что потеря данных может вызывать некоторые проблемы. Вот с этими проблемами мы, похоже, и столкнулись. Так что chingachgoog, видимо, в своем конечном выводе прав. |
Часовой пояс GMT +4, время: 15:01. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|