Форум Flasher.ru - Параметры getColorBoundsRect

Цитата:

Сообщение от Волгоградец (Сообщение 755257)

Возможно дело с округлением альфы. Т.е. с цветами флэш нормально работает - а вот с прозрачностью - не очень.

Я тоже склонен считать, что дело в округлениях. Но, возможно, не из-за самой альфы, а из-за того, как НА САМОМ ДЕЛЕ храниться/записывается/считывается цвет в модели ARGB.

Цитата:

Сообщение от Волгоградец (Сообщение 755257)

Вот что выдает трейс при разных значениях цвета:

Код:

var myBitmapData:BitmapData = new BitmapData(300, 200, true, 0x700100FF);

trace("getPixel = 0x"+myBitmapData.getPixel(10,10).toString(16));//0xff

Ну как раз прозрачность тут считается правильно:

Код:

trace("getPixel32>> = 0x"+(myBitmapData.getPixel32(10,10)>>24).toString(16)+(myBitmapData.getPixel32(10,10) & 0xFFFFFF).toString(16)) // 0x70ff

// т.е. на самом деле 0x700000ff

А ошибка только в красном канале: вместо 0х01 посчитано 0х00

Цитата:

Сообщение от Волгоградец (Сообщение 755257)

Код:

0x990400FF

trace("getPixel = 0x"+myBitmapData.getPixel(10,10).toString(16));//0x300ff

Вот тут уже ошибка и в красном канале и в прозрачности:

Код:

//0x300ff т.е. на самом деле 0x0300ff 

//getPixel32>> = 0x-67300ff

Итак getPixel опять ошибся на единицу в красном канале, а вот getPixel32 круто наврал...

Цитата:

Сообщение от Волгоградец (Сообщение 755257)

Код:

0xFF0400FF

trace("getPixel = 0x"+myBitmapData.getPixel(10,10).toString(16));//0x400ff

Тут тоже забавно:

Код:

getPixel = 0x400ff т.е. на самом деле 0x0400ff - ошибки нет

getPixel32>> = 0x-1400ff т.е. на самом деле 0x-10400ff  - ошибка только в альфа канале

Надо помнить, что мы трассируем через toString(16), поэтому при значении альфа канала более 0x7F toString(16) глючит (см. выше).
Хотя и непонятно почему - мы же проверили побитовый сдвиг вправо?
Но тождество налицо - до значения 0x7F определяется верно, более - ошибка.

Цитата:

Сообщение от Alex_beginner

Ну, я думаю, проблема здесь в конфликте попиксельного смешивания прозрачности цвета (параметр transparent) и альфа-составляющей значений маски и искомого цвета.
Грубо говоря, установите, параметр transparent в false, и данный пример заработает

Да, я писал, что это только для прозрачной битмапы такие глюки.

Цитата:

Сообщение от Alex_beginner

т.е.:

Код:

myBitmapData = new BitmapData(300, 200, false, 0x705500FF);

Я, не совсем понимаю, зачем использовать transparent==true и при этом еще манипулировать альфа-каналом в кокретных используемых значениях. Практичнского значения это не имеет.
Используйте, лучше transparent==false и значения альфа-канала.

Не понял насчет transparent==false. Тогда же битмапа непрозрачная будет и параметр A модели ARGB вообще роли не играет (как и метод getPixel32 теряет свой смысл).
А ведь битмапа с прозрачностью - наиболее востребованная, разве нет?

add:
Ступил с трейсом на getPixel32, там надо было побитовый сдвиг без знака делать, тогда toString(16) правильный альфа канал показывает ВСЕГДА!

Код:

trace("getPixel32>> = 0x"+(myBitmapData.getPixel32(10,10)>>>24).toString(16)+(myBitmapData.getPixel32(10,10) & 0xFFFFFF).toString(16))

add2:
вроде нашел причину
http://flasher.ru/forum/showpost.php...25&postcount=3
ПУстячок, а приятно, что я верно предположил, что все дело в том, как НА САМОМ ДЕЛЕ ХРАНИТЬСЯ цвет в модели ARGB.