I wanted to start a thread on what vector file formats our customers think we should be supporting. And why those particular ones would be desirable.
This all ties into thinking we are doing in our current work finishing up V5 and also building the underpinnings of the more futuristic (but very real and amazingly awesome) V6.
This is going to be a somewhat long winded discussion, but if you make it through the whole thing, you will get a much better understanding of how Studio Artist works, as well as an understanding of the history of the incorporation of vector effects into the program over time.
Then you will be in a position to make some informed comments that might influence it's further development into awesome new directions. Because we do really value your comments and suggestions.
...
What are Those Existing Vector Output Options?
So what are your options right now in Studio Artist for vector output. Well, we support eps and svg for both vectorizer output as well as output from PASeqs that generate vectors in their recorded action steps.
There's also a somewhat clunky feature where you can use the svg file output features to generate a pdf via the pdf generation options available in apple's print dialog we provide under Action : Generate SVG : Print with PASeq menu.
And, we also support a custom vector file format you can use when you export a bezier path frame, via File : Export : Export Bezier Path Frame menu command. This custom format is also used internally to different Studio Artist preset types, as we will discuss.
...
So what are the advantages-disadvantages of these various features? And how did we end up with them in the first place.
The Custom Synthetik Bezier Vector Format
Our custom bezier path frame format was needed so that we could save and restore bezier path frames, so that showed up very early in the long and twisted history of Studio Artist.
Each Studio Artist layer consists of a RGBA frame buffer as well as an associated bezier path frame. The RGBA buffer stores a red-green-blue-alpha pixel raster image associated with that layer. The bezier path frame stores a set of bezier paths associated with that layer.
The bezier path frame is hidden, you don't see it unless you are specifically in Bezier Operation Mode.
How you use the bezier path frame is also up to you. Like many Studio Artist features, it is very user configurable and can be used in many different ways.
A common question, is, why didn't you just use something standard like eps for saving and restoring a bezier path frame?
My answer is, have you ever looked inside of an eps file generated from a program like Illustrator. Something simple like outputting a triangle has a huge amount of crap buried inside of this supposedly simple vector file. Now it would not have to be that way, the eps output generated from Studio Artist is pretty straightforward for example. But allowing for import of any arbitrary eps file sets us up for all kinds of potential problems, we basically would need to provide a complete postscript rendering engine (remember, postscript is a programming language too, so we would need to support all that that entails). When all we wanted to do was save and restore a few bezier paths (and their associated colors). So you can see why we made the decision to use our own relatively simple proprietary vector file format for this.
Now over the years things evolved, so now bezier paths can also be embedded inside of things like paint presets, or PASeq presets, so that custom format actually gets used in all kinds of places like that in a hidden way. You don't really know it's there, but it could be residing inside of some of your paint or PASeq presets.
PASeq presets could potentially have all kinds of different bezier frames embedded inside of them (remember, you can keyframe interpolate complete bezier paintings in individual auto-paint action steps). Stored as IFF information chunks in our proprietary vector format. Which is very memory efficient i might add.
EPS Vector Format
The history of eps output from Studio Artist is an interesting one. Because in the beginning, Studio Artist did not do direct vector drawing. We had a hybrid graphics model, which involved vector paths that were painted with raster paint. Those vector paths were encoded as bezier paths. The raster paint was applied along the vector bezier path as a series of paint Nibs. Think of it like a string of pearls laid out along a string. The pearls are the raster paint nibs, the string is the vector bezier path.
The hybrid graphics model was cool, because in theory you could re-render a recorded paint history to a different resolution, and then play back the re-rendered paint history into a higher resolution canvas. Re-rendering involved interpolating the underlying bezier path, and then painting on it with a larger string of bigger raster paint Nibs. Any parameters associated with things like controlling the appearance of procedural textures used in the raster paint nibs could also be re-rendered.
So re-rendering a painting basically involved re-painting it into a higher resolution canvas, which gives you more detail then you would if you used a raster interpolation algorithm to blow up a lower resolution painted canvas.
So you get the best of both worlds with the hybrid graphics mode, the rich organic visual quality of raster paint, with the rescalability of vector paths.
The original EPS Output Implementation
However, back in those early days, when dinosaurs and mac SE's with floppy discs roamed the earth, we thought it would be cool to allow for vector output derived from our raster auto-painting. So the vector drawing was not happening onto the Studio Artist canvas, it was generated as a separate series of commands inside of a eps file generated as Studio Artist painted with raster paint.
Now this involves a level of indirection, since you generate a raster painting recorded in a history or PASeq sequence. Then you play it back and that painting then gets converted into a series of eps vector output commands stored in a vector output file. And since eps vector graphics is greatly limited in terms of the range of visual features it can generate, you were restricted to basically flat colored paint nibs, or flat colored vector regions for your vector paint strokes.
But, it seemed like a cool idea. And as it turned out, Flash had an eps import option where you could take a folder of eps files and convent them onto a flash movie with one menu command. So we provided eps output from our Action : Process with Paint Action Sequence to EPS menu commands. So you could take a movie file for example, and render it out as a series of painted eps frames, which could then be converted into a flash movie.
These early eps output features still live on in the Vector Output control panel of the paint synthesizer. If your Main Render Option is Raster, there is an EPS Strokes control available there. The setting for that determines how eps paint strokes are generated from your raster paint stroke being drawn into the raster canvas layer.
The generated eps paint strokes are placed in the eps vector file being generated, they are not being used for drawing into the canvas you see on the screen.
Some of these eps paint stroke representations are pretty simple, like spheres on a path, or a single width colored bezier path. And unless you are painting with really simple flat color raster paint, what comes out of the eps file is going to look potentially very different than your paint canvas. So your rich organic wet paint preset is not going to be rendered that way when drawing flat color vector spheres on a path into the eps file.
Some of the other options that EPS Strokes control provides are more elaborate. Vector Blanking, or Color Vector Blanking, actually use the vectorizer dynamically to try and vectorize the individual raster paint stroke you just painted. So they might capture the magic of a rich organic raster paint a little bit better in the generated eps output. but it's still going to be a poor substitute for the real thing if the real thing is some nice organic wet paint effects.
So when you record paint preset (manual or autodraw) into a PASeq or history sequence, when you use the Generate EPS file from PASeq features to generate an eps file from it, if the paint preset is a Raster main Render Technique, then this ancient 'let's try to fake some vector output while drawing our raster paint stroke' code is what is generated the eps output for each paint stroke.
Based on the setting of the EPS Stroke parameter as described above.
Now i don't think these old eps output features were used by a ton of people. A few people did know about them and did some interesting things with them. An they are all still there, buried inside of the vector Output control panel in V4.
V4 of course supports direct vector painting, so things get more interesting as we move into the V4 implementations of this stuff, but first i want to finish this digression of ancient history that still lives buried in the SA code by talking about the original vectorizer eps output support
The Original EPS Vectorizer Output Features
The vectorizer was always intended to output vector files. After all, it's main goal is to take a raster image and convert it into a vector image.
However, it did it via a completely different code path than the one used to render vectorizer output into the raster canvas in a studio artist layer. This can be problematic, because it's easy to end up with something that looks one way on the canvas and a different way in the generated eps file.
Since we are still talking about history at the dawn of time, keep in mind that Studio Artist in those early days had no access to a comprehensive vector drawing api, other than whatever code we wrote ourselves. So the vector output from the vectorizer was rendered in the raster frame buffers in a layer with our custom vector drawing code. Which again, is going to look somewhat different than vector regions rendered via eps.
Vector Graphics in V4
Over time the planet evolved, dinosaurs faded from the earth, and we actually had access to a somewhat decent vector painting code api when we switched to the cross-platform application framework we used to build Studio Artist 4.
The original Studio Artist hybrid graphics model (raster paint nibs on a vector path), also got somewhat obscured as we continued to add new features to Studio Artist over the years. Things like Particle pen mode, or Region Fill as Brush pen mode for example, don't fit quite so neatly into our original hybrid graphics model. Direct support of vector painting in the paint synthesizer also typically doesn't fit into the hybrid graphics model of nibs of raster paint on a vector path model.
So as we added all of these cool new features, we figured out various ways to shoehorn them into the existing structure of the paint synthesizer.
Vector painting ended up being accessible from 2 different places. We added some Vector options to the Main Render Option in the Vector Output control panel. We also added an Anti-alias Solid Brush Type to the Brush Type control panel. That also implements direct vector painting, even thought the main Render Option is set to raster when you are using that one.
Either of these 2 approaches to doing direct vector paint also override the behavior of the Region Fill as Brush pen mode, so then you are drawing with real vector regions as opposed to raster regions being generated on the fly by that pen mode.
Vector Painting -the Interior Fill vs the Outline Path
Access to comprehensive vector paint apis also allowed for direct vector rendering in the vectorizer. Which is why the Canvas Render Option parameter was added to the Drawing control panel in the vectorizer.
The Pixel Raster Fill setting for that parameter does things the old fashioned way using our old proprietary vector region drawing code. And note that when you use that one, all of the pixels are filled in for every region generated by the vectorizer. But you don't get nice anti-aliased edges for your vector regions.
The Vector Anti-alias option for this Canvas Render Option parameter does all of the drawing using the nifty new vector paint api calls. So you get nice anti-aliased edges for all of your vector regions.
However, you then run into this issue where those anti-aliased vector regions might not fill in every pixel in the canvas. That's because the region is converted into a bezier region, and then the bezier region is filled in using the bezier region paint api. In some sense the bezier paths generated to describe any arbitrary pixel based region are an approximation to that original pixel region. So the unfilled pixel holes are where the approximation doesn't totally match up with the original pixels.
Each painted bezier region actually has 2 components. The filled interior of the bezier path, and the stroked bezier path itself, which is just drawing the path and not filling the interior. We call the stroked path part of the drawing the Outline. By setting the outline size to 2 or 3, you are essentially making the region fill a little bigger, which typically fills in those missed points you get when you try to approximate a complex pixel region with a bezier path.
You can also do things like set the Outline color to be different than the interior fill color for a region, leading to fun artistic effects.
EPS vs SVG Graphics
So with the release of Studio Artist 4 we now had real vector painting happening in several places in the program. It could be used in the vectorizer. And in paint synthesizer presets that use vector painting.
And in some other not so obvious places as well.
For example, some MSG processors actually might be doing vector painting internal to whatever effect they are doing. This then gets outputted as raster image streams from the MSG processor when the processing is finished.
Some Ip Ops might also be running vector paint processes internal to the overall effects they are generating. Because of that, we added support for Bezier paths being generated from ip op effects that do vector drawing internal to their effects (Path : Generate Path: from Ip Op menu command).
It turns out that the SVG file format is a much closer match to the features available in the vector painting api Studio Artist 4 uses (as opposed to EPS).
A huge weakness of EPS as a vector file format is that it does not really support partial transparency for overlapping objects. In essence, every overlapping vector region has to be split out into a separate region to try an pull it off. As opposed to just drawing your set of arbitrary vector regions that may overlap with some partial transparency.
Splitting out every overlapping chunk of vector region into a separate non-overlapping vector region quickly gets very complicated (prohibitively so) for anything that involves a lot of vector regions. And you have the problems associated with approximation of shapes and holes between adjacent ones i discussed above in the vectorizer section to worry about as well.
My guess as to why EPS has this major bummer of an issue with alpha support has to do with it's origins as a file format for sending visual information to a printer for printing. Including support for alpha blending to the format would have involved memory considerations in the postscript hardware implementation for the printer that would have been prohibitive in those old days when dinosaurs roamed the earth.
Adobe tried to add better alpha blending support in their pdf file format specification, but it seems very complex, and i don't think it has really been widely implemented.
SVG however, includes automatic support for partial alpha blending of arbitrary overlapping vector regions. So, it's a much better choice for outputting vector files from Studio Artist that will accurately re-create the vector drawing you see happening inside of Studio Artist.
Using eps will lead to solid vector shapes when you are using partial transparency settings for your painting. Fine if you are only painting in solid color regions at 100%, not so good it you have overlapping regions with partial transparency. SVG will accurately reproduce the partial transparency.
SVG also support nifty things like vector gradient effects. Things that Studio Artist also takes advantage of in it's vector drawing apis.
Which Vector File Format Should i Use?
So, why not dispense with eps and just use SVG for your Studio Artist vector file output? One reason is that the program you want to open the vector file inside of might not support it.
The classic example of this is using a vector file output from Studio Artist so that you can work with a low res canvas to quickly build up a vector effect, output it as a vector file, then re-render it as a raster image in something like photoshop at very high resolution for printing. Photoshop imports eps, but apparently not svg. But if you output from Studio Artist as eps, you loose all of your alpha blending, since the eps file format does not support it.
Most people who care about color matching or the finer points of matching color when printing images have custom calibration setups they have built up in Photoshop. So it really makes sense for them to print from there, and we encourage them to do so. Why should we re-invent the wheel for all of that stuff.
Now Illustrator opens svg vector files. So you could print form there.
However, we have found that it is quite easy to generate a svg vector file in Studio Artist that will crash Illustrator. You can do it with about 30 seconds of auto-painting in studio artist output as an svg vector file.
There is nothing wrong with these 'problem' svg files, they will open fine if you use Studio Artist to open them, or something else like Safari for example. There are just too many vectors in them for Illustrator to deal with.
If you think about it this kind of makes sense, programs like Illustrator were never really designed to work with extremely large numbers of vectors. The data structures they use to encode that information for editing and how much memory they take up probably make it prohibitive. And Studio Artist can generate extremely large numbers of vectors very quickly.
Interestingly, Studio Artist does a much better job of opening and rendering these hideously complex vector files than any of the other programs i have played around with that do also open them. Like we beat out Safari for example. And Safari has issues with svg gradient support, Studio Artist can handle it without a sweat.
So one thing we've been experimenting with is our own custom svg render engine. So you could for example output svg from Studio Artist, and then render it as a raster Tiff file at some really high resolution using our svg render engine, and then import that into Photoshop when you want to print it high res.
My version of Studio Artist for example, has an Import SVG to Canvas menu option that allows for arbitrary re-sizing of the imported svg file. So i've done experiments where i riff off a vector painting in a 1280x720 pixel canvas really quickly, then import it as a 15,000 x 8437 canvas. And that high res canvas looks great, crisp anti-aliased edges. So then i output that as a Tiff file for printing.
Why Generate a Vector File at All?
Why not just generate the super high res Tiff file directly in Studio Artist, and skip the vector file output part. You could of course do this, but you might run into memory limitations that currently exist with large canvas sizes and V4 Studio Artist, which is a 32 bit app, and can only work with a max of 4GB of virtual memory. But even ignoring that, it's often times way more efficient to work with a lower res canvas.
Speed is one reason. Things run way faster when working with a smaller canvas size. So you can riff off a painting into a lower res canvas very quickly. It's typically only when you get around to printing that painting that you care about it being really high res.
Another reason is that the vector results you get working with a lower res canvas might actually be what you are really looking for. Working with the vectorizer is a really good example of this. Using a super high res canvas size for your vectorizer workspace can lead to all kinds of extraneous artifacts in the generated vectors from smooth gradient sections of a source image being blown up to match your super high canvas size. While working with a much smaller canvas size might give you a much cleaner vector representation and the real result you are looking for.
So in cases like this, you are way better off working with the smaller canvas size, outputting the effect as a svg vector file, then rendering it to whatever large res raster image size you want for your final print.
In my mind, it's a way more efficient approach to working than starting with a 15,000 x 8437 pixel canvas and trying to generate a quick painting or vectorizer effect there. Maybe not for every situation, but certainly for ones where being spontaneous and working quickly are the goal.
As always, life is not so simple, problems with SVG
Now i started off this long exposition by asking for feedback about vector file formats that we should be supporting. And along the way, i made a pretty good case for why svg seems like a really good fit for Studio Artist vector effects. But of course, nothing in life is really simple once you dive into the gory details.
As it turns out, the svg file format has some interesting flaws that i don't think the people on the committees that designed it ever really thought through. Or maybe they did, but didn't care. I can't really speak for them.
Let's just say that there is a big difference between using a vector file format to store information that draws the linux penguin or a solid colored rainbow unicorn vs using it to store hideously complex artistic paintings that really push the envelope of what is possible using the format to create rich complex organic looking vector graphics. While svg performs admirably for storing that penguin or those unicorns, some of the cool stuff we added to v5 can bring svg to it's knees really quickly.
So the big question is, what do we do about this. Which gets back to my question about vector file formats. We could generate some bastard version of svg that we modify to make more efficient. Or we could look for some other 'official' standard that might work. Or we could roll our own. Just like we did for those bezier IFF chunks i mentioned earlier in this long winded discussion of the long convoluted history of Studio Artist vector support development.
I guess the other option is we could turn those bitching cool new vector features off, do you don't get into trouble when you try to save them out to a svg file. But that's not really the way things work here at Synthetik. So i'm not going to turn off the cool new features because the standard file formats we have access to are too ill-conceived to handle supporting them.
At this point many of you are probably thinking, 'the last thing the world needs is yet another vector graphics file format'. But then again, if we are getting into the business of also providing vector render options that allow rasterizing into arbitrary sized images from vector files, then maybe having our own vector file format for this does make a lot of sense. Especially if our vector file format provides a much more efficient way to manage the kind of vector complexity we are talking about providing with these new features.
I'm bringing all of this up to provide a windows into some issues we are currently wrestling with here at Synthetik. And a little peak about where things are headed in the near term future.
...
So as always, i welcome your thoughts on what vector file formats we should be supporting (or not).
Replies
The decisions we are making about how we are going to end up supporting vector file formats in V5 are in very active discussion here. This post tries to document the twisted history of vector painting in StudioArtist, it's humble and strange beginnings, and how it is really evolving into something very interesting, unique, and powerful as we move into the future. It also points out some of the limitations with existing vector file formats we are running into.
if you care about any of this, now is the time to make your thoughts known.
So i hope anyone interested will take the time to read through this long post, and offer their expert opinions to the questions it asks.
You may have concerns we aren't even considering in our thinking. We may have discovered things you haven't thought about or run into before.