Параметры getColorBoundsRect

[Alex_beginner]

chingachgoog! Очень любопытные исследования. Я, увлекся ими.

Ладно, используем getColorBoundsRect:

colorBoundsRect = myBitmapData.getColorBoundsRect(0xffff00ff, 0x705400ff, true);
trace(colorBoundsRect) // (x=0, y=0, w=250, h=200)

Обратите внимание: в маске канала R (RGB) параметр установлен в 0xFF, а в параметре цвета этого же канала установлено "левое" (реальное) значение в 0x54. Результат - все показывает верно.

Меняем параметр цвета на правильный (заданный), т.е. на 0х55:

colorBoundsRect = myBitmapData.getColorBoundsRect(0xffff00ff, 0x705500ff, true);
trace(colorBoundsRect) // (x=0, y=0, w=250, h=200)

Опять правильно! Как такое возможно?!

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

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

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

Буду исследовать дальше.

[Bred45]

Ребята, спасибо за эту тему. Тоже на днях ломал голову над похожей задачей при использовании Threshold.

В результате, причину проблемы нашел в мануале по getPixel:
Все цветовые пикселы в объекте BitmapData хранятся уже умноженными на значение альфы (premultiplied color values).
И в мануале даже упомянуто, что потеря данных может вызывать некоторые проблемы. Вот с этими проблемами мы, похоже, и столкнулись.

Так что chingachgoog, видимо, в своем конечном выводе прав.