an IOS platform issue with images

[Dave Dyer]

One would expect that
       int in[] = ...
       Image fin = Image.createImage(out,w,h);
       int out[] = fin.getRGB();

that in[] would contain the same values as out[], but this is not the case on IOS.

Presumably, the problem is due to some detail of how transparency is handled in the internal
representation of the image.   I can provide a test case, but this isn't a hard to produce problem,
all images with transparency turn 0 input into 0xffffff output.

[Shai Almog]

Assuming out is an ARGB array which you didn't state. This still isn't guaranteed to work as the colors are applied to a native surface which doesn't have to support all the colors.

[Dave Dyer]

I would say that putting out black and getting back white, as is the case here,
is a rather spectacular example of "not guaranteed"

[Shai Almog]

Where did you say you put in black and got back white in the question?
I just re-read it and can't see that neither in the sample nor the wording.

If the alpha component is transparent the color component is ignored.

[Dave Dyer]

The value I put in is 0x00000000, the value I get back out Is 0x00ffffff
but the effect ix not limited to fully transparent pixels.  Near!y transparent
come back as nearly white.  The "white" pollution continues up through
the transparency scale, so my smooth gray shadows become tinged
with white, because the partially transparent black has become
partially transparent white.

You can see this clearly in the attached images.  I suspect this is
because IOS is using pre-multiplied transparency, so the information
about the original color is actually being lost.  

[Shai Almog]

That's possible. Especially with image manipulation which is pretty tricky to get right on iOS as it's graphics pipeline is totally different.

I'm not sure if it's fixable though, if I recall that code we added the color to workaround a different problem in that logic where transparency didn't work at all without a blending color.

I'm not sure what could be used as a workaround for this.

[Dave Dyer]

well, you could retain the original rgb array that was used to create the image, but that
Screams waste of memory.

My test indicates this is also a problem for images created by the embedded image readers.
Basically this means getRGB is useless for processing images with a transparency component -
For example to do better scaling than the closest pixel scaling you provide access to.

This is something you ought to document in the description of getRGB.

[Shai Almog]

If you have something specific in mind you can submit a pull request with the javadoc changes you think are appropriate for this.

[Dave Dyer]

It's unreasonable for me to go to all the effort to resync my sources and construct a pull request, only to
be rejected because I can't guess the specific wording you will find acceptable.   Something to the effect
of

Note that RGB values produced by getRGB may not be identical to those you expect based on the known
values in the original image; and specifically that on IOS, the RGB conponents of partially transparent pixels
will have values unrelated to the original values.

[Shai Almog]

Pull requests are reasonably easy to do. The main motivation of using that over an issue or comment is:
a. They get done.
b. You get the credit.

I would not use the word unrelated since the values are clearly related.