On Images, bitwise operations don't take in account index of images.

[Siskin-Bot]

Submitted by: Steeve

First explanation:

Bitwise operations (or, xor, and) don't act at the current position of targeted images but always act on the whole content.
Index of images are ignored.

2nd possibility:

Index are taken in account, but when the tail of one image is pointed then the looping bitwise process jump at the head instead of stoping here.

There is the same behaviour in the current R2 release, so why is it a bug ?
Because in the old releases of R2 (1.3 for example) it was working fine without the need to copy skiped images before applying a bitwise operator on them.
Doing a copy on a sub-part of an image bypass the problem but cause a needless memory overhead.

a: make image! reduce [2x2 red]
b: make image! reduce [2x2 black]
>> a and skip b 0x1
== make image! [2x2 #{
0000000000000000000000
} #{
00000000
}]

The expected result is given by using a copy of the skiped image.

>> a and copy skip b 0x1
== make image! [2x2 #{
000000000000FF0000FF0000
} #{
00000000
}]

---

^{Imported from: CureCode [ Version: alpha 52 Type: Bug Platform: All Category: n/a Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#793}

Comments:

Rebolbot commented on May 12, 2009:

Submitted by: BrianH

Third possibility: Perhaps images don't (or shouldn't) have a series-like internal position in R3 anymore, like map! and bitset!.

---

Rebolbot commented on May 14, 2009:

Submitted by: Carl

Removed AND, OR, and XOR for images. They are not that useful as currently specified, especially with regard to alpha channel.

It may be that we need to provide a few powerful natives to manipulate image data directly. For now, use DRAW to modify images.

---

Rebolbot commented on May 14, 2009:

Submitted by: Steeve

Noooooooooo

---

Rebolbot added the Type.bug on Jan 12, 2016

---

[Oldes]

Related wish: #804