Talk:Raster graphics

Comments

---

"A bitmap corresponds bit-for-bit with an image displayed on a screen, generally in the same format used for storage in the display's video memory, or maybe as a device-independent bitmap." Should the word "maybe" be used here? It doesn't sound right.

---

—Preceding unsigned comment added by The MP (talk • contribs) 00:56, 9 December 2008 (UTC)

Cant be rescaled without significant loss of quality? I dont really understand this. scaling DOWN loses NO quality if you ask me. scaling up, though it loses no absolute quality, it lowers the relative quality.

---

Scaling down clearly loses quality. What if I scale down to a single pixel? If by quality you mean information per pixel then you may be right, but that's not what most people mean. --drj

---

The terms "Vector" vs. "Raster" graphics originally derived from display technology. Vector dislays moved the CRT beam from point to point to draw straight line segments, whereas the CRT beam in a raster display scanned a fixed pattern like a TV. Displaying a circle on a raster display required scan-conversion (determining the points where the scan line intersected the circle), whereas displaying a circle on a vector display required vectorization (fitting many short vectors to approximate the circle). Scaling a vectorized circle meant scaling the vectors, which did not preserve the accuracy of the approximation. To maintain fidelity it was necessary to scale the circle geometrically and then re-vectorize. A circle can similarly be scaled geometrically and then re-scan-converted for a raster display. The approach is perhaps more accurately termed "geometric graphics".

---

That's true, and perhaps something of this origin of the terms should be included in that artice. But regardless of the origin of the terms, their most common present use is merely to distinguish "scanned" graphics from "object-based" graphics. This is even how the terms are used in modern graphics file format specs, and what they are likely to mean when encountered by our audience. I haven't seen an actual vector CRT since the old Atari coin-op video game "Tempest", but people do talk about things like PDF and SVG as "vector" graphics, and in that context, scalability (i.e., the fact that the image is defined in terms of an ideal that can be rendered to the limits of whatever device is available) is a primary feature (that's even what the "S" in SVG stands for). --LDC

---

Here's what the Microsoft Press Computer Dictionary (3rd ed. 1997) has to say...

vector graphics images generated from mathematical descriptions that determine the position, length, and direction in which lines are drawn. Objects are created as collections of lines rather than as patterns of individual dots or pixels.

object-oriented graphics computer graphics that are based on the use of graphics primitives, such as lines, curves, circles, and squares...

The IBM Dictionary of Computing (10th ed. 1994) has:

vector graphics - see coordinate graphics

coordinate graphics - Computer graphics in which display images are generated from display commands and coordinate data. Contrast with raster graphics. Synonymous with line graphics.

On the other hand, Robin Williams in Jargon: An Informal Dictionary of Computer Terms (1993) says:

The term vector graphics means exactly the same thing as object-oriented (or just object) graphics.

I suspect the confusion in terminology is due to people (perhaps unfamiliar with the word "vector") incorrectly using "vector graphics" as an antonym for "raster graphics".

---

If you think it's worthwhile to retain the older meaning of "vector" (perhaps to ease confusion with math articles about vectors), then perhaps we could have a "vector graphics" page with something like "The term vector graphics is commonly used today as a synonym for object graphics, though originally it referred to...", and the establish a Wikipedia style guideline to use "object graphics" exclusively. My hesitation to do this is that the misuse of the term really is well-entrenched, and it might be more confusing to use to "correct" term. --LDC

---

I definitely think the original meaning and context should be included, if only for historical reference. Whether we should attempt to discourage the use of the term in its new sense in favor of "object graphics", I don't know.

---

Is "raster graphics" the proper name for this page?

The expression "raster graphics" came into use many years ago (70's or earlier) to distinguish computer graphics algorithms appropriate for the "new" bitmap-based displays, from the older ones oriented twoards direct-drawing displays ("vector graphics"). Since "vector graphics" are dead, the name is no longer meaninful.

Also, the term "bitmap" was coined (in the early 80's) to refer specifically to *binary* images stored in memory. ("Advanced" workstations then had only 64K bytes of memory for everything!) Even today "bitmap" is used in non-graphics contexts to stand for "compact *boolean* array". When color raster graphics became popular some people may have continued using "bitmap" out of habit, but others used more appropriate names like "bytemap", "pixmap", "pelmap".

Nowadays "raster graphics" is supported by a "frame buffer" in the video card, rather than a "bitmap" in memory. If/when a programmer needs to describe the data structure used to represent a digital image in main memory, I think he would rather use "image object", "pixel array", "image in memory", etc. -- rather than "bitmap".

Finally, this page mixes the system programming concept of "bitmap" (a data structure in computer memory) with the signal processing concept of "digital image" (an abstract array of samples). Issues like resolution, scaling etc. belong to the latter, not the former.

So here is my proposal:

1. Create a new page for "digital image" [done!] and move to it those parts of the present "raster graphics" page that apply to digital images independently of memory layout.
2. Create a new page called "raster map" aka "pixel array" that describes the data structure in question (a packed 2D array of bits or small integers) and its main uses -- namely, storing a digital image in memory, and as a frame buffer. This page should include "bitmap"as a special case. (Or perhaps "bitmap" should have a separate page due to its use for non-image applications?)
3. Reduce the "raster graphics" page to a single paragraph, "A term coined in the 70's to distinguish computer graphics techniques bla bla...from "vector raphics" bla bla...
4. Create links between the "raster map" and "frame buffer" pages.

What do you think? --143.106.24.42 08:52, 4 Mar 2004 (UTC)Jorge Stolfi

• Vector graphics does not just refer to a type of display, but also to storing coordinates of vertices, etc. rather than pixel data, that is not dead. --Patrick 00:49, 5 Mar 2004 (UTC)

Ok, I should have said "vector graphics *displays* are dead".

Storing vertices etc. is certainly more alive than ever --- that is what goes into the typical graphics card, or what you put in a Postscript file; but I think that the proper name for that is (2D) *geometric modeling*.

That nomenclature would be consistent with common usage in 3D graphics: The representation of the scene with vertices, edges, faces etc. is called the *geometric model*. By rendering this model (at a chosen scale and resolution) one obtains produces a (raster) digital image, which goes to the display device.

Note that your 2D "vector graphics" similarly must be converted to a digital image before it can be displayed. That is the job of the graphics card, Postscript interpreter, etc. At that moment one must choose a rendering window and resolution (and lose information), just as in 3D graphics.

In other words, the concepts of "vector graphics" and "raster graphics" are no longer two mutually exclusive alternative ways of doing computer graphics, but rather two succesive *stages* of it. Thus those names (which embodied the either/or view) are no longer adequate.

Analog raster graphics

Should the article link to halftone printing as a halftone print is essentially composed of dots, an analog raster image. Scoo 09:43, 20 July 2006 (UTC)

The article is not too detailed....................... Thumbs down

Better explanation of value of raster graphics, contrasted with vector graphics

Note the following passage in the raster graphics article:

Raster graphics deal more practically than vector graphics with photographs and photo-realistic images . . . . [Italics added]

The article does not explain this greater practicality. Reading the voctor graphics article, one is impressed with the use of vector graphics in producing sharper images. So, one wonders why bother with raster graphics. Furthermore, one notices that Paint Shop Pro handles raster graphics, while Photoshop does not. What does Corel know that Adobe does not, or vice versa? Dogru144 16:27, 8 August 2007 (UTC)

Speaking of analog photos, which type of graphic editing (raster or vector) is better? Cheers, Dogru144 16:27, 8 August 2007 (UTC)

Mention of Some Formats?

It'd be great if mention or links could be made to some formats e.g. GIF, JPEG, & BMP.

Any others?

Regards

JohnI 22:54, 29 August 2007 (UTC)

Done. I just added visible links to two other pages that cover that. We definately don't want this article to turn into a looooong list of graphics file formats. --Kubanczyk 07:50, 19 September 2007 (UTC)

color/colour

I have reverted wholesale spelling changes on this article enough, so someone else feel free to do it instead. From now on I'm just going to keep it consistent one spelling or the other. VMS Mosaic 17:51, 19 September 2007 (UTC)

this is comfusing. —Preceding unsigned comment added by 72.94.124.105 (talk) 19:41, 3 November 2007 (UTC)

Merging “bitmap”?

Is there notable examples of raster graphics, which are not bitmap in the sense of that article? (Do not confuse it with binary image which is a separate article.) May be, so named analog raster graphics? But such unquantized things as analog video are not commonly referred as raster graphics, and may be noted as See also.

I propose to merge the article “bitmap” here, and move bitmap (disambiguation) to bitmap, see Talk:Bitmap#What concept is the article about?. Incnis Mrsi (talk) 12:50, 20 January 2009 (UTC)

I have to agree. Besides, they are in a sense one and the same. Adam Hillman (talk) 12:12, 5 March 2009 (UTC)

• Oppose – In general, I'm not in favor of merging a decent sourced article into a messed up unsourced article. If we're going to do a merge, I'd look for what in raster graphics can be sourced, and then decide whether it overlaps the content of bitmap enough to support a merge, and then decide which direction to go. At present, I'd say merge the meager content of raster graphics into bitmap, though they could also be kept distinct; their present contents do not actually overlap much. Dicklyon (talk) 18:18, 5 March 2009 (UTC)

• Oppose while a bitmap does fall under raster graphics so do more complex formats such as OpenRaster and PSD. I suggest we put a sub section in marked {{main | Bitmap}}, Bitmap is a descent sized and sourced somewhat article now and I believe it will be pushed into its own article in the future if merged anyhow. --Gnepets (talk) 01:41, 18 June 2009 (UTC)

Merge bitmap into here?

I have no dog in this fight, but I’m curious why JohnnyMrNinja merged the "Bitmap" article into here even though there seems to be more opposition than support for such a merger. [edit: in the previous section] –jacobolus (t) 10:14, 12 February 2011 (UTC)

I'd have participated in the "fight" myself, but I lost the keys to my time machine. The debate is about the article in June 2009, which was about both bitmap file formats in general (i.e. raster graphics) and the Bitmap file format. The latter was later split off into its own article, leaving the two pages completely redundant. Thanks for the vote of confidence. ▫ JohnnyMrNinja 10:29, 12 February 2011 (UTC)

Ah, fair point. I didn’t look as closely as I should have. Well, it should probably be put to another discussion then. I moved this to a new section. Does anyone have a high-level vision for how these pages should ideally be organized? Does a merger, now in 2011, seem like a good idea to people? –jacobolus (t) 11:50, 12 February 2011 (UTC)

I'm still going for yes on this one, the current version is a complete overlap. ▫ JohnnyMrNinja 06:52, 14 February 2011 (UTC)

Agreed! Should be one. -rjdthegreat — Preceding undated comment added 21:01, 23 June 2015 (UTC)

As I said before, "I'm not in favor of merging a decent sourced article into a messed up unsourced article." Merge the other direction, and lose the ugly smiley face if you want to improve matters. Dicklyon (talk) 16:06, 14 February 2011 (UTC)

Hmmm...

It would be easier for users to find the articles if they were merged, but I notice they both talk abount different things at some points. If the Raster Image article were to be cleaned up a bit, then merging could definitely be a possibility. talk 18:18, 25 October 2012 (UTC)

etymology

I doubt that the rastrum theory is correct. I would like to see a source for it. In Dutch, "rooster" means grid, and this word sounds similar to raster. http://en.wiktionary.org/wiki/rooster#Dutch

Xiutwel 13:52, 17 June 2011 (UTC) — Preceding unsigned comment added by 195.7.132.65 (talk)

Merge proposal

As the original creator of a small article on Raster data, I'm OK with merging it into this article, so long as readers are able to find a distinct discussion of the former (actually broader!) topic. — Preceding unsigned comment added by Ldecola (talk • contribs) 15:59, 9 April 2020 (UTC)

  Y Merger complete. Klbrain (talk) 20:36, 31 August 2020 (UTC)

Fairly edit rework of lead

I made a fairly heavy revision of lead this morning. As usual, my work is along the lines of a suggested treatment, I make my contribution and move along, taking no further possession of the end result. Revise or revert as you wish. But do note that I've substantially increased the subject matter coverage, and my revised lead certainly summarizes far better than the pre-existing material. — MaxEnt 18:30, 28 September 2020 (UTC)

We don't need no registration, we don't need no scan control

For the record, after contemplating my recent edit (previous comment), I strongly oppose the merge proposal from a decade ago.

This becomes a lot more obvious after I added the footnote to mechanical television at the bottom of the revised lead.

I was there in the late seventies/early eighties, and bitmapped graphics did not become a thing until around 1982, with the entry of the "affordable" Hercules Graphics Card in the IBM PC expansion market at USD $499 ($1350 inflation adjusted to 2020). Note that this was just the card, and did not include the monitor. Before that you only had the subsidized workstation crowd—aka the prima dona X-window hacker community at MIT—loudly demanding megapixel bit-mapped screens, and $250,000 futuristic concept cars at Xerox Parc (which I personally once got to fool around with for a solid hour). Then you had the Apple Lisa in 1982, another grotesquely overpriced concept car, before the "affordable" Macintosh from 1984 which brought bit-mapped graphics into the mainstream once and for all at a lush, monochromatic 72 dpi on white phosphor (not even having any other possible display mode).

Rasterization is any process which decomposed multidimensional objects into a series of parallel ribbons. If the object has an inherent visual nature, then it's almost surely two dimensional, and we lump this together as raster graphics.

In the electro-mechanical world that long predates the above (1920s for mechanical television) of central engineering concern is registration: decomposing the image with a known registration, and maintaining that registration within tight tolerances when putting the image back together again. What does not matter is whether the lines are drawn left to right or right to left, whether the continuous or discrete "pixels" have any particular local geometry (they can be dots, squares, blobs), and or sequence of iteration in which the ribbons are first acquired or later laid down (analog television has long been interlaced). Within each ribbon, you have a linear offset, x, and a function (determined by recorded data values) that maps 'x onto some form of intensity; this need not be a visual intensity as such, but might instead be an applied tip force.

We rasterize image data when building electromechanical systems for much the same reason that spoken language is highly serialized. You have one production element (the beam, or pen, or throat) to cover the desired output space of whatever conceptual dimension it might have. (Note that true visual sign languages are more concurrent that spoken language—both arms and the face annotate in parallel—but still highly serialized.)

x can be viewed as distance, but more often in equipment it is best viewed as time. CRT tubes ideally obtain a constant horizontal scan velocity across the projected surface (which has not always been a plane).

CRT displays would display with less flicker if the scan lines alternated direction (less time spent in horizontal retrace), but then you would have a severe registration problem between the two directions so this was never done. Eventually dot matrix printers would print bidirectionally to save time, I'm not sure how they finally solved the registration problem.

For similar reasons, the reproduction process is almost always highly regularized: constant scan velocity, constant ribbon thickness, and a highly regular scan line display order (if not perfect top to bottom).

Once memory becomes cheap enough (aka DRAM) everything rasterized is reinvented as bitmapped for the convenience of digital technology. The Macintosh's 512x342 monochrome bitmap required 22 KB of memory. The original edition had 128 KB in total (I believe the graphics used the same system bus and was allocated precisely every second clock cycle, but this is long ago). What really made this the beginning of bitmapped graphics in a real way was that the Mac provided an implementation of bit blit in ROM (as I recall, code from the ROM ran faster than code from RAM, but I forget the precise reason why). I recall that codifying bit blit in this was originally a Xerox Parc innovation, from whom Jobs borrowstole a great deal of his original IP.

Meanwhile, monochrome text adapters continued to exist for a long time. These are extremely rasterized, but with the rasterization performed by hardware in real time for every scan line generated (your character ROM chips work pretty darn hard). I would not call the character text array "bit mapped". (On IBM it was traditionally 25×80×2 with bits in the second byte used to control inverse video and blink and other hell spawn.) Nevertheless, text mode was indeed rasterized on display.

If a bitmap is used to represent a mechanically uniform grid, it rasterizes naturally for the needs of most available hardware. As Marc Andreessen once said, software eventually eats everything, to such a degree that some people suppose that raster graphics has now become a subset of bitmapped graphics. These people are prone to hum along to the following ditty:

 we don't need no registration
 we don't need no scan control

only they probably have their screen set up to display that in Helvetica, rather than monospace as God intended.

Bitmapped graphics are a technical implementation of raster graphics that took the world by storm in the early 1980s, and which immediately then developed a large, cite-worthy specialist literature. Guess which article has the better citation standard? (If only I could get my hands on more past editions of Linotype Weekly I might even stand a fighting chance in the citation wars.)

Quite clearly, bitmapped has its origins in raster graphics, but the vast majority of modern file formats derive far more directly from bitmapped graphics than from their raster heritage (although traditional conventions regarding raster bit layout yet remain).

Once we get to the era of the LCD display panel, the era of rasterization is largely ended.

If you disagree, take a quick browse through DisplayPort Technical Overview. Way beyond rasterization, the image is sliced and diced during compression with a Ginsu knife. (The name Ginsu was invented by Becher; Becher later translated the word as meaning "I never have to work again".)

A few final notes: dot matrix and inkjet printers perform simultaneous rasterization of many image rows; scanning electron microscopes rasterize (but not visually until false colored).

Maybe the solution is to create a page titled raster graphics electromechanical reproduction to cover decades worth of legacy peripheral devices where this was a mandatory interface, turn raster graphics itself into a largely historical treatment (at least as far back as mechanical television) and push everything else into bitmapped graphics (where I would further separate out bitmapped graphics file formats, lest these drown everything else).

Unfortunately, I'm not as blessed as the Ginsu guy, and I've already devoted far more time to this than intended so I must toss my message in a bottle into the vast talk-page ocean and then transubstantiate myself into the sunset. — MaxEnt 21:18, 28 September 2020 (UTC)

Revision

I did a fairly substantial revision of this page, trying to reorganize it into a more standard page layout. The intro had grown rather messy, so I moved a lot of it into more expansive sections below. It is not perfect, and could use more work, but I hope it is an improvement.

On the discussion above about bitmap vs. raster, yes there is a subtle distinction, and much of the discussion above should be in the page itself rather than here, but the fact is that they are commonly used interchangeably in most fields, and they belong on the same page. Bplewe (talk) 17:00, 24 October 2021 (UTC)