We are still talking about slices. But I just couldn’t resist making another Adobe Flash rant. Slicing images was a setback to web graphics when the focus should have been getting more people to use vector graphics. Web graphics are still in the stone ages IMO.
And PostScript was great for print, but inferior to SmartSketch for electronic display. I’ve met the people who’ve developed it. Sometimes the newer technology is better, but loses a format war to whatever is first to market. The same thing happened with VCRs in the format war of VHS vs Betamax.
I wouldn’t disagree with you there, and although I never really took to Flash in practice, I do remember being quite intrigued by it as a vector editing platform. It employed some constructs and conventions that really should have been adopted by Adobe and installed in Illustrator, IMO.
I worked at a company that did both Flash and Director. They wanted me to compete with the Director team because vector animations were showing to be more advantageous for where the company was headed. Instead I opted to have the Director coders use my Flash Animations in their Director files. That was a career mistake. Director was already dying while Flash was growing.
And then there was Authorware which I could never understand. Flash was almost rescued with FLEX, but I couldn’t understand that either.
A while back, I splashed around enough to complete a project in Hippo Animator, which was Director-like in some ways (and more cryptic than Flash in others). It’s HTML5 output worked well on every tested platform, and it’s stupid-cheap, even if all you want is a platform for hobbyist-level work.
The problem with vector graphics on the web is that they’re typically larger in terms of bytes than their raster equivalents.
This can run contrary to common sense for those coming from a print background. Raster files need to be large and high resolution in the print world, but the same images can be compressed dozens of times smaller for use on the web.
Unlike raster images, vector files can’t be compressed with lossy compression algorithms. I use scaled vector graphics (SVG) for websites quite often. For that matter, I prefer them for a number of reasons, but honestly, they soak up bandwidth and are often far more inefficient than a .png or .jpg that’s been optimized for web use.
With relatively slow mobile connections accounting for over half web-related traffic, keeping byte sizes down is probably just as important now as it was back in the '90s.
Sorry Just-B … been a really frustrating day trying to make FF as happy as Chrome with seemingly most simple of code. Add to that an annoying (but wealthy) prima donna client and her stupid mobile device.
Here’s an old Adobe link which I hope helps all in much ‘safer’ words than I can muster at the moment…
Vector files don’t need to be compressed because they don’t consist of pixels. To compress a vector file would mean reducing nodes, kind of like the simplify feature in Adobe Illustrator. This works if there is too many redundant and stray points in the file. But there are other limitations slowing vector down that most people don’t know about.
IMO, the main reason vector is not used is because most people, especially noobs don’t know enough about how to develop vector graphics. It’s not as intuitive as pixels. As long as kids are taught to use crayons and pencils in preschool, they will gravitate towards raster. You’d have to teach them to draw using string and thumbtacks to get them comfortable with vector at an early age. The best applications combine vector and raster in 1 format, like SmartSketch did.
As for the web, I noticed that raster graphics were better if there were lots of complex lines in the graphics. But most graphics aren’t that complex. Vector graphics are faster to load, but slower to render if they are too complex. The difference is in processing power. Nobody complained about 3D graphic rendering when they wanted it bad enough. Developers just push for faster processors and for everyone to throw out their slower devices every year. Consumerism is great for the economy.
Now as we are coming to the end of the Moore’s law period, we are recognizing the necessity of vector. We know that even if bandwidth increases, traffic will increase keeping delivery speed at almost a constant. With Net Neutrality ending, bandwidth will be at a premium again. Faster processing will be in demand again for real-time rendering of vector graphics. Ultimately, a format (like SmartSketch and Flash) that combines vector with raster will make the most sense. But even within that format, vector will be utilized more than raster.
They can, of course, be compressed in a lossless way.
Just to demonstrate the file size problems with .svg, the following illustration is fairly typical. It has some complexity, but isn’t unusual. As a .png, it weighs in at 32KB at 685X441 pixels. The equivalent .svg is over ten times weightier at 356KB.
The sample headline, bottom, on the other hand is almost exactly the same size in .png or .svg, at 8KB.
Text isn’t the best example because the fonts could be installed on the device.
The problem isn’t really with SVG format as much as it’s with the number of points in the object. The first image would have way too many points as a vector graphic of any format. But if you compare the size of the second image as both a raster and a vector, it might be more revealing. The real test is comparing the size of the same image as both a vector and a raster format, at varying dimensions, and at varying animation speeds.
If there is a problem with SVG, it’s probably code bloat from the PostScript format or extra code for printing. But again, when it comes to web and other electronic display, the ideal format would be a combination of vector and raster. It only need be raster when rendering vector gets too complicated mathematically. Further into the future it will be easier to get faster rendering than it will be to get more bandwidth.
I used it only to demonstrate that even a very basic vector file is no smaller than a typical .png. I could have drawn a group of rectangles and ovals to demonstrate the same thing.
The more complicated vector images become, the weightier they become in relationship to an equivalent .png or .jpg when used at typical website dimensions
The main advantages to vector formats on the web are scalability and usefulness in animations. There are places for both vector and raster online, but I think lots of people have assumed vector is the up-and-coming replacement for web graphics without realizing that the benefits aren’t as significant or widespread as they assume.
I think we are in agreement here. Vector will never completely replace raster, just as electronic display will never completely replace print.
Eventually vector will become more dominant. When that happens, I can’t imagine a scenario where it will lose that dominance other than the complete obsolescence of display technology, exclusive brain-to-brain communication.
Just out of curiosity, I put it to the test. (I know, too much time on my hands.)
At the default full color, the png size was over twice the size of the SVG and almost 3x the size of the svgz. Even with a designated color pallet, the png was slightly larger than the SVG. The best I could do with the png was to reduce the quality of it to get it smaller than the svg. With fuzzy edges, the png size was 66% of the svg and 90% of the svgz. However, I’m not sure if svgz is used anywhere.
Full Color PNG 1245 bytes
Indexed Color PNG 613 bytes
SVG 606 bytes
SVGZ 438 bytes
Reduced quality PNG 398 bytes
I didn’t post the svgs because the forum software converts them to png automatically.
Yes, but you created three of the most easily defined vector objects imaginable — an RGB-colored shape defined by an edge that is always the sum of the distance between two other points. A circle would be even simpler to define since it only has one foci instead of two, but that’s about it.
So yes, these kinds of geometric primitives can be spelled out in a vector language like Postscript more efficiently than a pixel-by-pixel rendition, but it’s sort of pointless since the PNG equivalent is an inconsequential handful of bytes anyway.
A rectangle is (or should be) the simplest fillable shape. It requires the least amount of math. I tested a rectangle just out of curiosity. The SVG size didn’t change much, which maybe an SVG format specific problem. The png files got way smaller, but that’s because a rectangle is a giant pixel in effect. I chose an oval not because of it’s simplicity, but because of it’s varying of angles to demonstrate the anti-aliasing problem you get when you shrink a raster graphic too much. A vector graphic doesn’t have that issue, but the rendering engine may still do a lousy job of rendering vector graphics. It’s not as easy to tell with straight lines like you see in rectangles.
Not to go round and round here, but I think we are mostly in agreement. There was another thread about compression where you gave advice about knowing the type of image that you are dealing with. That’s pretty much the same lesson here to. If someone knows what type of graphic they are dealing with and also knows how that graphic can be optimally processed on a computer of any kind, they will know whether or not to use vector, raster, or a combination of both. They will no how to save the file in the optimal file format also. There is no one-size-fits-all solution for optimal graphic delivery.
On the subject of image slicing, it will never be completely dead, but will decline in use as vector graphics get more dominant. There will probably be periods where raster makes small comebacks when processing power is not as accessible or rendering algorithms aren’t feasible to install. In those cases, software that does slicing will still be useful, but fewer people will know how to do it, just like any other specialty or dying art.
Obviously I don’t do web much, but in print we have the concept of Optimization.
For instance you can send me a file at 1gig in weight and 600ppi at output size.
However, on the hardware I have that spews ink, anything over 150ppi at output size is wasted time because the return you get on higher image resolutions just isn’t translated into visual resolution on the machine out put. While the machine may be spewing 1200DPI, the addition of more pixels in the PPI of the image doesn’t present a noticeable difference in the machine output to warrant the extra rip time.
I imagine the same is true of monitors, whether desktop or handheld. There is an optimization level for web graphics over which the file is overkill. Whether something is best represented in vector or raster, doesn’t that depend on the end user intent and the program used is decided as one would select a proper wrench?
You guys can tell me to go back to my inks.
I was just curious as I read through this.
Just my two cents about Flash… it was taken off the market because it was a major security threat that left open holes for computers to get infected by viruses.
