RE: [9fans] PNG and APE

RE: [9fans] PNG and APE

[cej]

Thanks, good work!! However, we should try to do native ports for
libraries,
to encourage people to write native progs.

Best,
++pac.


-----Original Message-----
From: 9fans-bounces+cej=gli.cas.cz@cse.psu.edu
[mailto:9fans-bounces+cej=gli.cas.cz@cse.psu.edu] On Behalf Of
lucio@proxima.alt.za
Sent: 23 April 2006 18:52
To: 9fans@cse.psu.edu
Subject: [9fans] PNG and APE

I have added APE ports of the most recently released versions of ZLIB
and LIBPNG and a newer PNG renderer (npng.c) to
/n/sources/contrib/lucio/pub.  The README in the same directory
started off as a mail message to describe all the relevant facets of
this project, but it got too long.

I'd like to solicit comments and possibly draw on more advanced skills
to address some of the issues I raise in the README, for which I think
npng may be a worthwhile exchange, specially if we can repair its
present shortcomings as documented in the README :-)

++L

RE: [9fans] PNG and APE

[lucio]

> Thanks, good work!! However, we should try to do native ports for
> libraries,
> to encourage people to write native progs.

Thank you for the encouragement.  That's the plan, but it's a tough
call because tracking these libraries is a nightmare.  Actually not
really so with zlib, libpng and even libjpeg (my next effort), but
once you move a little higher up to the applications, it's quite a
problem.

Anybody who wants to contribute, here are the most difficult issues:
replacing stdio with Bio and error handling (setjump.longjump, is
it?).  I don't mind coding this, but I need some code inspection once
I'm done.  You'll see in npng that I've defined empty functions for
error handling and I use sysfatal()-style handling for errors that
oughtn't to bring the program to a standstill.

In addition, advice on the "t", "v" and "3" options would not go
amiss.  I think I have "k" right, but I use "v" where I think "t"
ought to be and "v" and "3" need just the type of hint that Russ is so
good at.

Lastly, can someone tell me for definite that "e" isn't required?

++L

Re: [9fans] PNG and APE

[Lyndon Nerenberg]

 > That's the plan, but it's a tough
> call because tracking these libraries is a nightmare.  Actually not
> really so with zlib, libpng and even libjpeg (my next effort), but
> once you move a little higher up to the applications, it's quite a
> problem.

You don't have to track these utilities feechur for feechur.  You
don't even have to preserve the API, necessarily.  Not for native-to-
Plan9 implementations.  Take what's good and leave the crap behind.
(And make the good parts better, within the better environment.)

--lyndon

Re: [9fans] PNG and APE

[lucio]

> You don't have to track these utilities feechur for feechur.  You
> don't even have to preserve the API, necessarily.  Not for native-to-
> Plan9 implementations.  Take what's good and leave the crap behind.
> (And make the good parts better, within the better environment.)

Well, if one had unlimited resources, that would be great, but with
Open Source it is often the case that it's not features but bug fixes
that come along thick and fast.  Rewriting a library is no small task,
tracking it when modified isn't much fun either.

That, I'm afraid, is Plan 9's "between a rock and a hard place".

++L

Re: [9fans] PNG and APE

[lucio]

> a rewritten or from-scratch library can lead it's own life.  there's
> no requirement that said library needs to track anything.

It's still a "rock", otherwise we'd have an endless supply of improved
libraries to flaunt to our Oonix colleagues.

And re-inventing the wheel too seldom results in Porter-Duffs,
Fossil/Ventis or Factotums.  Most often the result looks like GCC.

++L

Re: [9fans] PNG and APE

[erik quanstrom]

a rewritten or from-scratch library can lead it's own life.  there's
no requirement that said library needs to track anything.

- erik

On Tue Apr 25 14:26:19 CDT 2006, lucio@proxima.alt.za wrote:
>
> Well, if one had unlimited resources, that would be great, but with
> Open Source it is often the case that it's not features but bug fixes
> that come along thick and fast.  Rewriting a library is no small task,
> tracking it when modified isn't much fun either.
>
> That, I'm afraid, is Plan 9's "between a rock and a hard place".
>
> ++L
>

Re: [9fans] PNG and APE

[Steve Simon]

> ftp://ftp.alvyray.com/Acrobat/4_Comp.pdf
> ftp://ftp.alvyray.com/Acrobat/17_Nonln.pdf

And the one that started it:
	http://www.keithp.com/~keithp/porterduff/p253-porter.pdf

-Steve

Re: [9fans] PNG and APE

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 154 bytes --]

for interesting discussions of that and several other matters, see
ftp://ftp.alvyray.com/Acrobat/4_Comp.pdf
ftp://ftp.alvyray.com/Acrobat/17_Nonln.pdf

[-- Attachment #2: Type: message/rfc822, Size: 2775 bytes --]

From: lucio@proxima.alt.za
To: 9fans@cse.psu.edu
Subject: Re: [9fans] PNG and APE
Date: Sun, 23 Apr 2006 20:32:37 +0200
Message-ID: <4a162f325b2077f65b44586f29ae5827@proxima.alt.za>

> There is a mismatch between
> PNGs definition of alpha and Plan 9's.

Wonderful, thank you.  I will fix!

++L

Re: [9fans] PNG and APE

[lucio]

> There is a mismatch between
> PNGs definition of alpha and Plan 9's.

Wonderful, thank you.  I will fix!

++L

Re: [9fans] PNG and APE

[Russ Cox]

I did not internalize the fact that your confusion over the
meaning of alpha arose from trying to process alpha
channels in PNG files.  There is a mismatch between
PNGs definition of alpha and Plan 9's.  In Plan 9 images,
the r, g, and b channels are premultiplied by alpha.
In PNG, they are not, so when you display a PNG image
with alpha channel you must do (r, g, b) *= alpha yourself
before handing it off to libdraw.

Russ

[9fans] PNG and APE

[lucio]

I have added APE ports of the most recently released versions of ZLIB
and LIBPNG and a newer PNG renderer (npng.c) to
/n/sources/contrib/lucio/pub.  The README in the same directory
started off as a mail message to describe all the relevant facets of
this project, but it got too long.

I'd like to solicit comments and possibly draw on more advanced skills
to address some of the issues I raise in the README, for which I think
npng may be a worthwhile exchange, specially if we can repair its
present shortcomings as documented in the README :-)

++L