14 Replies Latest reply on Dec 10, 2007 10:21 PM by nagromme

    Lingo Airbrush

    Luisa Klose Level 1
      I have Director 8 and I'm trying to develop an airbrush in Lingo that works like ones included with most image editing applications. What I have so far works pretty well although it's not as good as it should be. There seems to be a problem with the way Director composites alpha channels. The DIR file with the pertinent code can be downloaded from:

      DIR file
      or
      ZIP file

      To see the problem, try painting with white (rgb(255, 255, 255)) on a white background. One would expect the brushtrokes to be invisible, but they're not. The transparent areas of each brushtroke end up as shades of very light grey - making it look like the brush is "dirty."

      I have tried everything that I can think of to fix the problem but I'm stuck. My hope is that someone here will be able to help me to get this airbrush working the way it should. Perhaps it's already as good as it will ever be. Either way, you're welcome to use the code if you're interested in Imaging Lingo.
        • 1. Re: Lingo Airbrush
          duckets Level 1

          Interesting problem!

          I believe this is something to do with the way that director rounds off rgb values, but other than that I'm not sure why it causes this particular behaviour, however I believe it is not a problem in your code, but a flaw in the copypixels routine in director.

          The symptoms are this:
          If you are copypixelling one image with an alpha channel onto a 2nd image, the resulting colour becomes more innacurate as the level of transparency increases.

          The maximum level of transparency is 255 (completely transparent), and no problems occur when using this value in the alpha channel, however for values approaching 254 (very very faint), the resulting colour values seems to tend towards exactly half the true source colour values.

          For example, if you have an image containing "red" rgb(255,0,0), with an alpha channel containing "almost white" rgb(254,254,254), the combined result is an almost invisibly tranparent red. However if you repeatedly copypixel this 'almost invisible' image onto a 2nd image so that the opacity gradually adds up, the resulting colour eventually reaches a "dark red" colour of rgb(127,0,0).

          If the alpha channel is a little darker, say rgb(253,253,253), the resulting colour after many repeated copypixels is a little closer to the original colour - rgb(170,0,0). As the alpha channel gets darker, the end result approaches the original colour. With an alpha of rgb(220,220,220) you get rgb(247,0,0). Closer still, but it never reaches the original source colour no matter how many times you copypixel it over.

          Now - I can understand why this happens with coloured source images, like the red example above (rounding off innacuracies because the rgb values are integers), but I don't understand why this also happens with white-on-white. If you have a white source image, with an "almost white" alpha channel rgb(254,254,254), then repeatedly copypixel it onto a white destination image, the result actually tends towards mid grey as the repetitions add up. I don't understand why this non-white value is creeping into the copypixels routine.

          I'd be interested to hear anyone else's further comments on this problem.


          - ben



          • 2. Re: Lingo Airbrush
            Level 7
            ...this "has" something to do with...


            --
            Craig Wollman
            Word of Mouth Productions

            phone 212 928 9581
            fax 212 928 9582
            159-00 Riverside Drive West #5H-70
            NY, NY 10032
            www.wordofmouthpros.com


            "duckets" <webforumsuser@macromedia.com> wrote in message
            news:ehaeid$4lc$1@forums.macromedia.com...
            > Interesting problem!
            >
            > I believe this is something to do with the way that director rounds off
            > rgb
            > values, but other than that I'm not sure why it causes this particular
            > behaviour, however I believe it is not a problem in your code, but a flaw
            > in
            > the copypixels routine in director.
            >
            > The symptoms are this:
            > If you are copypixelling one image with an alpha channel onto a 2nd image,
            > the
            > resulting colour becomes more innacurate as the level of transparency
            > increases.
            >
            > The maximum level of transparency is 255 (completely transparent), and no
            > problems occur when using this value in the alpha channel, however for
            > values
            > approaching 254 (very very faint), the resulting colour values seems to
            > tend
            > towards exactly half the true source colour values.
            >
            > For example, if you have an image containing "red" rgb(255,0,0), with an
            > alpha
            > channel containing "almost white" rgb(254,254,254), the combined result is
            > an
            > almost invisibly tranparent red. However if you repeatedly copypixel this
            > 'almost invisible' image onto a 2nd image so that the opacity gradually
            > adds
            > up, the resulting colour eventually reaches a "dark red" colour of
            > rgb(127,0,0).
            >
            > If the alpha channel is a little darker, say rgb(253,253,253), the
            > resulting
            > colour after many repeated copypixels is a little closer to the original
            > colour
            > - rgb(170,0,0). As the alpha channel gets darker, the end result
            > approaches the
            > original colour. With an alpha of rgb(220,220,220) you get rgb(247,0,0).
            > Closer
            > still, but it never reaches the original source colour no matter how many
            > times
            > you copypixel it over.
            >
            > Now - I can understand why this happens with coloured source images, like
            > the
            > red example above (rounding off innacuracies because the rgb values are
            > integers), but I don't understand why this also happens with
            > white-on-white. If
            > you have a white source image, with an "almost white" alpha channel
            > rgb(254,254,254), then repeatedly copypixel it onto a white destination
            > image,
            > the result actually tends towards mid grey as the repetitions add up. I
            > don't
            > understand why this non-white value is creeping into the copypixels
            > routine.
            >
            > I'd be interested to hear anyone else's further comments on this problem.
            >
            >
            > - ben
            >
            >
            >
            >
            >


            • 3. Lingo Airbrush
              Luisa Klose Level 1
              Thanks for your response, Ben.

              I should mention that in addition to the approach I used in the sample file, I also tried the #createMask command with every #ink - without success. As a last resort, I created a test graphic with an alpha channel in Fireworks and layered copies of it in Director using multiple sprite channels, and the same thing happens. As I said in my original post, it appears that the problem is with the way Director composites alpha channels.

              I'm still hoping that there's a workaround that doesn't involve waiting for a new version of Director.
              • 4. Re: Lingo Airbrush
                FasterPastor
                FWIW: I have 8.5 and the same problem exists there.
                • 5. Re: Lingo Airbrush
                  FasterPastor Level 1
                  I just realized when making this post that I have yet to use the free updater for 8.5.1 since switching to this PC. It boasts something to do with anti-aliasing, which is not exactly what is addressed here. But I will download and apply the update and see if the problem lingers.
                  • 6. Lingo Airbrush
                    Luisa Klose Level 1
                    Thanks for trying it out, Doug. I doubt that the update will make a difference in this case, but I'm interested anyway.
                    • 7. Re: Lingo Airbrush
                      FasterPastor Level 1
                      You're right. The update did not address that issue. Same problem with 8.5.1. Oh well. I tried.
                      • 8. Re: Lingo Airbrush
                        Luisa Klose Level 1
                        Much appreciated anyway :)
                        • 9. Re: Lingo Airbrush
                          duckets Level 1
                          quote:

                          Originally posted by: Craig Wollman
                          ...this "has" something to do with...



                          Hmm, correcting grammar on web forums - good luck with that! :-P

                          - Ben
                          • 10. Re: Lingo Airbrush
                            duckets Level 1
                            quote:

                            Originally posted by: Luisa Klose
                            I'm still hoping that there's a workaround that doesn't involve waiting for a new version of Director.


                            I don't think a new version of director will solve the problem (it occurs here in MX04). However you can solve the problem by doing the blending calculations yourself. Because your brush is relatively small (9x9 pixels), it's actually pretty fast to just go through each pixel of the brush, and do the blend calculation against each corresponding pixel of the image "by hand" so to speak, using getPixel and setPixel. This is a lot slower than using copyPixels of course, but it may still be fast enough for your needs.

                            Something like this, for each r,g,b of each pixel affected by the brush (where alphalevel is a float between 0.0 and 1.0):

                            newRed = (canvasPixel.red * (1-alphaLevel)) + (brushPixel.red * alphaLevel)

                            I've added the change to your demo (and shuffled things around just a tiny bit - you were using closed repeat loops for the drawing!). I've added two buttons which switch between the old mode and the new mode. With the new accurate mode, the problem seems to be gone. I also added an extra display to the right which is a high-contrast version of the canvas, which shows up the dirtyness much more clearly when it occurs.

                            here it is: http://www.robotduck.com/misc/airbrush/


                            enjoy :-)

                            - Ben


                            • 11. Re: Lingo Airbrush
                              Luisa Klose Level 1
                              Thanks, Ben.

                              I was able to load the DIR file in my browser and it works the way it should. Unfortunately, I wasn't able to load it in my version of Director, but your explanation should be good enough. One thing I'm curious about though: what do you mean by "you were using closed repeat loops for the drawing?" Apparently there's a better way to do it and if I could have seen the code I probably wouldn't have to ask you to explain it. :)
                              • 12. Re: Lingo Airbrush
                                duckets Level 1
                                Ah I see you said you're running director 8. I'm using mx04 here, but I tried it in director 8.5 and it works ok. I I'm not sure if I can save as a format that v8 will open.

                                What I mean by the repeat loops is that you are 'locking' director by performing a 'repeat while' command when drawing, until the user releases the mouse. This can cause problems (particularly on Apple Macs, I think), and it means that as you develop your application further, no other code can execute at the same time.

                                My change was just, instead of using a repeat loop, it checks each frame to see if the mouse is still held down, and draws the next portion of the stroke - so that the 'exitframe' handler is still happening each frame as the user is drawing.



                                • 13. Re: Lingo Airbrush
                                  Luisa Klose Level 1
                                  Ben,

                                  That's what I imagined you were talking about, but I thought that maybe you were referring to a fancy advanced approach that I had never considered. ;)

                                  I'm working on an update to this thing:

                                  PixelToolbox

                                  It's been a few years and I don't remember why I chose to use a repeat loop instead of exitFrame, but I'll be there again soon enough.

                                  Thanks for your help. You solved the problem. :)

                                  -Luisa
                                  • 14. Lingo Airbrush
                                    nagromme Level 1
                                    I'm having this same white-becoming-gray issue, both with alpha compositing in Lingo AND with simply overlapping several white sprites with alphas. (My images are too big to be doing any pixel-by-pixel Lingo at acceptable speeds as was suggested above.)

                                    The simplest case that shows this: an all-white sprite on an all-white background cannot be seen. UNTIL you add an alpha. Now the sprite turns to light gray (RGB 254)--even the fully solid parts of the sprite. Yet the paint editor window still shows pure white. (Now layer a few of these sprites and noticeable gray smudges appear.)

                                    Has any solution or workaround emerged? Is it impossible for an image to display any colors above 254 if an alpha channel is present?

                                    Thanks in advance! (I'm in MX 2004.)

                                    quote:

                                    Originally posted by: ducketsIf the alpha channel is a little darker, say rgb(253,253,253), the resulting colour after many repeated copypixels is a little closer to the original colour - rgb(170,0,0). As the alpha channel gets darker, the end result approaches the original colour. With an alpha of rgb(220,220,220) you get rgb(247,0,0). Closer still, but it never reaches the original source colour no matter how many times you copypixel it over.

                                    Now - I can understand why this happens with coloured source images, like the red example above (rounding off innacuracies because the rgb values are integers), but I don't understand why this also happens with white-on-white. If you have a white source image, with an "almost white" alpha channel rgb(254,254,254), then repeatedly copypixel it onto a white destination image, the result actually tends towards mid grey as the repetitions add up. I don't understand why this non-white value is creeping into the copypixels routine.