CompuServe Messages

Erik (sorry about the name screwup… ;^( ), I didn't "neglect to mention it" ("it" being area selction inaccuracy), I wasn't aware of it as a problem. Further, if it used to be a problem it likely isn't now because the area selection code has all been rewritten for the next release. :^) I have *never* had an area selection problem such as you describe; of course, I work in magnify because when an image is scaled down, you can't always see the precise boundries you want to work with. You must remember that IM R/t always scales the display to match the aspect and overscan and etc, so many images cannot be pixel-for-pixel edited without some level of zoom – this is inherent. Regarding autoscroll… I _hate_ that and that's why it's not there. I prefer to combine the selected areas – you have much more precise control and you don't pay the time penalty for redraws every time you get too close to an edge without thinking. I suppose we should add it with a user option switch (so I could turn it off). I'll make a note of it. Since a large number of our customers ARE producing FLC's that work, it seems to me that your FLC player may not be up to the task of dealing with the FLC you are generating. Some FLC players are limited to specific resolutions or ranges of resolutions. This may be the root of your problem – or there may be a bug that specifically affects the way you are doing things as compared to others' methods. Tech Support is not at liberty to divulge release dates for new versions unless I *specifically* say so, and I have not, nor will I at this time. Don't blame them, blame me. :^) Our "little boolean operators" do exactly what you describe. Press the appropriate one (just like you'd press the "little shift key" in PS) and use the make mask operation under process and it'll do just what you describe (with any set of area selection tools)… add or remove areas. once you've got the complete area done, using redo and any operation gets it done. The use of "actual" images of the brush are a bit problematical as well, due to the huge number of display modes it'd have to be supported in. Not impossible, just really, really, hard. We'll probably add it sometime when we've got several weeks to spend on that one issue. Since what's there works just fine, it's not a high priority. You can't "XOR a B&W zebra stripe", Erik. When you XOR, you get colors which are ordinal opposites of the palette number of the pixel under the XOR. You have to _draw_ a zebra stripe. When you draw one, you have to redraw the image data underneath it. When you redraw in the case of a low color image, you have to know either (a) the exact display state for every surrounding pixel to reconstruct the dither or, (b) save every pixel, or (c) redraw without dither (which seriously degrades the image and takes mucho time). When you XOR a line, XOR'ing it again removes it quickly and easily and without resorting to the image data or dither issues. Those are very time consuming (in the CPU sense) and that's the precise reason that the functionality isn't there. It's easy for an end user such as yourself to forget the color limitations that stock Amigas impose on software; when you're picking colors for image fidelty from a group of 16, for instance, any two colors dedicated to "zebras" significantly (as in oviously) degrade the display image quality – this is something we like to avoid as much as possible. Heck, it we had just 256 color and 24-bit to deal with seriously it'd be a whole different ball game. But that's not the case with the Amiga. Or even the PC, anymore. The co-ordinates problem sounds like it would be easily fixed, and should be. I'll see to it. Imagemaster R/t can "erase" to a previous version of an image easily. Load it into a buffer. Keep it around as you work (in fact, make the buffer each time you decide you have a "keeper" version. When you want to go back, select it as secondary and rub it thru. Works just fine. Photoshop: Imagemaster R/t is not a Photoshop clone. Photoshop is fine, for what it does (which is a darned sight less than IM R/t can do). It's got some very convenient tools and shortcuts; and for "prepress" ops, it's pretty much without peer at this time. However, IM R/t is designed to be a generalized image manipulator – and it far outperforms Photoshop at that task. I'm NOT saying we shouldn't use some of the capabilities that Photoshop has – sure, they'd be very convenient. But in point of fact, I could list you literally hundreds of operations you just can't do in Photoshop at all which IM R/t does without breaking a sweat. On Production actually got the credit right, eh? Amazing. After the all the botch-ups in that other recent review (new media, was that it?) where they screwed up darn near everything, it's nice to hear that some accuracy snuck in somewhere. $599 list price, indeed. Hah! Thanks for the feedback.