"Icon Image reader" published to the Cincom Public Store

Hi community

I have published the package "ICOImageReader" to the public store with the hope that others might find such a file importer useful,
too.

It extends the image reader class hierarchy with an ICOImageReader class that can read the Microsoft Windows Icon File format. I
tried to be conform to the Image Reader protocol, but it differs as Icon files can contain several images in different sizes and
color depths. So there is an #images accessor instead of #image (which also exists, but only returns the first image). The result
are OpaqueImages instead of Images to deal with transparency information.

If you have questions or feedback, just send me an email.

Thomas

That is great news! We really need to enhance the visual appearance of
application made using VisualWorks.

I assume Microsoft icons can contain alpha information. Do you support
this, or are pixels simply transparent/opaque? If the internal image
format is PNG, you might want to look a the following post, which
explains how alpha information in PNG images can be used when
displaying images:
http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&entry=3328177749

Runar Jordahl

Hi Runar

I feared that this question would come up, although I thought it would take some more time than less than one hour :)

Icons can contain alpha channel information in 32bpp format, at least AFAIK. But currently alpha channel is ignored. It is as you
wish it wouldn't be, there are simple colors and a pixel mask applied to it. This has 2 main reasons: my lack of knowledge (until
today) about
- alpha channels per se and their use in images (though I know what they are for)
- how to transfer this into vw opaqueimages
But, this is version 1.0, there is much room left for improvements. My first intention was to use a more capable icon designer
(palettes, color blending, anti-aliasing, smoothing, "asDisabledImage" per click, etc).
So alpha channel support is on the to do list, with lecture on alpha channel coming first.

thomas

Hi all

Does anyone know the current status of alpha channel support/gradient fill/coverage values between 0 and 1 in visualworks? I found
emails about the subject from last year where Eliot talked about the BitBlt engine from squeak that should be ported to vw for 7.4
as a vm plugin. But i didn't find any notes about it in the release notes for 7.4, neither in 7.4.1.

And I assume it is a prerequisite that OpaqueImages used for Icons in vw can have gradient transparency and display themselves
properly. I don't know any other way how to currently embed the information about alpha channel in an icon so that it displays
itself correctly on any given background.

Thomas

The BitBlt code does not support alpha information, but could possibly
be improved to deal with it. As far as I understand, the current code
is for copying rectangular areas of pixels. I do not know for sure,
but I assume it copies pixels between Pixmaps. It would be nice if
Cincom improved this code, and included it as part of the base.

Currently, I think you need to follow the advice in my post
(http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&entry=3328177749)
to draw alpha-enabled images. It is slow, but I think it might be OK
on a fast computer when not too many icons are drawn.

Also read this post,
http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&entry=3329821464
to understand how Pixmap and Image differs. If you in the future want
to use an improved BitBlt, make sure it supports the type of graphical
object you need.

Runar

My intention for this goodie was to provide an importer for OpaqueImages that you otherwise would define with the ImageEditor (or
some more enhanced tools like CoolImage) as Images and Masks (figures and shapes in terminology of OpaqueImages). Nothing more.
Final destination (for me) are resource methods that are installed in some IconLibrary and used the same way as usual, returning
OpaqueImages (or maybe creating them on the fly from files if you want to avoid methods).

So my point of view is that OpaqueImages (as the rest of the graphics system) must deal with transparency better than nowadays (I am
on 7.3.1 at the moment, so I don't know much about 7.4/7.4.1). With current OpaqueImages the transparency is reduced to
transparent/opaque instead of a transparency level somewhere between 0 and 1. But I do not want to augment them (e.g. create another
OpqueImage class) and half of the graphics library to deal with transparency levels. There was a discussion last year and probably
also some work already done.

Some subjects from messages in vwnc last year were:
- Finish WarpBlt port [Was: [Feature Request] CoveragePalette (and alpha blending)]
- [Feature Request] CoveragePalette

One statement by Eliot was
>>     the plan for alpha-blending is to finish the port of the Squeak
>> WarpBlt code in vw7.4.  The Squeak code needs some modification
>> before it will work for VisualWorks
>>     - we have to support more pixel formats than Squeak, because we
>> have to use those provided by the window manager.  So eg. we must
>> support 24-bit pixels and for 16-bit pixels we need to support at
>> least 5,5,5 and 5,6,5 formats.

(Sorry it was WarpBlt, not BitBlt) And the subject was that vw should fix/enhance some vm restrictions and free CoverageValues would
be possible to create transparency. So OpaqueImage would also automatically get enabled for alpha blending as it is defined in the
ico files.

And my question was about this mentioned WarpBlt port or other enhancements that would support alpha blending in vw graphics. Then
the above import could better transport transparancy information into vw graphics, icons or whatever.

Thomas


Comments=true&entry=3328177749)