Hi
The Epigent package is easy to implement and makes the toolbar look a good deal better. However on OSX it does not produce the same effect. <a href="cid:part2.00020104.05050404@wanadoo.fr"> <a href="cid:part2.00020104.05050404@wanadoo.fr"> Does anyone has dealt with this ? Regards, @+Maarten, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc capture2.tiff (11K) Download Attachment |
On Apr 14, 2008, at 3:38 PM, Maarten Mostert wrote: > Hi > > The Epigent package is easy to implement and makes the toolbar look > a good deal better. > > However on OSX it does not produce the same effect. > > > <Capturer1.PNG> <capture2.png> > > > Does anyone has dealt with this ? Different (display) platforms place A byte in different sequence relative to the RGB ones. I assume it's out of order. -- Travis Griggs Objologist "You A students, you'll be back soon teaching here with me. You B students, you'll actually go on to be real engineers. You C students, you'll go into management and tell the A and B students what to do." - My Fluid Dynamics Professor whom I have yet to disprove _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Maarten Mostert-2
I am the author of this package, and I would be happy to try and help you correct these problems. Sadly, I do not own a Mac myself but we can maybe sort this out anyway. As Travis notes, byte order might be the problem. I will contact you later (outside this group). Runar Jordahl2008/4/14, Maarten Mostert <[hidden email]>:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Maarten Mostert-2
I looked at this problem using an example Thomas sent me. Using the
image (provided as Smalltalk code) I reproduced the problem at 16 bit color depth at my PC. But using my own test image, the problem does not occur. To get my test image inspect: AlphaChannelImage iconExample16by16image Anyone having problems should probably look at this image and see if it displays ok. Note how the first top-left three pixels are Red, Green, and Blue. The PNG is attached. What I found is that Thomas' supplied a Depth32Image that uses a different palette than I use in my tests. Thomas' Depth32Image has this palette: (Graphics.FixedPalette redShift: 16 redMask: 255 greenShift: 8 greenMask: 255 blueShift: 0 blueMask: 255) While, my Depth32Image has this palette: (Graphics.FixedPalette redShift: 0 redMask: 255 greenShift: 8 greenMask: 255 blueShift: 16 blueMask: 255) Note how my palette shifts the RGB bits in increasing order; R is at bit position 0, G at 8, and B at 16. I am pretty sure this is causing the problems, but I have not looked into the details of the rendering code to confirm this. So there is a bug in the code, which I will look at later. The workaround is to always use a Depth32Image with the palette format I use in my examples. To create an image I do the following: - Edit the image in Paint.NET. - Save the image as PNG in 32 bit format. - Create the Depth32Image using class PNGImageReader. I use instance method #from: where the argument is the raw PNG image file as a Stream. See references to method #iconExample16by16 for the details. Note how #iconExample16by16 answers only a ByteArray which is an exact copy of the bytes found in the PNG file I saved from the image editing program. This uses "Epigent File In Method". ( http://www.cincomsmalltalk.com/publicRepository/Epigent%20File%20In%20Method(Bundle).html ) Runar _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc iconExample16by16.png (862 bytes) Download Attachment |
Hi Runar
Well, this brings some more light into the issue for me. I didn't get to the idea that the swapping of red and blue could be caused by the palette used for the images. One thing that could be a source of this problem could be the import of our images. I want to check this. I have written an ICO file format importer because we (some time ago) started to create icons using a windows icon tool that produces .ico files. Now we additionally use a bought stock icon library. In the beginning, we produced OpaqueImages from the ico, and then extended this to create AlphaChannelImages from 32bit ico file format with alpha channel support. What I want to check is that the import of the ico files produces the correct results. I even assume that I could change the import and use a palette that matches yours. That way the issue would just vanish. Thomas Runar Jordahl schrieb: > I looked at this problem using an example Thomas sent me. Using the > image (provided as Smalltalk code) I reproduced the problem at 16 bit > color depth at my PC. But using my own test image, the problem does > not occur. > > To get my test image inspect: AlphaChannelImage iconExample16by16image > > Anyone having problems should probably look at this image and see if > it displays ok. Note how the first top-left three pixels are Red, > Green, and Blue. The PNG is attached. > > What I found is that Thomas' supplied a Depth32Image that uses a > different palette than I use in my tests. Thomas' Depth32Image has > this palette: > (Graphics.FixedPalette > redShift: 16 redMask: 255 > greenShift: 8 greenMask: 255 > blueShift: 0 blueMask: 255) > > > > While, my Depth32Image has this palette: > (Graphics.FixedPalette > redShift: 0 redMask: 255 > greenShift: 8 greenMask: 255 > blueShift: 16 blueMask: 255) > > Note how my palette shifts the RGB bits in increasing order; R is at > bit position 0, G at 8, and B at 16. I am pretty sure this is causing > the problems, but I have not looked into the details of the rendering > code to confirm this. So there is a bug in the code, which I will look > at later. > > The workaround is to always use a Depth32Image with the palette format > I use in my examples. To create an image I do the following: > > - Edit the image in Paint.NET. > - Save the image as PNG in 32 bit format. > - Create the Depth32Image using class PNGImageReader. I use instance > method #from: where the argument is the raw PNG image file as a > Stream. > > See references to method #iconExample16by16 for the details. Note how > #iconExample16by16 answers only a ByteArray which is an exact copy of > the bytes found in the PNG file I saved from the image editing > program. This uses "Epigent File In Method". ( > http://www.cincomsmalltalk.com/publicRepository/Epigent%20File%20In%20Method(Bundle).html > ) > > Runar > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > -- Mit freundlichen Grüssen Thomas Brodt PORaBo Consulting Tel. +41 71 666 76 52 Fax. +41 71 666 76 57 http://www.porabo.ch _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Runar Jordahl
I played a bit with your image and found something strange. converting it with: <<convertToPalette: FixedPalette rgb8Bit >>would normally modify it to your test palette, but that does not work. However displaying it from <<ImageReader fromFile: 'iconExample16by16.png' >> Allready shows that things turn badly: While from finder your test icon shows correctly. Converting the png to a 24bit bitmap shows it up correctly on both Mac and Windows but Epigent does not handle that. Rememeber that when you use the good old icon editor reading icons from the screen gives bad result from PaintNet. You have to convert them to bitmaps open them in paint and then read them from the screen. The real problem might originate from imageReader. Regards, @+Maarten, Runar Jordahl a écrit : I looked at this problem using an example Thomas sent me. Using the image (provided as Smalltalk code) I reproduced the problem at 16 bit color depth at my PC. But using my own test image, the problem does not occur. To get my test image inspect: AlphaChannelImage iconExample16by16image Anyone having problems should probably look at this image and see if it displays ok. Note how the first top-left three pixels are Red, Green, and Blue. The PNG is attached. What I found is that Thomas' supplied a Depth32Image that uses a different palette than I use in my tests. Thomas' Depth32Image has this palette: (Graphics.FixedPalette redShift: 16 redMask: 255 greenShift: 8 greenMask: 255 blueShift: 0 blueMask: 255) While, my Depth32Image has this palette: (Graphics.FixedPalette redShift: 0 redMask: 255 greenShift: 8 greenMask: 255 blueShift: 16 blueMask: 255) Note how my palette shifts the RGB bits in increasing order; R is at bit position 0, G at 8, and B at 16. I am pretty sure this is causing the problems, but I have not looked into the details of the rendering code to confirm this. So there is a bug in the code, which I will look at later. The workaround is to always use a Depth32Image with the palette format I use in my examples. To create an image I do the following: - Edit the image in Paint.NET. - Save the image as PNG in 32 bit format. - Create the Depth32Image using class PNGImageReader. I use instance method #from: where the argument is the raw PNG image file as a Stream. See references to method #iconExample16by16 for the details. Note how #iconExample16by16 answers only a ByteArray which is an exact copy of the bytes found in the PNG file I saved from the image editing program. This uses "Epigent File In Method". ( http://www.cincomsmalltalk.com/publicRepository/Epigent%20File%20In%20Method(Bundle).html ) Runar _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
I think this thread highlights two different problems:
- Thomas' problem is the palette he uses. Red and Blue get mixed. As my previous post explains, the workaround for his problem is to create the Depth32Image from the PNG directly. To handle this problem I will let the drawing code throw an exception when getting an invalid palette. Later I might improve the code to handle this type of palette too. - Maarten's problem is not the order of the RGB values. There are two possible explanations for his problems: 1 - The alpha (transparency) information is not read correctly. So instead of blending with the background, the code simply uses the color values stored in the Depth32Image. 2 - The color value of the target image is not read correctly, and the code always blends to a black pixel. Right now I think explanation 1 is most likely to cause the problems. I will add unit tests to determine the cause of Maarten's problems (and mail you when they are ready Maarten). Runar _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Is this issue resolved somehow? Using the latest version from Store the AlphaChannelImage iconExample16by16 still shows up on my Mac as shown in the attachment.
2008/4/20 Runar Jordahl <[hidden email]> I think this thread highlights two different problems: _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc alpha.png (5K) Download Attachment |
Can you possibly check the result of the following statement in method
AlphaChannelImage>>displayOn:at: aGraphicsContext medium completeContentsOfArea: rectangle Verify that temporary variable toScreenImage contains the area of the screen to which the icon is to be drawn on. If that image is not correct the next statement (self displayOnImage: toScreenImage.) will of course create the wrong result image. In your case I guess toScreenImage should contain only white pixels. If you look at my code, you'll notice the call to completeContentsOfArea: is covered by an exception handler. I had problems with this method crashing. That might be caused by a bug in VisualWorks. Kind regards Runar Jordahl _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Rob Vens-2
addLast: in List is implemented with a check if there's a need to grow,
and a call to a privateAddLast:. In OrderedCollection, addLast: has the same structure, but no separate privateAddLast:. Instead it has a addLastNoCheck: which basically does the same thing as privateAddLast, but gets used by other methods than addLast:... Would it perhaps be a good idea to make these two methods work the same way? (ie: the List way, so in OrderedCollection rename addLastNoCheck: (or have it call privateAddLast: for compatability reasons), and have addLast: call it) Cheers, Henry _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Runar Jordahl
Using AlphaChannelImage iconExample16by16.
if I set a breakpoint in the method displayOn:at: and inspect toScreenImage the following can be seen: it is a Depth32Image with depth 24 it displays as a black rectangle all bits in the bits array are zero How can I determine that it is the correct area of the screen to draw on? 2008/11/12 Runar Jordahl <[hidden email]> Can you possibly check the result of the following statement in method _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Runar Jordahl
Have you any idea how to integrate an alphaChannelImage with a cairo
graphics which uses a different palette ( FixedPalette CairoARGB32) ? Annick Fron _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
All magic happens in Image>>putAlphaChannelImage:at: . There are
explicitly checks that verifies the palette. If it is not supported, an exception is thrown. My code traverses each 4 bytes chuck used to represent a pixel (The #bits instance variable in Image), plotting it to the destination image. - My code assumes the order of bytes to be Alpha, Blue, Green, and Red. - For #cairoARGB32, the order of pixel information is Blue, Green, Red, and Alpha. Changing my code is possible, but right now I have not time to do it. So I suggest making an image my code can understand. One possibility is to swap the bits yourself, and attach the following palette to the image: Graphics.FixedPalette redShift: 0 redMask: 255 greenShift: 8 greenMask: 255 blueShift: 16 blueMask: 255 To swap pixels, please do something like this (not tested): (1 to: bits size by: 4) do: [:index | | blue green red alpha| blue := bits at: index. green := bits at: index + 1 red := bits at: index + 2 alpha := bits at: index +3 bits at: index put: alpha bits at: index + 1 put: blue bits at: index + 2 put: green bits at: index + 3 put: red] Runar Jordahl _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Runar Jordahl
" If you look at my code, you'll notice the call to
completeContentsOfArea: is covered by an exception handler. I had problems with this method crashing. That might be caused by a bug in VisualWorks." Hi Runar, I don't think the reason for the exception is a bug in VW. The exception occurs when you want to get the completeContentsOfArea: for a rectangular part on your window which is partially/completely covered by another application window. In that case the primitive/the OS doesn't know what is hidden behind the window and returns a bitmap that's only partially filled (I think the unknown parts are just left black). It also returns a list of rectangles that describe the parts that were left black. If you don't mind those parts being black, you can just use #contentsOfArea instead of #completeContentsOfArea:, then the exception doesn't occur anymore. Mark -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Runar Jordahl Sent: woensdag 12 november 2008 12:33 To: Rob Vens Cc: [hidden email] Subject: Re: [vwnc] Epigent AlphaChannelImage Can you possibly check the result of the following statement in method AlphaChannelImage>>displayOn:at: aGraphicsContext medium completeContentsOfArea: rectangle Verify that temporary variable toScreenImage contains the area of the screen to which the icon is to be drawn on. If that image is not correct the next statement (self displayOnImage: toScreenImage.) will of course create the wrong result image. In your case I guess toScreenImage should contain only white pixels. If you look at my code, you'll notice the call to completeContentsOfArea: is covered by an exception handler. I had problems with this method crashing. That might be caused by a bug in VisualWorks. Kind regards Runar Jordahl _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Runar Jordahl
Hi, Here is a small patch to be able to display incomplete images. AlphaChannelImage>>displayOn: aGraphicsContext at: aPoint | toScreenImage rectangle | rectangle := aGraphicsContext clippingBounds moveBy: aGraphicsContext translation. rectangle extent: self extent. rectangle area positive ifFalse: [^self]. [toScreenImage := aGraphicsContext medium completeContentsOfArea: (rectangle intersect: (0@0 extent: (aGraphicsContext medium extent)))] on: Error do: [:exception | ^self]. self displayOnImage: toScreenImage. aGraphicsContext copyImage: toScreenImage to: aPoint ============ Besides, I was not able to translate the palettes. I managed the mask by using png : I draw on cairo, then save as png bits, and reimport the result into an alphaChannelImage. Best regards Annick Fron _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Thank you! I did not fully understand what this patch fixes. Could you
please provide some more details? If there is an general agreement about the patch, I will include it tomorrow. Kind regards Runar Jordahl 2008/11/25 Annick Fron <[hidden email]>: > > Hi, > Here is a small patch to be able to display incomplete images. > AlphaChannelImage>>displayOn: aGraphicsContext at: aPoint > > | toScreenImage rectangle | > > rectangle := aGraphicsContext clippingBounds moveBy: > aGraphicsContext translation. > rectangle extent: self extent. > > rectangle area positive ifFalse: [^self]. > > [toScreenImage := aGraphicsContext medium > completeContentsOfArea: (rectangle intersect: (0@0 extent: > (aGraphicsContext medium extent)))] > on: Error > do: [:exception | ^self]. > self displayOnImage: toScreenImage. > aGraphicsContext copyImage: toScreenImage to: aPoint > ============ > Besides, I was not able to translate the palettes. I managed the mask by > using png : I draw on cairo, then save as png bits, and reimport the result > into an alphaChannelImage. > Best regards > Annick Fron vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Annick
Thank you for providing this fix! Bundle "Epigent Graphics" 1.8
contains the fix. Runar Jordahl _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Henrik Sperre Johansen
AR 55950...
-----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Johansen Sent: Wednesday, November 12, 2008 3:40 AM To: [hidden email] Subject: [vwnc] List vs OrderedCollection addLast: addLast: in List is implemented with a check if there's a need to grow, and a call to a privateAddLast:. In OrderedCollection, addLast: has the same structure, but no separate privateAddLast:. Instead it has a addLastNoCheck: which basically does the same thing as privateAddLast, but gets used by other methods than addLast:... Would it perhaps be a good idea to make these two methods work the same way? (ie: the List way, so in OrderedCollection rename addLastNoCheck: (or have it call privateAddLast: for compatability reasons), and have addLast: call it) Cheers, Henry _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
For context, I stumbled upon this when trying to speed up the addAll:
removeAll: methods somewhat. There's quite alot of places where for the batch operations' pre/post-conditions (like enough space checks) could be more efficiently obtained by a single operation, and then a privateAdd:/Remove: for each object, than the "naive" way of validating once for each object added. I quickly discovered it's somewhat painful to the above though, as you've got to be very careful about subclasses with different pre/post-conditions ;) super super! Happy new year all! Henry Valloud, Andres wrote: > AR 55950... > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Henrik Johansen > Sent: Wednesday, November 12, 2008 3:40 AM > To: [hidden email] > Subject: [vwnc] List vs OrderedCollection addLast: > > addLast: in List is implemented with a check if there's a need to grow, > and a call to a privateAddLast:. > In OrderedCollection, addLast: has the same structure, but no separate > privateAddLast:. > Instead it has a addLastNoCheck: which basically does the same thing as > privateAddLast, but gets used by other methods than addLast:... > Would it perhaps be a good idea to make these two methods work the same > way? > (ie: the List way, so in OrderedCollection rename addLastNoCheck: (or > have it call privateAddLast: for compatability reasons), and have > addLast: call it) > > Cheers, > Henry > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |