Quote Originally Posted by David O'Neil View Post
And I return you to my very first reply. Selecting every pixel of a certain color and changing them to another would be extremely difficult to do when having vector and bitmap items together in one 'composition,' and using a quasi-vector approach.
Quote Originally Posted by David O'Neil View Post
...and there are some big gotchas in the mess, such as the 'color selection' example I am trying to get you to think about.
(Just to be clear, this isn’t indented to be a bashing response; just thorough.)

I now appreciate what you are saying; to be more explicit and lucid: consider the case where a ‘quasi object’ was used to say smudge a vector and bitmap group using, say, the method proposed above. How do you select regions of similar colour if the result is 'independent' of resolution? Regions of similar colour could still conceivably be selected down to the internal resolution of the software – if that’s how it would work. How CPU intensive this would be is debatable, but it’s nevertheless conceivable.

But let’s just look at Live Effects for a moment. This is a more resolution dependent (i.e. not resolution ‘independent’) product of what I’m talking about. In this case, the object is given some more complex effect defined by some algorithm, e.g. mosaic, bevel, blur etc. the object instead of, say, direct-draw smudge. The output is not independent of resolution, but rasterised by an amount you specify. It’s possible that LE’s could produce explicit vector (resolution independent) output, however, remember they were designed for bitmap programs, and hence rasterise the output. After this effect is applied, another can be applied on the resulting image. You can thus have a stack of processed vector-like effects (in that they are recalculated if one in the stack is changed) on any one object. The idea of stacking processes is one additional consequential consideration to the issue you raise – namely that if underlying object(s) changes the ‘quasi-object’ reprocesses. The difference with this analogy though is that all current LE’s (except feather) are not independent of resolution as mentioned. Perhaps these quasi-objects I mention would not all necessarily be resolution ‘independent’, and be rasterised significantly. It would still be a vector process (regenerated with change by reprocessing the algorithm), but would be a relatively low resolution output. I suppose in this case, bitmap programs do some vector-like processes – in that you can use live effects (low resolution vector-like processes).

Let’s also look at the first party bump map live effect. By definition, its output has to be a bitmap, as the effect is designed to work on bitmaps – to simulate 3D surface depth. The true vector equivalent would require 3D processing, so that lights could be shined on surfaces – this is what we see in Xara3D for example.

Quote Originally Posted by David O'Neil View Post
I stick by my earlier statement--the two approaches are different at the core.
Yes, there's no dispute here, but the point being made is that all these bitmap operations can be done in a vector package with the right tools, which needn't not be there (this is the amalgamation of the two software types that was mentioned). I highlight again the three distinct points I made in my second longer post: 1. dealing with bitmaps; 2. dealing with ‘vectors’; and 3. applying effects to both vectors and bitmaps. All three can be done in a single (vector orientated) package. Xara actually already does all 3 – if proof were required of what I’m theorising about in practice – but doesn't have the tools found in bitmap editing software...yet.

Quote Originally Posted by David O'Neil View Post
...it will be very difficult to get vector quality from bitmap objects...
I'm not quite sure what you are meaning by this, but bitmaps are frequently used in vector packages. Feathering a photo in the CatWoman example demonstrates this clearly. The whole point of using bitmaps in vector packages is that they can be rescaled, i.e. the resolution varied from its fixed value without the information being lost on re-sampling to the bitmap resolution as happens in bitmap programs (of course you can't add information that isn't there in the bitmap itself).

I predict a vector-orientated future (the timescales of which is anyone’s guess), with tools found in bitmap software combined into the vector software, and it being implemented in such a way that these bitmap tools can effectively be used on both traditional vector objects (those independent of resolution), and plain bitmaps. Xara have hinted they are heading in this direction, if not using the suggestions I proposed above.