PDA

View Full Version : Normalizing an image



Rezmason
April 30th, 2009, 03:37 PM
Flash 10's got this new method on the BitmapData object called "get histogram()", which spits out a lot of neat data about the image in question. I'm particularly interested in finding the dimmest and brightest values for the image's blue channel, which I'm using for some image processing / computer vision stuff. Once I find the two extremes on the range of the blue channel, I can throw them into a ColorTransform object and normalize the image.

Problem is, get histogram() does a lot of work that I don't need it to, and it's really expensive. I'd like to find the information I need in some other, faster way.

I'm going to try iterating over the image and doing the computations myself, but I feel like this will be even slower. Does anyone have any other ideas?

Krilnon
April 30th, 2009, 04:01 PM
PixelBender might let you do it faster than you might be able to in AS… or you could try to figure out how to dump the image into the domain global fast memory ByteArray.

Rezmason
April 30th, 2009, 04:12 PM
[O]r you could try to figure out how to dump the image into the domain global fast memory ByteArray.

Whoa. Into the what? This sounds different from a standard ByteArray.

Krilnon
April 30th, 2009, 04:29 PM
http://livedocs.adobe.com/flex/3/langref/flash/system/ApplicationDomain.html#domainMemory

There are some AVM2 instructions in FP10 that operate on a ByteArray that you can specify. Those instructions let you get almost-direct memory access instead of having to go through whatever overhead there is with any other ByteArray. The Flash IDE and Flex SDK don't generate any of these instructions, as far as I know, but I think that haXe added some support for them and I've heard that most of Alchemy's speed increases come about as a result of these instructions.

http://llvm.org/devmtg/2008-08/Petersen_FlashCCompiler.pdf


On x86, JITs to direct memory accesses to hard-coded addresses

Store opcodes

[stack: (coerced to int or Number) value, (coerced to int) address -> ]
0x35 si8 – store an 8 bit integer to global memory
0x36 si16 – store a 16 bit integer to global memory
0x37 si32 – store a 32 bit integer to global memory
0x38 sf32 – store a 32 bit (IEEE 754) float to global memory (truncating the input double/Number to 32 bit IEEE 754)

Load opcodes
[stack: (coerced to int) address -> value (int or Number)]
0x3a li8 – load an 8 bit unsigned integer from global memory
0x3b li16 – load a 16 bit unsigned integer from global memory
0x3c li32 – load a 32 bit integer from global memory
0x3d lf32 – load a 32 bit (IEEE 754) float from global memory and promote to 64 bit (IEEE 754) double/Number
0x3e lf64 – load a 64 bit (IEEE 754) float from global memory
Sign extension opcodes

[stack: (coerced to int) value -> value (int)]
0x50 sxi1 – sign extend from 1 bit to 32
0x51 sxi8 – sign extend from 8 bits to 32
0x52 sxi16 – sign extend from 16 bits to 32

I was going to write something someday that made those instructions available-ish to ActionScript, but I haven't gotten around to it yet. Maybe it has already been done.

Rezmason
April 30th, 2009, 08:00 PM
All the more reason to learn haXe, I suppose. :D Does anybody know whether the definitions and methods within a SWF written in haXe are accessible to Flash-compiled SWFs when loaded in at runtime?