[9fans] radar for plan 9, and two draw funnies.

[erik quanstrom]

once upon a time, it was pretty easy to get a radar
image on the web. these days, they're fancy.
the one i use is http://radar.weather.gov/ridge
which consists of a number of transparent images
that need to be overlaid. this can be done with
page, but it's pretty painful without double-buffering,
it's tied too tightly to the screen, and panning a composed
image doesn't work.

so i wrote a program imgtype that works like doctype(1)
for images. it's essentially stolen from page(1). page
could use the same code. then i wrote
a program compose that takes a series of images
of arbitrary type and composes them with SoverD.

l = (topo.jpg county.gif cities.gif warn.gif hw.gif radar.gif)
f=/lib/radar
compose $f/$l|page

this works, and is all available in contrib quanstro/radar.
it assumes you live in georgia. so you may want to edit
the script to put the right radar source in. bonus points
for ta script converting from /lib/sky/here to radar. :-)

but there are two problems.

1. for some reason the hw.gif (interstates) are
in cyan not red. drawing the radar first and the
hw second yields inverse radar colors.

2. the county boundaries get red and speckly
if any images are drawn on top of them, but only
if the target channel format is m8. r8g8b8a8
works fine. why would m8 != r8g8b8?

there's an image here
/n/sources/contrib/quanstro/drawfunny/bad.png
http://www.quanstro.net/plan9/bad.png

i belive this
http://radar.weather.gov/ridge/radar.php?rid=ffc
is what it is supposed to look like.

you can also run an experiment on this directly from sources
; cd /n/sources/contrib/quanstro/drawfunny
; ./testinplace

i've left p9p and plan 9 source there. the source in drawfunny
lags behind the contrib package.

- erik

[Russ Cox]

> why would m8 != r8g8b8?

m8 is approximately r2g2b2.
you don't have nearly enough
precision to do image compositing
and get useful results.

a better question would be why
you are using m8.

russ

[erik quanstrom]

On Sat Dec 12 09:59:41 EST 2009, r...@swtch.com wrote:
> > why would m8 != r8g8b8?
>
> m8 is approximately r2g2b2.
> you don't have nearly enough
> precision to do image compositing
> and get useful results.

that makes sense.

> a better question would be why
> you are using m8.

jpg without -t defaults to outputting
m8, even for a jpg without a colormap,
even for photos. i didn't realize that,
and i'm not doing that any more.

still, why is red getting turned to cyan?

- erik

[Russ Cox]

> still, why is red getting turned to cyan?

post a tiny program that demonstrates the
bug and i'll look into it. you pointed at a
directory with a complex program in it,
and i don't have time to dig through it.

russ

[erik quanstrom]

i'm sure this could be smaller, but i've got to run.
the images are here: /n/sources/contrib/quanstro/drawfunny/images/

; 8.out <{jpg -t9 /lib/radar/*.jpg} <{gif -t9 /lib/radar/hw.gif} <{gif -t9 /lib/radar/radar.gif}|page

#include <u.h>
#include <libc.h>
#include <bio.h>
#include <draw.h>
#include <memdraw.h>
#include <memlayer.h>

enum {
CHAN = RGBA32,
};

void
usage(void)
{
fprint(2, "usage: composetst...\n");
exits("usage");
}

Memimage*
newimage(int fd, ulong chan)
{
Memimage *t, *im;

im = readmemimage(fd);
if(im == nil)
sysfatal("readmemimage: %r");
if(chan != 0){
t = allocmemimage(im->r, chan);
if(t == nil)
sysfatal("readmemimage: %r");
memfillcolor(t, DTransparent);
memdraw(t, im->r, im, ZP, nil, ZP, SoverD);
freememimage(im);
im = t;
}
return im;
}

void
main(int argc, char **argv)
{
int i, fd;
Memimage *im, *scr;

ARGBEGIN{
default:
usage();
}ARGEND
if(argc == 0)
usage();
memimageinit();
fd = open(argv[0], OREAD);
if(fd == -1)
sysfatal("open: %r");
scr = newimage(fd, CHAN);
for(i = 1; i < argc; i++){
fd = open(argv[i], OREAD);
if(fd == -1)
sysfatal("open: %r");
im = newimage(fd, 0);
memdraw(scr, scr->r, im, ZP, nil, ZP, SoverD);
freememimage(im);
}
writememimage(1, scr);
exits("");
}

[Russ Cox]

On Sat, Dec 12, 2009 at 8:09 AM, erik quanstrom <quan...@quanstro.net> wrote:
> i'm sure this could be smaller, but i've got to run.

When you get back, please look into cutting it down
to a smaller case. For example, you could use crop
to isolate the small regions that it takes to reproduce
the problem. Even better, get it down to a single
pixel, and then you can use allocimage instead of
reading a file. That's an interesting test case.

Take your time - if the bug has lasted this long I'm
sure it can wait until you have time to isolate a good
test case.

Russ

[Jacob Todd]

On Fri, Dec 11, 2009 at 08:51:21PM -0500, erik quanstrom wrote:
> 1. for some reason the hw.gif (interstates) are
> in cyan not red. drawing the radar first and the
> hw second yields inverse radar colors.

In what order are you layering the images? According to [1] they are layered
left to right as on the toggle bar.

[1]http://www.srh.noaa.gov/jetstream/doppler/ridge_download.htm

[erik quanstrom]

i think that's beside the point here. the colors get inverted regardless
of the order of composition. try compose -t topo.jpg radar.gif hw.gif.
(this is the same order as on the site). in this case the radar image has
the wrong colors.

it looks like an α² problem, but i don't think it is. if you use an r8g8b8
base image, the color effects still happen. m8a8 yields black. i didn't
know that was legal, yet:
; gif -9 radar.gif|dd -count 1 -bs 50>[2=]; echo
m8a8 0 0 600 ;

it's especially odd to try these two:
; compose -c m8 -t topo.jpg radar.gif hw.gif
; compose -c m8 -t topo.jpg hw.gif radar.gif

- erik