Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Vector Vengeance: British Claim They Can Kill the Pixel Within Five Years

Soulskill posted about a year and a half ago | from the now-you're-thinking-with-vectors dept.

Graphics 221

MrSeb writes "The humble pixel — the 2D picture element that has formed the foundation of just about every kind of digital media for the last 50 years — may soon meet its maker. Believe it or not, if a team of British are to be believed, the pixel, within five short years, will be replaced with vectors. If you know about computer graphics, or if you've ever edited or drawn an image on your computer, you know that there are two primary ways of storing image data: As a bitmap, or as vectors. A bitmap is quite simply a giant grid of pixels, with the arrangement and color of the pixels dictating what the image looks like. Vectors are an entirely different beast: In vector graphics, the image is described as a series of mathematical equations. To draw a bitmap shape you just color in a block of pixels; with vector graphics, you would describe the shape in terms of height, width, radius, and so on. At the moment, bitmaps are used almost exclusively in the realm of digital media — but that isn't to say they don't have their flaws. As display (and camera and cinema) resolution increases, so does the number of pixels. The obvious problem with this is that larger bitmaps are computationally more expensive to process, resulting in a slower (or more expensive) workflow. Pixel bitmaps don't scale very gracefully; reduction is okay, but enlargement is a no-no. There is always the issue of a master format, too: With pixel bitmaps, conversions from one format to another, or changing frame rates, is messy, lossy business. Which finally leads us back to the innovation at hand: Philip Willis and John Patterson of the University of Bath in England have devised a video codec that replaces pixel bitmaps with vectors (PDF)."

cancel ×

221 comments

Sorry! There are no comments related to the filter you selected.

Vectrex LIVES! (5, Interesting)

Anonymous Coward | about a year and a half ago | (#42264817)

The return of the glorious Vectrex!

Re:Vectrex LIVES! (1)

camperdave (969942) | about a year and a half ago | (#42265523)

Time to limber up my Asteroid reflexes.

But (4, Funny)

MyLongNickName (822545) | about a year and a half ago | (#42264819)

But, if there are no pixels, how will I detect photoshops? I've seen quite a few in my day...

Terrible summary (4, Informative)

MrEricSir (398214) | about a year and a half ago | (#42264837)

They're not "getting rid of pixels," since you'll still have pixels on your monitor and your graphics card will still buffer what it's drawing to the screen.

The paper sounds interesting enough, but the summary has essentially nothing to do with it.

Re:Terrible summary (5, Funny)

jeffmeden (135043) | about a year and a half ago | (#42264975)

They're not "getting rid of pixels," since you'll still have pixels on your monitor and your graphics card will still buffer what it's drawing to the screen.

The paper sounds interesting enough, but the summary has essentially nothing to do with it.

No no, they also specify a hardware appliance of several algorithmically aware lasers that will dance around in a box to the exact specification of the vector design, and it would generate a new frame as fast as the light could get from one end to the other. It was on page p[k_, n_] := ((k - 2) n (n + 1))/2 - (k - 3) n;

Re:Terrible summary (4, Interesting)

teg (97890) | about a year and a half ago | (#42265013)

They're not "getting rid of pixels," since you'll still have pixels on your monitor and your graphics card will still buffer what it's drawing to the screen.

The paper sounds interesting enough, but the summary has essentially nothing to do with it.

Vector monitors [wikipedia.org] to the rescue!

Re:Terrible summary (0)

Anonymous Coward | about a year and a half ago | (#42265221)

I get that old CRT's and such weren't as good as we'd like now, but in theory wouldn't this produce a much better picture, if the content it was displaying was all geometrically described? I mean, no pixel gap, no hackish aliasing, etc?

Re:Terrible summary (1)

devjoe (88696) | about a year and a half ago | (#42265317)

They're not "getting rid of pixels," since you'll still have pixels on your monitor and your graphics card will still buffer what it's drawing to the screen.

Vector monitors [wikipedia.org] to the rescue!

And since this is only for a video format, we'll also need to bring back Display Postscript [wikipedia.org] for our user interface elements!

Re:Terrible summary (1)

mrchaotica (681592) | about a year and a half ago | (#42265553)

What do you mean, "bring back?" OS X (and, I assume, IOS) still use Display Postscript!

(OK, so they actually use Display PDF, which is a subset, but still...)

Re:Terrible summary (1)

Hentes (2461350) | about a year and a half ago | (#42265759)

Theoretically, all CRTs can be used to display vector graphics.

Teribad summary (1)

TiggertheMad (556308) | about a year and a half ago | (#42265027)

The paper sounds interesting enough, but the summary has essentially nothing to do with it.

Agreed. The title is very misleading. Also, since this is just going to be generating vector gradients to interpolate fill values, wouldn't you essentially get the same effect by up-sampling a bitmap and as part of the scaling process, run some sort of algorithm to figure out color averages between the old pixels to create smooth blends in the new image? It seems like just another way to approach this problem.

Since all of our input hardware is still going to have to take in information samples in some sort of gird array, this isn't really going to radically change everything as much as they might hope.

Re:Teribad summary (2)

Yetihehe (971185) | about a year and a half ago | (#42265229)

The same could be said about mp3. Just like mp3 is compressing data in frequency domain instead of time domain, this codec changes pixel grid representation into vector representation.

Re:Teribad summary (3, Insightful)

cnettel (836611) | about a year and a half ago | (#42265303)

All current input hardware uses fairly rectangular input grids. However, this is often far from the truth. A digital camera contains pixels, but each pixel is covered by a color filter. In a JPEG from the camera, all pixels are represented (and compressed), but some information is already only a result of interpolation. This is one reason for why RAW is preferable, no lying about the information around. One could make hexagonal sensors or sensors with varying pixel density for a greater and more affordable field of view, or weird lens designs where the projection is not rectangular. If you have vector or mesh-free image data you have much greater freedom in designing both input and output methodology.

Re:Teribad summary (1)

X0563511 (793323) | about a year and a half ago | (#42265439)

If by input hardware you exclusively mean scanners and cameras.

What about content created directly?

Re:Terrible summary (5, Insightful)

Samantha Wright (1324923) | about a year and a half ago | (#42265287)

The fault lies with the university's PR department this time. It appears they took an off-handed comment about pixel-based codecs being completely surpassed in half a decade, and sound-bit it as "the pixel will be dead in five years." Extremetech didn't exactly help things along, either.

I'm somewhat confident that if someone had invented a continuous method of storing and displaying images, it would be picked up by somewhat more prominent sources.

Re:Terrible summary (1)

K. S. Kyosuke (729550) | about a year and a half ago | (#42265427)

Also, I believe that the STEPS project headed by Alan Kay also tries to replace the graphics part of current SW by something purely vectorish. In addition, I'm curious about the video codec claims they seem to make. Wavelet and especially fractal compression, I believe, is capable of image reconstruction at any resolution desired, and they already cover the let's-find-some-structures-and-describe-them-algorithmically part. It still won't be able to cheat on the information theory, so I'd be surprised if the compression results were somehow spectacularly better for their method.

Re:Terrible summary (1)

t4ng* (1092951) | about a year and a half ago | (#42265545)

I propose creating graphics with this system that consist entirely of an 2D grid of vectors where each vector has the same start and end point, along with an associated color and brightness.

Re:Terrible summary (1)

TeknoHog (164938) | about a year and a half ago | (#42265753)

I also got initially excited about vector displays... and frankly, I don't see anything special about video compression with vectors. Compression is already done by other mathematical descriptions, such as Fourier/cosine transforms. In fact, there are MP3 decoders that give "extra" precision on output, because the stored sinusoidal wave has no resolution limit, even if it came from low-res samples initially.

Re:Terrible summary (2)

Lord Lode (1290856) | about a year and a half ago | (#42265817)

But... but... but...

With a different title it wouldn't be as sensationalist! >:(

My monitor.. (0)

Anonymous Coward | about a year and a half ago | (#42264841)

My monitor has too many dead vectors :(

First thought: Bullshit (5, Insightful)

jandrese (485) | about a year and a half ago | (#42264849)

Second thought: The article is light on details and sensationally titled, so it goes in the bullshit bin.

Probably what happened is someone came up with a good raster->vector converter that does some cool things in their lab, and the technologically ignorant British tabloid journalist went to town on it.

Re:First thought: Bullshit (0)

Anonymous Coward | about a year and a half ago | (#42265009)

Having read the paper, I can confirm that this is exactly what has happened.

Re:First thought: Bullshit (0)

Anonymous Coward | about a year and a half ago | (#42265025)

The article is light on details and sensationally titled, so it goes in the bullshit bin.

Like everything else on /. So are you suggesting the entire site belongs in the bullshit bin?

Re:First thought: Bullshit (5, Informative)

phantomfive (622387) | about a year and a half ago | (#42265039)

Probably what happened is someone came up with a good raster->vector converter that does some cool things in their lab

Yeap, if you read the actual paper, that's exactly what happened. It's not obvious how it is particularly better than any other technique, either; the scaled images in the paper don't look much different than images scaled normally. Vector drawings give extra information on how to scale; information that you're not going to be able to derive from a photograph.

It isn't the British tabloid journalist who is to blame for the sensationalism, though, because when they asked the Professor who wrote the paper, this is what he said:

“This is a significant breakthrough which will revolutionise the way visual media is produced. To accelerate this project we’ll need companies from around the world to get involved...[and] increase the potential applications of this game-changing research.”

The press is following his lead.

Re:First thought: Bullshit (3, Insightful)

glwtta (532858) | about a year and a half ago | (#42265271)

That's exactly why it's the journalists fault - their job isn't to follow along with whatever self-promoting bullshit the person being interviewed is spewing.

Re:First thought: Bullshit (3, Insightful)

Dishevel (1105119) | about a year and a half ago | (#42265639)

You are thinking of what "The Press" used to mean.
Today they are partisan PR firms. Although they do well at demanding respect.
Not so well at earning any though.

Re:First thought: Bullshit (1)

eth1 (94901) | about a year and a half ago | (#42265789)

It isn't the British tabloid journalist who is to blame for the sensationalism, though, because when they asked the Professor who wrote the paper, this is what he said:

“This is a significant breakthrough which will revolutionise the way visual media is produced. To accelerate this project we’ll need companies from around the world to get involved...[and] increase the potential applications of this game-changing research.”

Rough translation: "I'm full of shit, but if you send cash, I promise to polish the turds."

Re:First thought: Bullshit (0)

Anonymous Coward | about a year and a half ago | (#42265669)

No way! I stopped reading to the first link ("will be replaced with vectors"). Then I imagined the rest: everything from realtime downscaler to 80's tech (UHF's Money for Nothing song) and realtime rendering of that newsreader to a mesh you could rotate and go under her shirt. Just WOW.

The hypothetical inventions are more real than the "dead pixel" which doesn't exist (expect on cheap TVs).

get ready for some Tempest 2017 (4, Funny)

Joe_Dragon (2206452) | about a year and a half ago | (#42264867)

get ready for some Tempest 2017

Just vapourware crap out of a crap University (-1)

Anonymous Coward | about a year and a half ago | (#42264869)

n/t

maybe I am missing something (2)

bloodhawk (813939) | about a year and a half ago | (#42264871)

excuse my ignorance if I am off base but Isn't a vector just a different way of targeting your pixels on the screen? isn't this just a different way of describing which pixels to activate? and if so how does this remove the need for pixels?

Re:maybe I am missing something (1)

pruss (246395) | about a year and a half ago | (#42264973)

Almost certainly you're right. But there did used to be vector monitors. It seems rather unlikely to me that we'd go back to them, but who knows?

Re:maybe I am missing something (2, Informative)

Anonymous Coward | about a year and a half ago | (#42264995)

excuse my ignorance if I am off base but Isn't a vector just a different way of targeting your pixels on the screen? isn't this just a different way of describing which pixels to activate? and if so how does this remove the need for pixels?

Assuming you're still using a raster display, yes. I mean, you can just fire up Inkscape or Illustrator and get a vector-based engine that renders to a raster display. Or just use KDE's Plasma widgets.

Now, if you're on a vector display, THAT'S a different story. Then you get actual lines and curves and such. Such things existed back in The Day(tm). The arcade game Asteroids, in fact, was meant to be played on a vector display. Lunar Lander, Battlezone, the original Atari Star Wars tie-in, all of those were vector display screens.

Of course, those displays had massive limitations, and that's why raster displays stomped all over them. One of which being a lack of solid colors using the technology of the time. Another being the fact that every game looked like a laser show (mostly because, in a way, that's effectively how it was displayed). And because of that, the increased cost of the display itself as you allowed more vectors on-screen at once, in addition to any added processor cost. They still have a very distinct, unique look to them, but ultimately, vector displays as general-purpose consumer monitors died horribly.

What it looks like these people are doing, however, is mapping movie data to vectors. Or something. I think it's still going to be output onto a raster display, but it'll scale better? I guess we really DO need to count the pores on the actors' faces...

Re:maybe I am missing something (1)

demonlapin (527802) | about a year and a half ago | (#42264997)

In practice, this will be running on raster-style screens, since almost everything is a flat screen these days, but at least in theory a vector CRT is driven very differently from a raster CRT.

Re:maybe I am missing something (1)

Anonymous Coward | about a year and a half ago | (#42265101)

you are exactly right and OP is a you-know-what.

somewhere some dickhead will point out massive amounts of compression in representing a rectangle as "four numbers" instead of an NxM grid. Then someone else will point that that's already what happens, just that the video hardware does the translation. Everyone should just punch themselves.

Re:maybe I am missing something (0)

Anonymous Coward | about a year and a half ago | (#42265477)

remeber this one?
http://en.wikipedia.org/wiki/Vectrex

Re:maybe I am missing something (0)

Anonymous Coward | about a year and a half ago | (#42265725)

You are missing the point. With the old tech you would have dead pixels. But when the vector crosses that pixel it will be called dead vector. This is how tech is progressing...

Wait for it... (0)

Anonymous Coward | about a year and a half ago | (#42264881)

Vector locked in...

So they want 2d accelerators? (0)

Anonymous Coward | about a year and a half ago | (#42264883)

Hey look, it's 1993 again.

The only thing i want to know (1)

marcello_dl (667940) | about a year and a half ago | (#42264885)

Will it be patent-walled?

Translating between cameras and displays (1)

A nonymous Coward (7548) | about a year and a half ago | (#42264889)

Is this going to make it harder to translate pictures from cameras to displays? I understand that displays will still have pixels, it's just the drawing that is different (AIUI). But cameras detect and report pixels, not vectors. Wouldn't it be better to translate those camera pixels directly to display pixels, instead of storing some information suitable forvector analysis?

I may be completely ignorant here, knowing just enough to be dangerous to my reputation :-)

Re:Translating between cameras and displays (1)

AlphaWolf_HK (692722) | about a year and a half ago | (#42265073)

Maybe they intend to be able to clean up each edition of the big book of British smiles much easier each time it is released.

Re:Translating between cameras and displays (0)

Anonymous Coward | about a year and a half ago | (#42265115)

well actually ... eyes are raster imagers, but natively convert that images to vectors. The bitrate on human eyes is pretty low, yet they're at the retina level. So, this is not implausible. However, yes, right now, (almost) all imagers and displays are raster based. However, most compression algorithms are some sort of DCT.

Re:Translating between cameras and displays (1)

camperdave (969942) | about a year and a half ago | (#42265701)

Eyes are massively parallel pixel array devices. Raster implies scanning: pixel by pixel to form a line, line by line to form an image.

Yeah, not real. (5, Insightful)

Anonymous Coward | about a year and a half ago | (#42264893)

Vectors are accurate as long as you've described the vector completely accurately.

If you're defining a curve, unless it's a simple geometric curve, you'll need to define the parameters of that curve and they just don't stop: they're fractal.

How big a set of parameters do you think it would take to define MERELY THE OUTLINE of a squirrel?

So you're just as limited by vectors as you are with bitmaps. You're going to have to approximate.

Re:Yeah, not real. (4, Interesting)

bluefoxlucid (723572) | about a year and a half ago | (#42265267)

How big a set of parameters do you think it would take to define MERELY THE OUTLINE of a squirrel?

All estimates of the length of any coastline are wrong. They vary widely depending on how many curves are taken into account. Without adequate smoothing, the length of the coast of Norway is infinite. With adequate smoothing, it's a few miles.

Not necessarily. (2, Informative)

Anonymous Coward | about a year and a half ago | (#42265723)

Infinitesimals added an infinite number of times add up to an undefined number. It may be infinite, it may be finite, but you can't say it is definitely one or the other unless you have already counted it up.

See Zeno's Paradox.
See also Atomic theory. At some level there is no more coastline, just a circle around an atom. Definitely smaller than norway's macro-scale accorded length of coastline.

Re:Yeah, not real. (1)

K. S. Kyosuke (729550) | about a year and a half ago | (#42265915)

How big a set of parameters do you think it would take to define MERELY THE OUTLINE of a squirrel?

That depends on how long the relevant parts of its DNA are. :D

Re:Yeah, not real. (1)

VortexCortex (1117377) | about a year and a half ago | (#42265921)

If you're defining a curve, unless it's a simple geometric curve, you'll need to define the parameters of that curve and they just don't stop: they're fractal.

Not only that but then you still have to selectively light up the display's RGB picture elements AKA pixels. So, no, we won't be rid of the "pixel" anytime soon, not even if the internal storage format is vectors. Even if the display used different layers of colored phosphors excited by multiple different beams striking from different angles to create the RGB (or whatever) color space, the convergences would still be pixelated due to the rasterized placement of the overlapping picture elements (pixels). Lastly, even if the screens were uniform and magically allowed multiple wavelengths of light to pass through the other layers, the beam itself would be controlled by a computer with finite precision calculations. The curves will become vectors, and the smallest resolution attainable on the display would be a single picture element (one PIXEL).

Quantum scale "Analog" displays you say? Oh what's a Quanta? A little packet of data, eh? A FUCKING PIXEL.

superresolution (0)

Anonymous Coward | about a year and a half ago | (#42264897)

Can anyone explain why this isn't just a bad (but perhaps faster) superresolution technique?

http://en.wikipedia.org/wiki/Superresolution

What's your vector, Victor? (2)

Lev13than (581686) | about a year and a half ago | (#42264901)

So they replaced pixels with a two-dimensional grid of sqare vectors that scale in width and height to grid width(or height) divided by the number of square vectors on the grid?

Actually just skimmed TFA and it looks like they have an interesting model - they separate the three channels and then fit vector "contours" around the different levels of brightness for each channel. The finer you need control, the more contours you add and the more explicitly you define the the polygons. Looks like a promising, workable solution.

Re:What's your vector, Victor? (0)

Anonymous Coward | about a year and a half ago | (#42265829)

Roger, Roger. I'm just going to get some Charlie, Charlie!

Re:What's your vector, Victor? (1)

MobyDisk (75490) | about a year and a half ago | (#42265913)

Using curve fitting like that is a common existing approach to scaling pixels. It can be done on a regular pixel image. It has nothing to do with vector storage like the article summary implies.

And cold fusion will be here in 6 years... (1)

Red Herring (47817) | about a year and a half ago | (#42264903)

..."At the moment there’s very little information about VSV"... ..."there should be working demonstrations of VSV within the next three to six months"... ..."Performance is awful"...

Yeah, this is DEFINATELY the kind of thing that will cause all current digital cameras and monitors to be obsolete within 5 years.

Or, it may get them an investment from some gullible investors that will then disappear into 'continued research due to unanticipated complications" for a few years, followed by "the pixel industry establishment is suppressing us!"

Why hate on pixels? (3, Funny)

jeffmeden (135043) | about a year and a half ago | (#42264931)

Just to spite them, i am going to republish their PDF using a 1024x14576 .bmp file.

Re:Why hate on pixels? (2)

Bigby (659157) | about a year and a half ago | (#42265417)

Then paste the BMP into a Word doc.

Re:Why hate on pixels? (1)

jeffmeden (135043) | about a year and a half ago | (#42265549)

Then paste the BMP into a Word doc.

I was thinking Excel, for the coup de grâce of technological misapplication. (i see this all the time, unfortunately)

It's just a compression technique (0)

Anonymous Coward | about a year and a half ago | (#42264945)

Cool and all, but highly oversold by the summary. They're not getting rid of pixels (whatever that might mean) but simply describing compression that uses vectorization as its primary mechanism.

No it's not a compression technique... yet (2)

slew (2918) | about a year and a half ago | (#42265055)

On the other hand the fixed contour level setting strategy resulted in file sizes 10x larger than their pixel equivalents which we did not attempt to address in the work being reported here....

We have also (knowingly) been far too conservative in the numbers of contours we find, possibly by as much as a factor of 20, but it will take a (much more complex) adaptive encoder to find the local optima. Compression is an obvious focus for future work.

Our original concern was to be able to reproduce photographic images from contour form so that they looked visually indistinguishable from the original. In this we were generally successful.

There is a reflection on that hubcap... (5, Funny)

ittybad (896498) | about a year and a half ago | (#42264947)

Enhance.

vectors still have scaling issues (1)

darue (2699381) | about a year and a half ago | (#42265059)

due to the use of cross-hatching type paterns, and issues around line-thickness

"... a series of mathematical equations" (0)

Anonymous Coward | about a year and a half ago | (#42265085)

A brilliant description of vector graphics, /.: "Entirely different beast [...] a series of mathematical equations."

In Soviet Russia, this is nerds for news.

Are they going to invent vector based FPAs too? (1)

imkonen (580619) | about a year and a half ago | (#42265091)

Because if not, they left out how they know what the underlying vector shapes are in the original image / video frame. Are those four pixels at the spatial sampling limit from what was originally a diamond, a circle, a letter o, a smiley face emoticon? I can only scale up if I already know that!

I can believe there is some interesting work being done in the algorithms that guess these things, and leveraging work done in the fields of machine vision and astronomy may translate to a video compression algorithm that is more efficient because of the inherently ordered nature of the universe (doesn't really matter if it guessed wrong if on random sample of images of real objects it stores the information more efficiently), but it's hardly novel to realize vector graphics work better if I'm making an illustration and I know what object I want it to represent rather than taking a picture (like the soda bottle with the small label on it).

"Britons" (0)

Anonymous Coward | about a year and a half ago | (#42265111)

A "team of Britons" or "a team of British devs", not a "team of British."

Or a "team of Brits." That's entirely fine for a casual and friendly tone. Cromulent even.

Re:"Britons" (1)

MysteriousPreacher (702266) | about a year and a half ago | (#42265319)

In fairness, the editors are probably a team of American. Only reason to think of anything Britishes is when there's a tasty morsel in need of a good hard extradition.

2D pixels? (0)

BetterSense (1398915) | about a year and a half ago | (#42265113)

TFS says pixels are '2D picture elements'. In what way are pixels 2-dimensional?

If anything I would say that monochrome pixels are 1-dimensional and 3-color pixels are 3-dimensional.

Re:2D pixels? (1)

Anonymous Coward | about a year and a half ago | (#42265153)

Oh, why, did you pick the only point the "summary" was right about?

Re:2D pixels? (1)

wonkey_monkey (2592601) | about a year and a half ago | (#42265385)

2D picture elements

[2D picture] elements, not 2D [picture elements]

Re:2D pixels? (1)

Bigby (659157) | about a year and a half ago | (#42265485)

A pixel has a height and width. If you consider color a dimension (as opposed to a property), then that would be a 3rd dimension. If the color is RGB, that is 5 dimensions. If it is CMYK, then that is 6 dimensions. Add in string theory and you get 17 dimensions.

UIs (1)

MrLint (519792) | about a year and a half ago | (#42265117)

I have been wondering for several years about why we dont have vector based UIs. The 2d accelerators should be good enough to draw vector window objects and such... Why has this languished?

Re:UIs (1)

Zimluura (2543412) | about a year and a half ago | (#42265283)

vector window objects have been around for a really long time. x even does allot of that stuff. i think e17 uses them allot.

only ever tried a little 2d opengl programming, but the 3d cards i used then (before programmable pipeline) had no hardware support for 2d ogl functions. that being said if you used the 3d functions to draw 2d elements (and leave all your z values 0) it was really really fast.

but i think it's all been static because display resolutions were static for so long.

resolutions basically went up slowly, then hdtv hit the mainstream with "1080p" actually lowering the bar, and only now that apple has pushed the buzzword "retina_display" are the mainstream consumers wanting more than "1080p". not an apple fan by any means, but i'm glad someone has been pushing a little bit for dpi.

The point about display sizes is accurate (1)

Omnifarious (11933) | about a year and a half ago | (#42265133)

I bought myself a nice retina mac recently. Likely the last mac I'll ever buy unfortunately. Apple is becoming too despotic for me to support even if their laptops are still open enough for me to consider using.

But that aside, I'm very disappointed to learn that Apple has to play a number of tricks to deal with applications that are written to do things in pixel units. I found this to be something of a surprise. I thought developers were better than that nowadays.

I've not done much application development, but when I have I always try to be careful to specify the application's layout in some device-independent way. It's really disappointing that so many applications (web pages most emphatically included in this list) decide that things should be sized in terms of pixels. That's a unit that really makes no sense at all to use unless you're specifying a line-width in terms of it (I want he smallest line width that I can draw and have it show up).

Unfortunately, even if app developers wrote their applications properly, there's still the problem of icons and pictures. Those are almost always bitmaps. And that's really not the right format for them, especially not for icons. IMHO, if you MUST use a bitmap for something, use one that's way obnoxiously large for any display you might anticipate using, then scale it to the right device-independent size in device dependent coordinates using a high-quality scaling algorithm before you display it.

Or better yet, use a vector drawing for your icon.

I've seen a lot of people clamoring for extremely high resolution displays. I'm among them. But with application developers developing things like they do, I can see why it hasn't happened. It would be a total mess.

Re:The point about display sizes is accurate (1)

vux984 (928602) | about a year and a half ago | (#42265501)

It's really disappointing that so many applications (web pages most emphatically included in this list) decide that things should be sized in terms of pixels.

Anything using images as a major component of a web design pretty much needs pixel dimensions for things to line up properly and/or to avoid ugly scaling issues.

There is no elegant way around it.

IMHO, if you MUST use a bitmap for something, use one that's way obnoxiously large for any display you might anticipate using, then scale it to the right device-independent size in device dependent coordinates using a high-quality scaling algorithm before you display it.

Firstly scaling things that are "icon" sized doesn't work. Algorithms can't do it well. Try it, take a few obnoxiously high resolution logos and scale it to the size needed for your browser address bar "favicon". (16x16 and 32x32) and odds are it looks like a mess.

Usually they need to be hand-edited at the pixel level for each targeted resolution. Icon files actually hold multiple versions of the icon at different resolutions. (Although frequently developers omit many of the resolutions.)

Secondly, the idea of all the images being "obnoxiously large" and then scaled might be ok for a locally installed program, but its completely unacceptable on the web to download megabytes of images to scale down to icon sized button even if it would work.

Or better yet, use a vector drawing for your icon.

These don't usually scale down to 16x16 or 32x32 pixels any better. They scale up better (smoother), though, which is a start, although its still better to just use a higher resolution more detailed version for the higher resolutions.

The reason why there are ugly results (1)

Anonymous Coward | about a year and a half ago | (#42265893)

The reason why there are no elegant ways around it is that you're being an arsehole: IT IS A WEB PAGE NOT A FRIGGING POSTER.

Jesus frigging Christ.

Web design is not the same as designing a poster. But it is done by the same set of asshat clowns who, having come from a "design background" that is still wedded to the idea that the "artist" paints the forms and the "plebian" goes gooey over it.

STOP FUCKING ABOUT!

The web page is being displayed on a device that you do not control and do not have the capacity to predetermine the look by people with differing visual needs.

If you were desinging a poster or book for a page 4.3" diagonally across, you'd use one form. A poster for a page 21" across and a different aspect ratio, you would use a different one.

THAT is why you do not get to demand "pixel perfect positioning". Because you're giving out information in one form for all these varying needs.

Not only that, the text may have to be larger for the hard-of-seeing (large print books). When you do a large print book you use a different typesetter. The words will NOT appear precisely where you wanted and the images will NOT appear right where you think the will and the text reflow will NOT be the same.

But because you are writing one web page for all these things, you, you little fuckwits, are TOO FUCKING LAZY to write a specific page for each possible device (with colour changes for the colour blind and braille versions for the blind, etc) and instead of actually USING THE RIGHT TOOL FOR THE JOB, insist on sucky bollocks that you then whine about being "really hard".

What's really hard is that you're thick as pigshit on this: you're using print memes on a non-print medium where you have NO CONTROL over how it is presented eventually.

So drop this crap about wanting a "web experience" as YOU want to define it (unless it's for specific device parameters, in which case, say so) and start defining the CONTENT as you want to present and as many hints about the best method for displaying that over which the end device can completely ignore you and do what the hell it wants, but STILL gets the CONTENT delivered effectively.

STOP fucking playing artist because it makes you feel creative.

ESPECIALLY if you're going to whine about how hard it is making things "pixel perfect" on a bloody WEB PAGE.

Kill Pixels in Five Years? Yeah Right! (2)

na1led (1030470) | about a year and a half ago | (#42265139)

I'm no expert in this subject, but don't most digital cameras capture using pixels? How the hell are they going to make a camera that renders vector image captures on the fly? You're camera would need a Geforce GTX 670 GPU.

Re:Kill Pixels in Five Years? Yeah Right! (1)

GoodNewsJimDotCom (2244874) | about a year and a half ago | (#42265637)

I had a laptop in the 90s that liked to kill pixels all the time.

zomg (0)

Anonymous Coward | about a year and a half ago | (#42265143)

They are going to change PIxel(R,G,B) to Vector(X,Y,Z). No one ever thought of using a tuple as a tuple! This could literally change everything.

Still need to take pixels into account (1)

FunkyELF (609131) | about a year and a half ago | (#42265145)

There is something to be said about lines being drawn with 1 pixel height or width even if they are vector graphics.
Makes things look nice and crisp.

== edit ==
just realized this was about video codecs

correct me if i'm wrong but... (1)

etash (1907284) | about a year and a half ago | (#42265149)

..your highest vector-resolution is still the highest vector resolution of your vector-saving camera. for example if your camera which saves to a vector format, doesn't have a high resolution, it will produce a crude vector file, which will only look good for equally small screen resolutions.

Dumb question... (0)

Anonymous Coward | about a year and a half ago | (#42265161)

Are JPEG images necessarly tied to pixels? If they store images as just a bunch of cosine waves added together, can't they in theory be resolution independent?

Re:Dumb question... (1)

gagol (583737) | about a year and a half ago | (#42265719)

yes, jpeg stores pixels only. For vector storage you need svg, ps, eps, etc.

Scaleable vector fonts, anyone, sheesh. (0)

Anonymous Coward | about a year and a half ago | (#42265183)

The premise of this article seems to be that all of us morons out here use flat bitmaps for every aspect of graphics and image manipulation.

Most likely (1)

TheSkepticalOptimist (898384) | about a year and a half ago | (#42265209)

The BBC will report that the reason behind global warming stems from the use of pixels instead of vectors because of the added energy overhead of processing millions of pixels instead of only thousands of endpoints.

Five years ago (1)

hobarrera (2008506) | about a year and a half ago | (#42265263)

We had the tecnology to easily do this over five years ago. How is this news? Until developers stop using bitmaps instead of vectorized graphics and relative units, this won't change either.

The English finally done it! (0)

Anonymous Coward | about a year and a half ago | (#42265293)

If they are getting into the monitor game, that means they finally figured out how to make it leak oil.

There's no beating English ingenuity!

What is this shit? (1)

glwtta (532858) | about a year and a half ago | (#42265305)

Maybe I could follow along if you added a couple more paragraphs about what pixels are.

Gosh, I hope the next monitor I buy will have enough vectors to support this futuristic technology. I probably need to hurry, do you think pixels will be dead before the end of the year?

Oh please. (1)

0m3gaMan (745008) | about a year and a half ago | (#42265325)

Vector graphics? Oh yeah that'll work.

frame rates? (1)

X0563511 (793323) | about a year and a half ago | (#42265365)

WTF do frame rates have to do with raster vs vector?

FAiLZORS (-1)

Anonymous Coward | about a year and a half ago | (#42265373)

God, 7et's fucking 4eople already; I'm head spinning area. It is the

It is slightly beyond my imagination (1)

erroneus (253617) | about a year and a half ago | (#42265393)

I get the idea in principle but I disagree with it in practice. The main reason why is the source.

Current digital and even analog video recording techniques capture frames in a two-dimensional format. Vector graphics while superior for many things, is not the one-size-fits-all format that many fans want to think it is. In the case of film, images are captured as an analog recording onto photosensitive film. Image density and quality varies on the quality of the material capturing the image. In the case of digital, the limitations are similar though captures are made by cells arranged in a geometric pattern on a plane. (Some are rectangular arranged arrays and others are hexagonal arrays and there may be other arrangements I don't know about.)

A means for capturing images as a native vector formatted data stream escapes my imagination. In my mind, it relies on a conversion process for each frame which is imaginable, however, it seems ... what's the word... over-burdensome for cameras and video cameras to be responsible for this task. And to do this within 5 years? I'm sorry, but everyone from the home user to the most sophisticated professional will not be willing to replace all of their gear so quickly and easily. I suppose I can see Hollywood being the early adopter of such equipment as their budgets for a single film might pay for the new equipment from the beginning. But for that to find its way for home use would most definitely take longer than 5 years... and probably longer while the various industries interested would want to find ways to DRM the new standard until it is useless.

Consider how much easier it would be to "shop" both images and video to add or remove elements seamlessly. "Watermarks" would be extremely trivial to remove from a vector graphics file. (Especially true of SVG format and I can't help but assume they mean to use a similar format.)

So the source would be the biggest stumbling block as to require everything be processed after acquisition does not do enough to make vector "replace" bitmaps... ever. And another stumbling block, of course, would be those with interests in copyright protection.

Re:It is slightly beyond my imagination (1)

viperidaenz (2515578) | about a year and a half ago | (#42265505)

A means for capturing images as a native vector formatted data stream escapes my imagination.

I'm thinking some kind of sci-fi laser scanner. But the direct output of that is more like a 3D bitmap, not a bunch of vectors...

Tek 4010, what was old is new (0)

Anonymous Coward | about a year and a half ago | (#42265463)

So time to get the Tek 4010 out of storage?

It'll never work (2)

viperidaenz (2515578) | about a year and a half ago | (#42265473)

Without pixels, you only have vector graphics. Unless the world is willing to all convert to anime porn, raster images will always be around.

The scaling they show looks worse than bilinear (1)

zeidrich (2793777) | about a year and a half ago | (#42265509)

The prime benefit of using vector graphics as opposed to raster graphics is that you can scale them better.

When you vectorize pixel graphics (see the link at the bottom of the article, it's a great paper) the vectorizer has a lot of heuristics to determine what constitutes a contiguous region. This is generally because of the smaller palette that's being targeted, and the stylized forms that the artists used to deal with a lot of information in a small (maybe 32x32 pixel) package. You can make a lot more safe assumptions when you are converting pixel art to vectors.

When you vectorize a rasterized photo you don't have the same leeway. You can see this in the reference image, the iris of the eye looks flat and angular, the brim of the hat looks like a string of beads. This is because the heuristics that it uses have to be quite conservative about how they interpret regions, what might look, based on color analysis, like a contiguous region, might to a human eye be identified as two distinct region based on overall shading queues. As a human looking at the picture, we know the brim of the hat is a contiguous region, but the algorithm isn't able to infer that, and still display it in a way that makes it true to the original source image at the unscaled resolution.

The bilinear filtering that's done on the raster image, however, just makes the shot fuzzier. However, that fuzziness works in the viewers favor, because the eye still looks quite round, and the brim still looks quite straight and contiguous. The fuzziness means there's an impression that there's a full set of eyelashes, while with the vectorized image, it looks like there is a single solid clump of lashes. There's still an amount of aliasing that belies the raster image's original resolution, however that aliasing is very regular and easy to process. The vector image looks very well defined in some places where it's a lie (for example, the iris looks well defined, but it's well defined as an angular shape) while on the other hand it looks aliased where even the raster image scaled bilinearly looks better defined (such as the brim of the hat)

Could patents be somehow involved? (0)

Anonymous Coward | about a year and a half ago | (#42265521)

with so many codecs in the world, this is yet another one that probably is not yet patented.

its about speed (0)

Anonymous Coward | about a year and a half ago | (#42265589)

Vector representations are all about speed. faster transmission, faster re-sizing, and it should make categorization, recognition, and editing easier. everything is faster and new things are possible.

vector monitors! (0)

Anonymous Coward | about a year and a half ago | (#42265815)

This is stupid. Bottom line is that the source is still pixel based on a camera. If you convert to vectors just to convert back to pixels for display, how is that better? Wouldn't the best be storing at resolution AxB and always playing back at AxB or (nA)x(nB)?

The real solution is to invesnt a sensor that can take raw vector data in. God knows how that would work. And then have a true vector display.

Cool solutions if they ever occur but pointless. Pointless because the eye only has so much resolution. Theretically infinite resolution is not going to look better than a 10,000,000x,10,000,000 bitmap.

polygons, not sprites (1)

Khashishi (775369) | about a year and a half ago | (#42265835)

To a large degree, we are already there. 3D graphics processing is done in vector and matrix representations. Sprites are dead. It's all about polygons. Eventually, it does need to be rasterized to a pixel based monitor, but 3D geometry is all vector based. Unless you are using some weird voxel engine.

What I want to know... (1)

es330td (964170) | about a year and a half ago | (#42265867)

Does this mean the end of pixelation?

Airplane (0)

Anonymous Coward | about a year and a half ago | (#42265873)

Whats our Vector, Victor?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>