What is the absolute relevance of bitmap editors?

[Xhris]

Xhris

You posed this question for discussion:

What can bitmap editing software (like Photoshop) do that vector software (in principle) can’t?

My answer is script recording.
Like corel photo paint offers, which are saved as .csc files
See sample
This tool is so useful but cant be done in vector programs I believe

This is interesting, but too vague for me to comment. What about it makes you think it can't be done in a vector program? (And I should probably say that this question was referring to the artistic output of the package, not some explicit methodology).

Or are you really just being sarcastic that you want it in your favourite vector package?

[aridzone]

As far as I understand script recorders a based on bitmap pixels and cant be done with vectors.
And I think this has to do with artistic output not just methodology.
Done in 18 seconds:

[Xhris]

As far as I understand script recorders a based on bitmap pixels and cant be done with vectors.
And I think this has to do with artistic output not just methodology.
Done in 18 seconds:

It's easy to imagine the equivalent being applied to:

1. vectors
2. bitmaps in vector (or bitmap) programs (the equivalent to your example above)
3. the application of effects to both vectors and bitmaps.

All scripting is, is a series of hand produced actions done automatically in sequence. It certainly could be done in ANY piece of software, in any discipline (e.g. macros).

Oh, I like my picture.

[jamesmc]

Yeah, scripting in vector, I think they call that Flash.

or more specifically, action script.

Isn't part of it already in Xara Xtreme and Pro?

[remi]

No, scripting means automation of a graphics editor. Inkscape is able to do that, Corel Draw and Adobe Illustrator also....

[jamesmc]

No, scripting means automation of a graphics editor. Inkscape is able to do that, Corel Draw and Adobe Illustrator also....

Ah yeah. That is just a use of a script type language like python etc.

You end up making a bunch of macros really.

This is the one in PSP XI

[Xhris]

Well, either way, we've all now identified that scripting isn't something only possible in bitmap software.

[David O'Neil]

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.

I stick by my earlier statement--the two approaches are different at the core, and even though you can approach (and even excel) bitmap output using vector techniques, it will be very difficult to get vector quality from bitmap objects, and there are some big gotchas in the mess, such as the 'color selection' example I am trying to get you to think about.

[Xhris]

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.

...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.

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.

...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.

[David O'Neil]

You are not seeing a bigger picture.

Let us say that you have a 1500x1500 pixel 'bitmap/vector' combination. At one step you select all pixels colored 0xBABABA (or whatever color) and change them to another color, and do some processing on them. (Maybe you give them a starburst effect.)

Now, let us assume that some of those 'pixels' were the result of overlaid transparencies of various colors/transparency percentages, whereas others were not. Let us say that 500 pixels were affected.

Then, down the road, the designer changed some of the base hues in some of those transparencies, or he changed the transparency percentages, so that the final blended color on 122 of those resultant pixels are no longer 0xBABABA. Does the software package all of a sudden throw the processing on the pixels away? Does it keep it? There is no way for it to know what the designer wants in such a situation.

In addition, if you have vector objects that are 20 times more detailed than the 'bitmap' graphic, it is very likely that the final graphic would look low resolution because the bitmap portion is making it look washed out, just as my earlier 'thumbnail example' was trying to point out to you.

The previous scenario is extremely likely to occur when you scale your final output drawing.

The previous logic leads to the conclusion that you will always have to design your graphics, whether they are vector or bitmap, to at least the final resolution that you want your final product to have.

I think that what we will end up with is packages that integrate bitmap and vector into a usable amalgam that is quite powerful. They may primarily be vector, but bitmap operations will always continue to be used on bitmap objects--all objects will not necessarily be vectors.

For fun, wrap your head around what it would take to make a program like ArtRage into a pure vector package. It is not an easy task, due to the extreme amount of processing that would be involved. I will not argue that it is possible, but feasible? You might quickly get into logic like the first example I discussed, making it a bugger to get it intuitive to use.

Best wishes,
David

ps - So the 'absolute relevance of bitmap editors' is that they are, and will continue to be good at what they do, and there will always be some need for them.