What is the absolute relevance of bitmap editors?

[aridzone]

Thanks guys for clearing that up about script recorders for vector programs.
I have renewed hope that Xara will implement one in a coming version

[Xhris]

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.

This is interesting, as we are now exploring the specifics of the three general points I made above, and you are highlighting interesting subsets of them.

What you are specifically highlighting here is that some combination of vector effects may not be able to be re-processed if certain changes are applied to mid-stack operations. There thus may be limitations to applying vector effects to vector/bitmap combination objects as discussed in my point 3 – namely (and only) when applying vector-effects to selected regions of similar colour (it was good thinking of you to highlight this). In this case, you may very well have to rasterise and produce a bitmap to work with. But this is covered in point 2 and can still be done in a vector program (e.g. lock live effect). A vector program is everything (in principle) that a bitmap program is, and considerably more. This is why I’m sure they’ll be less dominant in the long term future.

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.

Now this is a different point entirely, and not really relating to anything I’m talking about. Here you are highlighting the limitations of bitmaps; they contain only a fixed amount of information, and thus when scaled up, no additional information is provided. This results in obvious pixelation, in contrast to vectors which are redrawn from their algorithms at the new desired effective resolution. In your thumbnail example, you seemed to imply that you would use a vector package to somehow add more information to a bitmap that isn’t actually there so that the bitmap somehow became truly vector-like and independent of resolution. This is not related to any of the three points I've discussed above, and I agree it’s nonsensical.

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.

Yes, we agree here, bitmap operations will continue to be used on bitmaps. But I was trying to introduce the idea that they not necessarily need to do so for some types of operation, e.g. vector eraser, smudge, etc. Vector feathering of bitmaps is one excellent example that proves the point I'm making.

I also remembered I've sort of discussed this idea before, but less in depth here:

“Expression's approach is to make clear distinctions between pixel and vector methods. I'm thinking of new approaches to unifying the two. The Xeus plugin for example got me thinking. A (relatively simple compared to Photoshop) bitmap editor loaded and you drew on a vector object. When you closed, that object acquired the pixel editing. I imagine a situation where any object can become a canvas (that could extend beyond the object itself). Pixel based operations can be performed on that object, and the parts of it which have been pixel-edited are rasterised, whereas the rest of the object retains it's resolution independence. The image below perhaps illustrates my thinking. Live effects share some similarities to this, however the effects are applied to, and therefore pixelate the whole object as far as I've seen.

The effects may not necessarily even need to be pixelated. Take vector feathering for example; blurring the edge of a vector shape independently of resolution. If you wanted to blur only one edge of an object and had a vector blur tool analogous to a pixel based blur tool - why can't that be done? Tools that work on both vectors or bitmaps.”

This idea is slightly different to what I propose here, but is an alternative approach. The idea here was inspired by the second picture: performing a blur on a bitmap (but it not need be) with the result appearing to be higher resolution. The ‘object as a canvas’ idea is actually less flexible than the quasi-object that performs operations on the underneath image.

[David O'Neil]

...There thus may be limitations to applying vector effects to vector/bitmap combination objects as discussed in my point 3 – namely (and only) when applying vector-effects to selected regions of similar colour...

There may be more instances with limitations of this nature. Until you program such a beast, you will probably not know.

...Here you are highlighting the limitations of bitmaps; they contain only a fixed amount of information, and thus when scaled up, no additional information is provided.

To an extent, I was also trying to point out that vectors are also limited to what the designer designed it for. You have to create enough information in your vector picture to obtain good results at 300dpi, 600dpi, or whatever dpi you are working with. If you double the scale of your drawing, chances are, you need four times the amount of vector information to make the new drawing look just as good as the old drawing at the same dpi. Otherwise, the scaled picture will only have 1/4 of the texture that the non-scaled one has if you are still outputting at the same dpi. Feathering may make it look smoother, but the density of features will be lacking. (I hope that was clear.)

(Stated differently, if you created a 600dpi picture via vector, and the smallest thing you designed for was a 1/100" pimple being visible (approx 6 pixel x 6 pixel area), and then doubled the scale of your drawing, the smallest 'feature' would be a 2/100" pimple, not a 1/100" pimple, so the visual information would be 1/4 what it was non-scaled. It will look clearer than if you simply scaled a bitmap, but it will also have less visual information density than the non-scaled one.)

In your thumbnail example, you seemed to imply that you would use a vector package to somehow add more information to a bitmap that isn’t actually there so that the bitmap somehow became truly vector-like and independent of resolution.

No I didn't. You did. I pointed out that you probably could not get any better results by vectorizing a bitmap and scaling it than you could by using the best bitmap scaling techniques available.

Yes, we agree here, bitmap operations will continue to be used on bitmaps. But I was trying to introduce the idea that they not necessarily need to do so for some types of operation, e.g. vector eraser, smudge, etc.

What I read implied that you were saying that all operations on a bitmap could be done using vector tools. You have just stated that that is not the case, and that bitmap editors will still be relevant. We agree.

Best wishes,
David

[Xhris]

Okay, so now the cards are on the table, we've concluded that bitmap editors are not and may never be obsolete (something I never set out to challenge really). But that vector programs are likely to become dominant on the grounds that they are (or could be in principle) everything bitmap programs are and significantly more. Namely, that vector programs can handle both vector and (in principle) all traditional bitmap operations on bitmaps (via incorporation of the bitmap editor toolset). And furthermore, with some limitations regarding multiple, stacked operations on selections of similar colour, could apply bitmap like effects to any objects. Therefore, the original question of what is the absolute relevance of bitmap editors? They are relevant in that they do something (i.e. handle bitmap operations only), but are inferior in that they are relatively limited compared to the potential of (future) vector applications.

[handrawn]

They are relevant in that they do something (i.e. handle bitmap operations only), but are inferior in that they are relatively limited compared to the potential of (future) vector applications.

Even if this postulation is true, it does not make them inferior, that is leading the argument.

ArtRage is not for example inferior to Corel Painter, it just doesn't pretend to be something it's not.

[David O'Neil]

...They are relevant in that they do something (i.e. handle bitmap operations only), but are inferior in that they are relatively limited compared to the potential of (future) vector applications.

I agree with handrawn on this one. When you can get effects every bit as good with a bitmap editor as you can with a vector editor, you cannot call the bitmap editor 'inferior.' At that point, among the only benefits a vector version of the drawing would have is the ability to scale and have your edges remain crisp, but as far as I understand, PS is fairly good at that to a certain extent.

[Xhris]

I was referring to the whole scope of the package rather than the resulting output. By definition that vector programs can (in principle) do everything bitmap editors do and considerably more (as we've discussed above), makes them a superior piece of software. That when dealing with bitmap operations, both could (in principle) get the same result, makes neither inferior in that respect. This was my point, for the purpose of predicting that in the long term future, vector packages may become dominant on the grounds that they do more.

[handrawn]

I was referring to the whole scope of the package rather than the resulting output. By definition that vector programs can (in principle) do everything bitmap editors do and considerably more (as we've discussed above), makes them a superior piece of software.

Greater [theoretical] ability does not necessarily mean superiority. There are other issues.

[Xhris]

Greater [theoretical] ability does not necessarily mean superiority.

In this context it does.

There are other issues.

Like what? That's what this thread is about.

[handrawn]

In this context it does.
.

No it does not. A hypothetical possibility is not superior to something that is already up and running and kicking ass.

Like what? That's what this thread is about.

See above.
See also price, usability, speed .......... etc
And who knows what else since its all so hypothetical?
The thread is about relevance I thought.
Artrage is far more relevant to my grandaughter than Xara.
Go figure.