Sign inRegisterCheck connection

Cumulus Weather Avatars: Information Density at 80×80

An 80×80 Cumulus weather avatar can carry one labeled scalar, not a banner. What must be dropped for forum signatures, and why density is a scientific limit.

Back to Cumulus weather software guides

An 80×80 weather avatar is a forum-signature object: a square PNG meant to sit next to a name in a thread, not a station home page. PHP GD can paint Cumulus web tags or realtime fields onto that square as easily as onto a 468×60 banner. The physics of the canvas is different. At 80 pixels on a side you do not have a status strip. You have room for one primary scalar, a unit, and maybe a one-letter qualifier. Everything else has to be dropped on purpose.

The historical TNET URL /projects/phpgdavatar was that tiny renderer for Cumulus stations. This article is about the density limit: what an avatar can honestly carry, what it must omit relative to a banner, and why shrinking a 468×60 strip into a square is not a design.

This page is not the banner generator, not the banner gallery, and not the analog thermometer. Those three products spend pixels in incompatible ways.

Historical context

Forum software of the period capped signature images. Eighty pixels square, sometimes 100×100, was a common ceiling. Station operators wanted the current temperature—or a wind glyph—to follow their posts. Cumulus already emitted tags and, optionally, realtime.txt. A small PHP script on the web host read one or two fields and drew a square.

The scientific mistake was treating the avatar as a scaled banner. A banner has a long axis for three labeled numbers. A square has no long axis. If you photograph a banner and crop it to 80×80, you get a fragment of a number, not a station. The avatar project existed because the fragment was not good enough.

TNET does not rehost the historical generator, the sample faces, or a ZIP of signature packs. The constraint remains: information capacity of a tiny raster fed by a Cumulus packet.

The pixel budget is a measurement budget

At 80×80, with a 4 px margin so type does not clip at the anti-alias, you have about 72×72 of usable field. A digit that remains readable after forum downscaling wants 20–28 px of cap height. That is enough for three characters of temperature (−4, 21, 104) plus a compact unit (C, F)—or enough for a two-digit wind and a unit, not both families at banner type sizes.

You can cheat by using 8 px type and stacking five lines. The cheat fails in the actual use case: signatures are displayed small, often next to other signatures, often after the forum has transcoded PNG to JPEG or WebP. Dense type becomes texture. Texture is not an observation.

So the avatar has to choose a primary quantity. For a Cumulus station the honest default is outside air temperature (<#temp>, realtime field 3) with <#tempunitnodeg> (field 15). Temperature is the number people look for in a thread, it has a short glyph, and Cumulus always has a unit token for it. Wind as the primary is defensible for a coastal or mountain station if you name whether it is average (<#wspeed>) or gust (<#wgust>) and you paint <#windunit>. Two primaries is how avatars become banners that do not fit.

What must be dropped versus a banner

A 468×60 Cumulus banner can reasonably carry temperature, a named wind, a station name, and a clock. An 80×80 avatar cannot. Drop, in this order, until the remaining type is readable:

  1. Station name. The forum already prints the username. Duplicating the callsign inside 80 px costs the only line you have for the unit. If several people in a thread run stations, the avatar is not how you disambiguate them; a link in the signature text is.
  2. Clock. Packet time (<#timehhmmss>) still matters scientifically. On a square it will be unread. Put freshness in HTTP Last-Modified derived from the Cumulus file, and accept that most forum caches will ignore it. That is a limitation of the medium, not a reason to paint 16:03 at 6 px.
  3. Wind direction. A 16-point compass rose at this size is a decoration. A three-letter point (NNW) plus a speed plus a unit is already the banner’s wind column. On an avatar, direction without speed is a weather vane icon pretending to be data.
  4. Pressure, rain, humidity, dewpoint. Each needs a unit and a definition (sea-level pressure versus station pressure; rain today versus rain rate). None of that survives 80 px.
  5. Forecast glyphs and condition icons. A sun/cloud pictogram derived from <#forecastnumber> or from a webcam thumbnail is a scenario or a photograph, not the temperature you think you published. If the avatar is a cartoon weather face, it is no longer a Cumulus observation product.
  6. Indoor temperature, extra sensors, UV, solar. Extra-sensor tags exist in Cumulus for stations that have them. They belong on a page with room for sensor identity. An unlabeled second number on an avatar is an unidentified sensor.

The analog thermometer spends the whole canvas on one scalar mapped to a scale. That is a different product: it communicates range and the ice point, not a compact numeral. Do not put a thermometer graphic inside an 80×80 avatar unless you are willing to drop the digits. Mixing a scale and a large number at this size guarantees that one of them is false precision.

Signatures are not station files

A forum signature is a third-party cache with no contract. The host will fetch the image URL, sometimes hotlink it, sometimes copy it, sometimes strip query strings, sometimes serve a days-old CDN object. Cumulus, meanwhile, may rewrite realtime.txt every few tens of seconds.

That mismatch is sharper for avatars than for banners because the social context implies “this is what it is like at this poster’s station right now.” It is not. It is the last PNG the forum obtained. Practical rules:

  • Generate the avatar from the same local Cumulus file the banner uses. Do not add a second fetch path that can disagree.
  • Cache by source mtime. Eighty-by-eighty PNGs are cheap; GD on every page view of a busy thread is not, and it still will not make the forum fresh.
  • Do not paint LIVE. The word does not fit, and the claim is false in a signature cache.
  • Missing data must not become 0. A black square or a visible -- is better than a fake freeze.
  • If <#SensorContactLost> is set (classic realtime field 51, Fine Offset family), the avatar should fail closed—blank or fault—not keep printing the last good temperature as if the link were up.

None of this requires redistributing the old TNET script. It is the same observation-chain honesty as any other derived image, applied to a canvas that cannot carry a footnote.

Density is why the three GD products diverged

The historical project family split identity images into three URLs because the canvases answer different questions:

| Product | Canvas | Question it can answer | |---|---|---| | Avatar | ~80×80 | What is the one number (with unit)? | | Banner | ~468×60 | What are a few independent scalars right now? | | Thermometer | tall, narrow | Where is temperature on a stated scale? |

If you find yourself putting banner fields on an avatar, you wanted a banner. If you find yourself drawing a mercury column behind the digits, you wanted a thermometer and you are about to hide the ice point behind a numeral. Keep the URLs specialized. The gallery can show avatar tiles as a style check (contrast, unit glyphs), but those tiles are still 80×80 products, not cropped banners.

Reading an avatar in the wild

If you consume someone else’s signature weather square:

  • Treat it as a historical, unlabeled screenshot of one field.
  • Do not convert units from the pixels. If the unit is missing, the image is incomplete.
  • Do not average avatars in a thread as if they were a mesonet. Siting, elevation, and cache age are unknown.
  • Prefer the station’s tag file, realtime packet, or logs if you need evidence.

Selecting one atmospheric field for a tiny display is the same editorial job as grouping evidence for a short public summary. TNET’s description of those groups is evidence families. Provenance and freshness of the files behind such summaries are data sources and methodology. The avatar is not an input to those pages; it is a warning about how little of a packet survives 80 pixels.

The Cumulus hub lists the related historical projects. The web-tag vocabulary is what you bind to the remaining scalar.

Sources