[plt-scheme] 2htdp/image

Yes, what Carl said. (Thanks. :)

I'll try to improve the docs along these lines (the juicy technical
bits are there now at the end of the docs, but the main point that
needed to be made is missing).

Robby

On Mon, Nov 16, 2009 at 8:34 PM, Carl Eastlund <carl.eastlund at gmail.com> wrote:
> On Mon, Nov 16, 2009 at 9:28 PM, Todd O'Bryan <toddobryan at gmail.com> wrote:
>>
>> I think I'm confused. If all bitmaps are images, but equality is done
>> cleverly, what will happen if you do
>>
>> (equal? (overlay BITMAP (line 20 30 "black"))
>>        (add-line BITMAP 0 0 20 30 "black"))
>>
>> And if you have to handle bitmaps anyway, how is color-list->image or
>> any of the crop functions any more problematic?
>>
>> In other words, suppose I make an image in DrScheme and save it as a
>> PNG. When I read it back in, I've lost all the image-y information, so
>> is it only equal to another bitmap that's pixel-identical, but not to
>> an image that's pixel-identical (say the one I saved)?
>>
>> Sorry to be dense, but I'm just trying to understand how this is going
>> to work when you start mixing user-created images and images loaded
>> from outside the environment.
>>
>> Todd
>
> Todd,
>
> There are a lot of images that are pixel-wise equal in this system,
> but not image-equal, even without resorting to bitmaps.  Two images
> that are equal are guaranteed to continue to be equal after applying
> (the same) scale and rotation operations to them; if you fix something
> to a bitmap and then apply scaling or rotation, you will get a
> different result, however.  So by differentiating bitmaps from other
> images, we lose some aspects of "ideal" image equality, but gain
> others.
>
> --Carl
>