Alpha channel of image! type
[1/11] from: aete:ramdamfilms at: 14-Nov-2002 10:44
Hi,
I looked everywhere (REBOL's site, eScribe, Google) to find how to access
the alpha channel in REBOL/View's image! type. What I want to do separate
all 4 channel into blocks or lists or arrays, whichever is most efficient
for later processing... and do it fast! Any clue is welcome.
Thanks,
-C
---------------
claude precourt [realisateur] ramdam films
[2/11] from: petr:krenzelok:trz:cz at: 14-Nov-2002 19:00
Hi,
I am not sure I can completly answer your question, but look at least
into following hints:
->> img: load %carlwaves.jpg
== make image! [128x128 #{
66191C681B1E6A1D20671A1D65181B681B1E702326772A2D74272A6A1D20
6114176215186C1F2275282B782B2E732A2C601E1F7...
now you can know each pixel:
->> img/1
== 28.25.102.0
->> img/2
== 30.27.104.0
As you can see, four bytes are used, zero represents value of alpha
channel here ....
But notice, that rebol presents data in BGR reverse format ...
->> to-integer #{66}
== 102
->> to-integer #{19}
== 25
->> to-integer #{1C}
== 28
->> to-integer #{68}
== 104
From above you can see, that alpha channel is not presented in ==make
image! output ....
simple
example of how to change alpha value of image to let's say
value of 100:
->> for i 1 (length? img) / 4 1 [poke img i to-tuple join img/:i/1 ["."
img/:i/2 "." img/:i/3 "." 100]]
->> view layout [image img]
So possibly, as for your example:
R: copy []
G: copy []
B: copy []
A: copy []
for i 1 (length? img) / 4 1 [append R img/:i/1 append G img/:i/2 append
B img/:i/3 append A img/:i/4]
So, that's it ... the code is nice looking and simple, isn't it? The
problem is, that for image manipulation, forget speed. Unless RT adds
compile to at least some areas of usage, you will have to either wait a
bit when manipulating large image, or go for C library, but you would
need /Pro version ...
HTH,
-pekr-
Claude Precourt wrote:
[3/11] from: cyphre:seznam:cz at: 14-Nov-2002 19:04
Hello Claude,
Here is a snippet of my quick console session:
>> img: load %image13.png
== make image! [800x600 #{
E88878E88878E88878E88878E88878E88878E88878D88878E88878E88878
E88878D88878E88878E88878E88878E88878E88878E...
>> img/1
== 120.136.232.0
;so here you can see four channels of first image pixel
;you can acces it also like
>> img/1/1 ;red channel
== 120
>> img/1/2 ;blue channel
== 136
>> img/1/3 ; green channel
== 232
>> img/1/4 ;alpha channel
== 0
;that's one possible method
;but be be carful on the order of image channel bytes in the binary form
>> xx: to-image layout [origin 0 box blue]
== make image! [100x100 #{
FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000
FF0000FF0000FF0000FF0000FF0000FF0000FF0000F...
>> xx: to-image layout [origin 0 box green]
== make image! [100x100 #{
00FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF00
00FF0000FF0000FF0000FF0000FF0000FF0000FF000...
>> xx: to-image layout [origin 0 box red]
== make image! [100x100 #{
0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF
0000FF0000FF0000FF0000FF0000FF0000FF0000FF0...
>>
;as you can see in the lines above the bytes are in different order:
BBGGRRAA
;and here you are some exaples of image channel splitting with speed
comparison:
>> red: make block! 1000000 green: make block! 1000000 blue: make block!
1000000 alpha: make block!
1000000 s: now/time/precise foreach [b g r a] img [insert tail red r insert
tail green g insert tail
blue b insert tail alpha a] now/time/precise - s
== 0:00:04.606
>> red: copy [] green: copy [] blue: copy [] alpha: copy [] s:
now/time/precise foreach [b g r a] im
g [insert tail red r insert tail green g insert tail blue b insert tail
alpha a] now/time/precise - s
== 0:00:09.434
>> red: make block! 1000000 green: make block! 1000000 blue: make block!
1000000 alpha: make block!
1000000 s: now/time/precise foreach [b g r a] img [append red r append green
g append blue b append
alpha a] now/time/precise - s
== 0:00:10.825
>> red: copy [] green: copy [] blue: copy [] alpha: copy [] s:
now/time/precise foreach [b g r a] im
g [append red r append green g append blue b append alpha a]
now/time/precise - s
== 0:00:15.643
;as you can see the fastest method from those examples is to preallocate the
series for each channel and then ise "insert tail" instead of "append"
;but this is quick experiment, there are lot of other possible methods...
regards
Cyphre
[4/11] from: greggirwin:mindspring at: 14-Nov-2002 11:09
Hi Claude,
CP> I looked everywhere (REBOL's site, eScribe, Google) to find how to access
CP> the alpha channel in REBOL/View's image! type. What I want to do separate
CP> all 4 channel into blocks or lists or arrays, whichever is most efficient
CP> for later processing... and do it fast! Any clue is welcome.
Something along these lines?
img: load %bay.jpg
block: reduce ['r copy [] 'g copy [] 'b copy [] 'a copy []]
foreach [r g b a] img [
append block/r r
append block/g g
append block/b b
append block/a a
]
What will work best depends on what processing you're doing later and
what your actual time constraints are.
-- Gregg
[5/11] from: aete:ramdamfilms at: 14-Nov-2002 17:52
Hmmm. That's not what I get at all. The following example session shows that
each pixels is, in fact, stored in 32 bits (test.png does have an alpha
channel):
>> img: load %test.png
>> == make image! [89x133 #{
466DB1476EB24970B44B72B64C73B64C73B74B72B64B72B64970B44A71B5
4B72B64B72B54970B44970B34A71B44B72B64D71BD4C...
>> first img
== 177.109.70
>> second img
== 109.70.0
>> third img
== 70.0.178
You can see that, using first, second and third, I can scroll through the
image's data one byte at a time, and that the fourth element is the fourth
byte of the pixel. So far so good. But then things start to get weird.
First, the value should be 255, as the alpha channel is white in the image,
and second, I don't have access to the fourth component of the pixel:
>> img/1
== 177.109.70
>> img/1/4
== none
I verified this behaviour on both MacOS and Linux implementations of
REBOL/View (versions 1.2.1.2.1 and 1.2.1.4.2 respectively) Could this be a
platform issue?
And, by the way, thanks for all the help! You all gave me cool hints on how
I can solve my problem in a more "rebol-like" way!
-C
[6/11] from: petr:krenzelok:trz:cz at: 15-Nov-2002 4:48
Claude Precourt wrote:
>Hmmm. That's not what I get at all. The following example session shows that
>each pixels is, in fact, stored in 32 bits (test.png does have an alpha
<<quoted lines omitted: 18>>
>== 70.0.178
>You can see that, using first, second and third,
So why don't you refer to my examples? ;-)
> I can scroll through the
>image's data one byte at a time, and that the fourth element is the fourth
>byte of the pixel. So far so good. But then things start to get weird.
>First, the value should be 255, as the alpha channel is white in the image,
>and second, I don't have access to the fourth component of the pixel:
>
Go and download 1.2.8 version of View ....
-pekr-
[7/11] from: aete:ramdamfilms at: 15-Nov-2002 8:18
> So why don't you refer to my examples? ;-)
Well, at this point, using your computer directly is more what I had in
mind! ;)
> Go and download 1.2.8 version of View ....
Easier said than done! I have the latest version available on RT's web site
(1.2.1). Is 1.2.8 is some kind of a beta that I can download elsewhere?
Btw, pardon my high level of "newbiness"... I had never heard of Rebol a
month ago!
Thanks again,
-C
[8/11] from: jan:skibinski:sympatico:ca at: 15-Nov-2002 13:33
Petr, Claude:
> >>Go and download 1.2.8 version of View ....
> >
<<quoted lines omitted: 3>>
> >
> http://www.rebol.com/beta-versions.html
That page has not been updated for a while I guess.
The 1.2.8 version of View can be found here:
http://www.reboltech.com/downloads/
Jan
[9/11] from: petr:krenzelok:trz:cz at: 15-Nov-2002 19:20
Claude Precourt wrote:
>>So why don't you refer to my examples? ;-)
>>
>>
>
>Well, at this point, using your computer directly is more what I had in
>mind! ;)
>
eh? :-) I thought my message containing answers to your questions
arrived to ml?
>>Go and download 1.2.8 version of View ....
>>
>>
>
>Easier said than done! I have the latest version available on RT's web site
>(1.2.1). Is 1.2.8 is some kind of a beta that I can download elsewhere?
>
http://www.rebol.com/beta-versions.html
>Btw, pardon my high level of "newbiness"... I had never heard of Rebol a
>month ago!
>
Where have you been last four years? :-)
-pekr-
[10/11] from: g:santilli:tiscalinet:it at: 15-Nov-2002 15:36
Hi Claude,
On Thursday, November 14, 2002, 11:52:56 PM, you wrote:
CP> Hmmm. That's not what I get at all. The following example session shows that
CP> each pixels is, in fact, stored in 32 bits (test.png does have an alpha
CP> channel):
[...]
CP> I verified this behaviour on both MacOS and Linux implementations of
CP> REBOL/View (versions 1.2.1.2.1 and 1.2.1.4.2 respectively) Could this be a
CP> platform issue?
Alpha channel is not supported in version 1.2.1.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[11/11] from: aete::ramdamfilms::com at: 16-Nov-2002 8:56
> Petr, Claude:
>>
<<quoted lines omitted: 10>>
> http://www.reboltech.com/downloads/
> Jan
Well, that version indeed works as expected. Now I just need to wait for it
to be available on MacOS... [sigh]
Thanks all for your help!
-C
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted