I just uploaded PortaCello3.zip with .sig to:
ftp://common-lisp.net/pub/project/cello
Check out also the new scroller screen shot, now scrolling the lovely
work of our own David Steuber, which he has made available with
attribution under the Creative Commons license.
ftp://common-lisp.net/pub/project/cello/mandel-scroller.jpg
That same GIF happens to be a fine texture for shapes, including a
sierpinski sponge, itself a fractal:
ftp://common-lisp.net/pub/project/cello/mandel-sponge.jpg
David explains that the lossy nature of JPG kills the image quality, so
to see the above really well you have to... download and port Cello to
your environment. :)
The code as stands runs under AllegroCL (lprs included) and Lispworks on
windows, and a reasonable facsimile has in the past been made to run
under AllegroCL/Linux by Frank Goenninger.
Speaking of AllegroCL lprs, the install notes just talk about the ASDF
build process. Anyone using ACL can -- after adjusting
configuration.lisp according to the install notes -- just run
/dv//cello/cellodemo/cellodemo.lpr.
Look for a PortaCello4 maintenance release, after which Kenny goes to
work on his own project and porting proceeds only as others do ports.
Future releases will continue, but will be KennyCellos, ie, just what he
uses day-to-day. Eventually this will include a Mac OS X port, but that
could be a lonnnnnnngggggg time from now.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····················@nyc.rr.com...
> I just uploaded PortaCello3.zip with .sig to:
>
> ftp://common-lisp.net/pub/project/cello
>
Hello Kenny,
In the zip file
CORE_DB_WAND_.DLL has dependencies on
CORE_DB_MAGICK_.DLL which is not supplied
and on MSVCRTD.DLL which is not standard on windows (but I believe my be
destributed
with microsoft compiled code).
As such the cells demo does not work as the dll CORE_DB_WAND_.DLL can not be
loaded
Rene.
Rene de Visser wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ·····················@nyc.rr.com...
>
>>I just uploaded PortaCello3.zip with .sig to:
>>
>> ftp://common-lisp.net/pub/project/cello
>>
>
> Hello Kenny,
>
> In the zip file
> CORE_DB_WAND_.DLL has dependencies on
>
> CORE_DB_MAGICK_.DLL which is not supplied
Oops. Others, too, I think. After uploading I realized I forgot to
reiterate in the install notes the bit about getting/building the
necessary libraries.
The only DLL in there you need from me is the FTGL one, unless you want
to go nuts and build your own. Binaries for FreeGlut and IM are on the
Web. Linux yabos need to build their own, but I gather there are
packages for the libraries used by Cello for the big Linux distros. I'll
fix up the install notes and replace. Meanwhile...
ftp://ftp.imagemagick.org/pub/ImageMagick/binaries
Grab the 6.0 version. Their doc says the Q8 version is a lot faster than
Q16 for not much less quality.
>
> and on MSVCRTD.DLL which is not standard on windows (but I believe my be
> destributed
> with microsoft compiled code).
If that bad boy is not amongst the bunch that come with the ImageMagick
dll I will add it to the distro.
Thx for the report,
Kenny
>
> As such the cells demo does not work as the dll CORE_DB_WAND_.DLL can not be
> loaded
>
> Rene.
>
>
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····················@nyc.rr.com...
> Rene de Visser wrote:
> > "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> > ·····················@nyc.rr.com...
> >
> >>I just uploaded PortaCello3.zip with .sig to:
> >>
> >> ftp://common-lisp.net/pub/project/cello
> >>
> > and on MSVCRTD.DLL which is not standard on windows (but I believe my be
> > destributed
> > with microsoft compiled code).
Hello Kenny,
I think its best to recompile FTGL.DLL so that it uses MSVCRT.DLL (which
comes with windows) rather than MSVCRTD.DLL (which is the visual studio
debug version), as even with MSVCRTD.DLL on my system, it refuse to load
MSVCRTD.DLL (maybe wrong version? or requires Visual studio?).
Rene.
Rene de Visser wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ·····················@nyc.rr.com...
>
>>Rene de Visser wrote:
>>
>>>"Kenny Tilton" <·······@nyc.rr.com> wrote in message
>>>·····················@nyc.rr.com...
>>>
>>>
>>>>I just uploaded PortaCello3.zip with .sig to:
>>>>
>>>> ftp://common-lisp.net/pub/project/cello
>>>>
>>>
>>>and on MSVCRTD.DLL which is not standard on windows (but I believe my be
>>>destributed
>>>with microsoft compiled code).
>
> Hello Kenny,
>
> I think its best to recompile FTGL.DLL so that it uses MSVCRT.DLL (which
> comes with windows) rather than MSVCRTD.DLL (which is the visual studio
> debug version),...
oh, sorry, I had no clue. I will get a new DLL up ASAP. Send me an email
if you would like to email it to you directly as well.
Thx for the detective work.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> I just uploaded PortaCello3.zip with .sig to:
>
> ftp://common-lisp.net/pub/project/cello
>
> Check out also the new scroller screen shot, now scrolling the lovely
> work of our own David Steuber, which he has made available with
> attribution under the Creative Commons license.
>
> ftp://common-lisp.net/pub/project/cello/mandel-scroller.jpg
>
> That same GIF happens to be a fine texture for shapes, including a
> sierpinski sponge, itself a fractal:
>
> ftp://common-lisp.net/pub/project/cello/mandel-sponge.jpg
>
> David explains that the lossy nature of JPG kills the image quality,
> so to see the above really well you have to... download and port Cello
> to your environment. :)
Why don't you use the PNG format instead?
Bj�rn
Bj�rn Lindberg wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>That same GIF happens to be a fine texture for shapes, including a
>>sierpinski sponge, itself a fractal:
>>
>> ftp://common-lisp.net/pub/project/cello/mandel-sponge.jpg
>>
>>David explains that the lossy nature of JPG kills the image quality,
>>so to see the above really well you have to... download and port Cello
>>to your environment. :)
>
>
> Why don't you use the PNG format instead?
Oh, is /that/ what PNG is? :) I will give it a try later today.
Thx,
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Bj�rn Lindberg wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>I just uploaded PortaCello3.zip with .sig to:
>>
>> ftp://common-lisp.net/pub/project/cello
>>
>>Check out also the new scroller screen shot, now scrolling the lovely
>>work of our own David Steuber, which he has made available with
>>attribution under the Creative Commons license.
>>
>> ftp://common-lisp.net/pub/project/cello/mandel-scroller.jpg
>>
>>That same GIF happens to be a fine texture for shapes, including a
>>sierpinski sponge, itself a fractal:
>>
>> ftp://common-lisp.net/pub/project/cello/mandel-sponge.jpg
>>
>>David explains that the lossy nature of JPG kills the image quality,
>>so to see the above really well you have to... download and port Cello
>>to your environment. :)
>
>
> Why don't you use the PNG format instead?
Whoa, I just now told ImageMagick to write it out as PNG instead of JPG
and it came out five times bigger, twice as big as GIF. Do those numbers
sound right? Oh, OK, a BMP comes out five times /bigger/ than the PNG,
and I know the GIF is controversial for the compression algorithm.
Anyway, you are right, I should not be using JPGs for screen shots. PNG
and GIF let one see things such as the anti-aliased font quality much
better. Don't know what I was thinking. Bandwidth, I guess, but any
Lispnik interested in Cello probably has the bandwidth.
Thx for the dope-slap.
Note to Renee: I was doing this to cheer myself up after a frustrating
few hours trying to figure out what the *&^*& I had done building FTGL.
Got that figured out and working without msvcrtd.dll, but now one of the
imagemagick DLLs dies looking for it (I renamed mine), so now I have to
go find a non-debug version of IM. I would add my msvcrtd.dll to the
distro but I suspect there will then be another such DLL which it or
someone else loads, so I'll carry on getting all the DLLs out of debug. RSN.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Whoa, I just now told ImageMagick to write it out as PNG instead of JPG and
> it came out five times bigger, twice as big as GIF. Do those numbers sound
> right? Oh, OK, a BMP comes out five times /bigger/ than the PNG, and I know
> the GIF is controversial for the compression algorithm.
Kenny, you have just discovered the difference between lossless and lossy
compression. Meaning that lossless compression will encode exactly the same
image you started with....
JPEG - lossy, with 'quality' parameter
GIF - lossy, pallete based colour
PNG - lossless, with 'compression' parameter (just like gzip, higher is
more compression but will cost more CPU to decompress
BMP - lossless, no compression, windows standard
Out of all these options, PNG is the best if you care about image fidelity
more than bandwidth, JPEG is probably best if your priorities are the
other way around. There are (quite a number) of other issues as well...
cheers,
Simon
Simon Alexander wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>Whoa, I just now told ImageMagick to write it out as PNG instead of JPG and
>>it came out five times bigger, twice as big as GIF. Do those numbers sound
>>right? Oh, OK, a BMP comes out five times /bigger/ than the PNG, and I know
>>the GIF is controversial for the compression algorithm.
>
>
> Kenny, you have just discovered the difference between lossless and lossy
> compression. Meaning that lossless compression will encode exactly the same
> image you started with....
I had never heard of PNG, just assumed it was some FSF alternative to
something. I didn't know GIF was lossy, tho. That explains a
long-standing mystery about why PhotoShop would not allow GIF saves of
certain color modes.
>
> JPEG - lossy, with 'quality' parameter
> GIF - lossy, pallete based colour
> PNG - lossless, with 'compression' parameter (just like gzip, higher is
> more compression but will cost more CPU to decompress
> BMP - lossless, no compression, windows standard
>
> Out of all these options, PNG is the best if you care about image fidelity
> more than bandwidth, JPEG is probably best if your priorities are the
> other way around.
Yeah, I'll stick with PNG for screen shots. The Savages of CLIM really
hate my eye-candy, so I want to rub it in as much as possible. :)
I must say, I had been surprised at how bad the JPGs looked, but I never
put two and two together. I have played a lot with JPGs to see what
difference various qualities made and always thought JPG compression was
splendid. Probably it breaks down more noticeably because of the small
type and antialiasing.
Thx for the info.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> I had never heard of PNG, just assumed it was some FSF alternative to
> something. I didn't know GIF was lossy, tho. That explains a
> long-standing mystery about why PhotoShop would not allow GIF saves
> of certain color modes.
PNG is 24 bit "true color". GIF is based on a palette of upto 256
colors. The latter is called index mode and a true color image will
not be saveable in an index mode format until you first convert it to
index mode, creating a color palette.
PNG stands for Portable Network Graphics and was developed for a
couple reasons that I know of. One was the LZW patent issue. GIF
uses LZW compression. The other was to support true color images with
a lossless compression scheme.
The PNG format has been around for a while now and all the major
graphical web browsers support it for inlined images.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
+ David Steuber <·····@david-steuber.com>:
| PNG is 24 bit "true color".
It /may/ be. But PNG also supports gray scale with 1, 2, 4, 8 or 16
bits per pixel, and RGB with 8 or 16 bits per pixel and channel.
Meaning 24 or 48 bits per pixel. If you have an alpha channel, that
becomes 36 or 64 bits per pixel.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Kenny Tilton <·······@nyc.rr.com> writes:
> I had never heard of PNG, just assumed it was some FSF alternative to
> something. I didn't know GIF was lossy, tho. That explains a
> long-standing mystery about why PhotoShop would not allow GIF saves
> of certain color modes.
GIF is only lossy wrt. palettes. So it's still a good format for
saving pictures which have a fixed an limited number of colors.
(But I personally prefer JPG for photos and PNG for everything else)
--
(espen)
Kenny Tilton wrote:
> I had never heard of PNG, just assumed it was some FSF alternative to
> something. I didn't know GIF was lossy, tho. That explains a
> long-standing mystery about why PhotoShop would not allow GIF saves of
> certain color modes.
A notable difference between GIF and PNG is that you can specify
the opacity of pixels. With GIFs you need to provide as many images
as there are backgrounds. With PNGs you just make one and give
the background pixels 100% opacity.
--
Jens Axel S�gaard
On Wed, 21 Apr 2004 10:07:24 +0200, Jens Axel S�gaard wrote:
> A notable difference between GIF and PNG is that you can specify
> the opacity of pixels. With GIFs you need to provide as many images
> as there are backgrounds. With PNGs you just make one and give
> the background pixels 100% opacity.
No, a GIF can have a transparent background. It doesn't support partial
transparency though, which PNG supports.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> On Wed, 21 Apr 2004 10:07:24 +0200, Jens Axel S�gaard wrote:
>>A notable difference between GIF and PNG is that you can specify
>>the opacity of pixels. With GIFs you need to provide as many images
>>as there are backgrounds. With PNGs you just make one and give
>>the background pixels 100% opacity.
> No, a GIF can have a transparent background. It doesn't support partial
> transparency though, which PNG supports.
You are right. I think I confused it with the problems when the opacity
was in the PNG format, but IE didn't show it properly.
--
Jens Axel S�gaard
Jens Axel S�gaard <······@soegaard.net> writes:
> You are right. I think I confused it with the problems when the opacity
> was in the PNG format, but IE didn't show it properly.
yes, the problems with poor png support in IE still puts some restrictions
on the png features you can safely use, doesn't it?
--
(espen)
On 2004-04-21 11:33:17, Espen Vestre wrote:
> Jens Axel S�gaard <······@soegaard.net> writes:
>> You are right. I think I confused it with the problems when the opacity
>> was in the PNG format, but IE didn't show it properly.
>
> yes, the problems with poor png support in IE still puts some restrictions
> on the png features you can safely use, doesn't it?
You can't use the prefered MIME type for XHTML. You can't use CSS2,
DOM1, DOM2, ... All this due to the IE.
Kenny Tilton <·······@nyc.rr.com> writes:
> I had never heard of PNG, just assumed it was some FSF alternative to
> something. I didn't know GIF was lossy, tho. That explains a long-standing
> mystery about why PhotoShop would not allow GIF saves of certain color
> modes.
Note other comments in this thread --- *some* images are losslessly
represented by GIF, others cannot be. It is the colourmap which is
(potentially) lossy, not the compression. PNG has been around for a while
now. It also features improved alpha channel compared to GIF
(i.e. transparency). For lossless compression and truecolor (i.e. 24bit)
representation, it does a pretty good job --- and most browsers support it
(at least partially, IE famously, due to a design flaw iirc, screwed up
transparency with them for ages, don't know if that is fixed yet).
> I must say, I had been surprised at how bad the JPGs looked, but I never
> put two and two together. I have played a lot with JPGs to see what
> difference various qualities made and always thought JPG compression was
> splendid. Probably it breaks down more noticeably because of the small type
> and antialiasing.
JPEG (and moreso JPEG2000) is a pretty decent general purpose image
compression approach, but any lossy process will have the potetial for
objectionable artifacts on some input.
Simon.
Kenny Tilton wrote:
> Simon Alexander wrote:
>
>> JPEG - lossy, with 'quality' parameter GIF - lossy, pallete based
>> colour PNG - lossless, with 'compression' parameter (just like gzip,
>> higher is
>> more compression but will cost more CPU to decompress
>> BMP - lossless, no compression, windows standard
>>
>> Out of all these options, PNG is the best if you care about image
>> fidelity more than bandwidth, JPEG is probably best if your
>> priorities are the other way around.
>
Another advantage of PNG over JPEG is that it can store an alpha channel.
(Alpha channel is normally used to hold per-pixel transparency data.)
So this
makes it useful for storing texture maps that have transparent areas and
are used
as decals. Of course you could do this with JPEG by saving two files
(one for RGB
and one for ALPHA) and combining them after they're loaded.
On Tue, 20 Apr 2004 21:23:22 -0400, Simon Alexander wrote:
> GIF - lossy, pallete based colour
GIF compression is not lossy. But since it supports only palette based
colour, it becomes lossy because the image must be reduced to 256 colours.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> On Tue, 20 Apr 2004 21:23:22 -0400, Simon Alexander wrote:
>
> > GIF - lossy, pallete based colour
>
> GIF compression is not lossy. But since it supports only palette based
> colour, it becomes lossy because the image must be reduced to 256 colours.
Correct. However, my mandelbrot3.gif file was already palette based
with fewer than 256 colors, so no information had to be thrown away as
it didn't exist in the first place.
PNG has the advantage of working with 24 bit color which also goes a
long way towards explaining why the GIF would be smaller.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> On Tue, 20 Apr 2004 21:23:22 -0400, Simon Alexander wrote:
>
> > GIF - lossy, pallete based colour
>
> GIF compression is not lossy. But since it supports only palette based
> colour, it becomes lossy because the image must be reduced to 256 colours.
>
Yes, that was poorly worded. I didn't mean to suggest that the compression
algorithm itself was lossy. If your image gamut is not representable by a
colour pallette, then the process is lossy....
S.
In article <·····················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Viola: ftp://ftp.common-lisp.net/pub/project/cello
Is "viola" the successor to "cello"? ;-)
New files at:
ftp://common-lisp.net/pub/project/cello
pc3-install-v2.txt -- more info on libraries
PC3-dynlib.zip -- full set of win32 DLLs, no longer in debug
PC3-ftgl.zip -- Just the FTGL dll, plus two source files providing C
glue to FTGL (a C++ library)
Meanwhile, deep in the orchestra pit:
Sashank Varma wrote:
> In article <·····················@twister.nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>Viola: ftp://ftp.common-lisp.net/pub/project/cello
>
>
> Is "viola" the successor to "cello"? ;-)
C'est une bonne idee.
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Hi Kenny Tilton,
> Whoa, I just now told ImageMagick to write it out as PNG instead of JPG
> and it came out five times bigger, twice as big as GIF. Do those numbers
> sound right?
They do given the extra colours your images contain. For example
mandel-scroller.png contains 6195 colours (identify -verbose) and a GIF
can only contain a 256 colour palette.
If you want to save some bandwidth use maximum compression when creating
the PNGs. In ImageMagick:
$ convert -quality 100 mandel-scroller.png mandel-scroller2.png
mandel-scroller2.png is only 257KiB compared to 335KiB for the original
image.
From the manual:
For the MNG and PNG image formats, the quality value sets the zlib
compression level (quality / 10) and filter-type (quality % 10).
Compression levels range from 0 (fastest compression) to 100 (best but
slowest). For compression level 0, the Huffman-only strategy is used,
which is fastest but not necessarily the worst compression.
Regards,
Adam