[AWT] Aus Image ein Grafikformat erzeugen, das mit transparenten Bereichen im Browser dargestellt werden kann
Carl Rosenberger
auch auf die Gefahr hin, dass ich um die Zeit mal wieder selbst
mit der Lösung schneller bin, bis sich jemand erbarmt:
Ich habe in meiner Applikation ein java.awt.Image, das auch
transparente Bereiche enthält. Aus der Darstellung im
Programm wird dynamisch HTML erzeugt, dass 100% genauso
aussehen soll.
Welches Format nehme ich für die Bilder?
Zuerst habe ich PNGs mit ImageIO.write() geschrieben.
Das sieht in Opera6 und Netscape6 wunderbar aus aber
leider nicht in MS Browsern. Nach einigem googlen habe ich
den Hinweis, dass es vermutlich daran liegt, dass 8-Bit PNG
Dateien erzeugt werden. Kann das sein?
Gibt es eine Möglichkeit mit Java-Bordmitteln auch 24-Bit
PNG Dateien zu erzeugen?
Meine Applikation ist eine Java Webstart Applikation und
so weit es geht versuche ich Bibliotheken zu sparen.
JAI muss nicht unbedingt auch noch mit.
Vielleicht sind GIFs ohnehin besser?
Nach weiteren Google Informationen funktionieren da
transparente Bilder auch mit alten Browsern gut.
Leider schreibt ImageIO.write() scheinbar keine GIFs.
Wie kann ich es dazu bringen?
Bietet sich eine fremde Bibliothek dafür an?
Mit erstem Googlen bin ich auf folgenden Code gestossen:
http://www.acme.com/java/software/Acme.JPM.Encoders.GifEncoder.html
Ist das die beste und kleinste Lösung?
Wie sieht es bei den Grössenverhältnissen von GIFs und PNGs aus?
Jeder Tip ist herzlich willkommen. Danke.
Viele Grüße,
Carl
Carl Rosenberger
> auch auf die Gefahr hin, dass ich um die Zeit mal wieder selbst
> mit der Lösung schneller bin, bis sich jemand erbarmt:
So langsam mutiere ich hier zum Running Gag.
> http://www.acme.com/java/software/Acme.JPM.Encoders.GifEncoder.html
> Ist das die beste und kleinste Lösung?
Das funktioniert wunderbar, der Quellcode ist erträglich wenig
und die Lizenz ist O.K.
Aus dem ACME Paket braucht man lediglich die Klassen:
Acme.IntHashtable
Acme.JPM.Encoders.ImageEncoder
Acme.JPM.Encoders.GifEncoder
Um aus einem Image eine GIF-Datei zu produzieren:
void writeGIF(Image img, File file) throws IOException{
FileOutputStream fos = new FileOutputStream(file);
new GifEncoder(img, fos).encode();
fos.flush();
fos.close();
}
> Wie sieht es bei den Grössenverhältnissen von GIFs und PNGs aus?
Das interessiert mich natürlich nach wie vor, vor
allem was 24-Bit PNGs betrifft und ob die dann im
MSIE ab 5.0 funktionieren.
Viele Grüße,
Carl
Stefan Matthias Aust
> Leider schreibt ImageIO.write() scheinbar keine GIFs.
Java schreibt keine GIFs weil jeder, der GIFs schreibt, dafür eine
Lizenz von Unisys braucht.
bye
--
Stefan Matthias Aust //
www.3plus4software.de // Inter Deum Et Diabolum Semper Musica Est
Carl Rosenberger
> > http://www.acme.com/java/software/Acme.JPM.Encoders.GifEncoder.html
> > Ist das die beste und kleinste Lösung?
>
> Das funktioniert wunderbar, der Quellcode ist erträglich wenig
> und die Lizenz ist O.K.
Arrrgghhhh !!!
Doch noch ein Haken:
java.io.IOException: too many colors for a GIF
at Acme.JPM.Encoders.GifEncoder.encodeDone(GifEncoder.java:144)
Die allerschnellste Lösung für Exceptions gibts wie immer, indem
man sie direkt in die GoogleGroup-Suche hackt.
Da wird mir zum Jimi ColorReducer geraten. Jimi ist mir aber
definitiv zu gross für meine Webstart Applikation.
Nochmal mit ColorReducer suchen. Aaah, Linda weiss wie es geht:
http://www.gurge.com/amd/java/quantize/
Danke Linda!
...und danke Adam für den schnellen kompakten Code.
...die Bilder von Neuseeland sind auch schön.
Jetzt ist wirklich alles paletti.
Ah, Java mit den ganzen verfügbaren Bibliotheken und der aktiven
Community mit zigtausend Postings ist einfach so supergenial.
Wenn jetzt mal wieder ein Thread "Wofür braucht man Java überhaupt ?"
kommt, hau ich ihm die gesammelten Links meiner eigenen
gesucht-und-gefunden-Threads um die Ohren.
...wartet nur bis meine Applikation fertig ist.
...das wird so geil.
Viele Grüße,
Carl
Carl Rosenberger
> > Leider schreibt ImageIO.write() scheinbar keine GIFs.
>
> Java schreibt keine GIFs weil jeder, der GIFs schreibt, dafür eine
> Lizenz von Unisys braucht.
Ups!
Ich auch?
Links?
Rechts?
Carl Rosenberger
Scheint so.
http://www.unisys.com/about__unisys/lzw/
Danke für die hilfreiche Information, Stefan, das wusste ich nicht.
Viele Grüße,
Carl
Frank Buss
> Gibt es eine Möglichkeit mit Java-Bordmitteln auch 24-Bit
> PNG Dateien zu erzeugen?
Geht bestimmt auch einfacher, aber du könntest auf jeden Fall mit der
Pixelgrabber-Klasse das Bild in ein Byte-Array kopieren und die PNG-Datei
selbst schreiben. Das PNG-Format ist sehr einfach, ich habe das vor ein
paar Jahren sogar mal als proof-of-concept in PHP programmiert, wobei ich
da noch den zlib-Stream selbst erzeugen musste (schonmal Adler-32-
Checksummenberechnung in PHP programmiert?), was du in Java nicht musst, da
per Deflater-Klasse schon vorhanden. Hier das Beispiel und der Quelltext
dazu:
http://www.frank-buss.de/clock.php3
http://www.frank-buss.de/clock.phps
--
Frank Buß, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Marco Lange
>>auch auf die Gefahr hin, dass ich um die Zeit mal wieder selbst
>>mit der Lösung schneller bin, bis sich jemand erbarmt:
>
> So langsam mutiere ich hier zum Running Gag.
Du lässt den anderen aber auch gar keine Zeit :-)
Auf das Lizenz-Problem, hat Dich ja Stefan schon aufmerksam gemacht.
Genau diese Tatsache, das Unisys nach jahrelanger Verbreitung u.a. durch
Compuserve ganz plötzlich auf die Idee kam, man habe ja ein Patent auf
das bei der Erstellung von GIFs verwendete LZW-Kompressionsverfahren und
könne schließlich daraus Profitschlagen, war ja der Grund warum
überhaupt das PNG-Format, das für ein verlustfrei komprimiertes
Image-Format IMHO wirklich gut ist, entwickelt wurde.
Ich verstehe wirklich nciht, warum die Unterstützung für PNG immer noch
so dürftig ausfällt, gerade seitens Microsoft.
Noch einmal zum GIF-Format. Ich möchte nicht lügen, aber ich meine
einmal gehört zu haben, dass man GIFs auch ohne Kompression erzeugen
kann und dann wahrscheinlich auch keine Lizenzgebühren bezahlen muss.
Vielleicht kannst Du ja die Größe der Bilder verschmerzen (ich
extrapoliere jetzt einmal, dass es sich immer noch um das
PDF-Thumbnail-Projekt handelt, wenn es sich bei den PDFs größtenteils um
Text handelt, würde Dir evtl. auch RLE genügen als
Kompressionsverfahren, dabei wiederum weiß ich aber nicht, ob GIF dies
unterstützt.
Viele Grüße zu übernächtigter Zeit,
Marco
Marco Lange
> Das PNG-Format ist sehr einfach [...]
Infos dazu gibt es auch noch unter:
http://www.libpng.org/pub/png/
Viele Grüße,
Marco Lange
Marco Schmidt
>Scheint so.
>http://www.unisys.com/about__unisys/lzw/
>
>Danke für die hilfreiche Information, Stefan, das wusste ich nicht.
Unter
<http://www.geocities.com/marcoschmidt.geo/java-image-faq.html#libraries>
findest Du Links zu der Patentlage. Es wird davon ausgegangen, daß ab
Juni 2003 das LZW-Patent wegfällt. Allerdings sind Unisys die mit den
vielen Anwälten...
Gruß,
Marco
--
Bitte nur in der Newsgroup antworten, nicht per Email!
de.comp.lang.java Homepage: http://www.dclj.de/
FAQ: http://www.faqs.org/faqs/de/comp-lang-java/faq/
Meine Java-Seiten: http://www.geocities.com/marcoschmidt.geo/java.html
Marco Schmidt
[...]
>Jetzt ist wirklich alles paletti.
Noch als Ergänzung: Der qualitativ beste (wenn auch deutlich
langsamste) Java-Farbquantisierer dürfte NeuQuant von
<http://www.fmsware.com/stuff/gif.html> sein.
[...]
Marco Schmidt
>> Wie sieht es bei den Grössenverhältnissen von GIFs und PNGs aus?
>
>Das interessiert mich natürlich nach wie vor, vor
>allem was 24-Bit PNGs betrifft und ob die dann im
>MSIE ab 5.0 funktionieren.
Beim Vergleich 8-Bit GIF vs. PNG gewinnt PNG eigentlich immer, außer
es handelt sich um sehr kleine Bilder.
24-Bit PNG vs. 8-Bit GIF ist nicht wirklich fair, da das PNG dann
üblicherweise mehr (und weniger redundante) Informationen speichert.
Bei PDF-Thumbnails (um die es sich hier wahrscheinlich handelt)
dürften 24 Bit i.A. nicht notwendig sein.
Übrigens: Die Dateigröße hängt auch direkt von der Art der
Farbreduktion ab. Wenn Du Dithering benutzt, um die Bildqualität zu
erhöhen, werden auch automatisch die Dateien größer.
Auf <http://www.libpng.org/pub/png/pngapbr.html> erfährst Du mehr über
den PNG-Support diverser Browser.
Marco Schmidt
>Auf das Lizenz-Problem, hat Dich ja Stefan schon aufmerksam gemacht.
>Genau diese Tatsache, das Unisys nach jahrelanger Verbreitung u.a. durch
>Compuserve ganz plötzlich auf die Idee kam, man habe ja ein Patent auf
>das bei der Erstellung von GIFs verwendete LZW-Kompressionsverfahren und
>könne schließlich daraus Profitschlagen, war ja der Grund warum
>überhaupt das PNG-Format, das für ein verlustfrei komprimiertes
>Image-Format IMHO wirklich gut ist, entwickelt wurde.
Mich ärgert das Patent auf diesen simplen Algorithmus auch. Allerdings
schwingt bei der GIF-LZW-Diskussion oft der Vorwurf mit, Unisys habe
GIF großwerden lassen, um dann abzusahnen. Tatsächlich ist Unisys aber
eine große Firma mit vielen Patenten und Mitarbeitern, und GIF war
anfangs nicht gerade allgegenwärtig. Sie werden es also einfach nicht
gemerkt haben. Compuserve hat seine Hausaufgaben beim Entwickleln von
GIF nicht gemacht. Später haben sie (=Compuserve) dann gemerkt, daß
LZW patentiert ist, und das Format trotzdem nicht umgeworfen. Daß
Unisys freiwillig auf Geld verzichtet, können die gegenüber ihren
Shareholdern wohl kaum verantworten.
>Ich verstehe wirklich nciht, warum die Unterstützung für PNG immer noch
>so dürftig ausfällt, gerade seitens Microsoft.
Faulheit. Andere Prioritäten. Desinteresse.
>Noch einmal zum GIF-Format. Ich möchte nicht lügen, aber ich meine
>einmal gehört zu haben, dass man GIFs auch ohne Kompression erzeugen
>kann und dann wahrscheinlich auch keine Lizenzgebühren bezahlen muss.
Man könnte stets nur Codes aussenden, die direkt für einen Pixel
stehen, statt solche, die Pixelketten referenzieren (erst damit wird
eine Datenreduktion erreicht). So verschwendet man ca. 1 Bit pro Pixel
(die Datei wird also sogar noch etwas größer als die unkomprimierte
Bildversion), verzichtet aber auf die Anwendung von LZW. Eigentlich
ist man damit im Reinen. Aber das wird bestimmt ein toller Prozeß
gegen Unisys' Rechtsabteilung. Besonders interessant in den USA, wo
man dann einer Laien-Jury erklären muß, warum das keine Anwendung von
LZW ist. Viel Glück!
>Vielleicht kannst Du ja die Größe der Bilder verschmerzen (ich
>extrapoliere jetzt einmal, dass es sich immer noch um das
>PDF-Thumbnail-Projekt handelt, wenn es sich bei den PDFs größtenteils um
>Text handelt, würde Dir evtl. auch RLE genügen als
>Kompressionsverfahren, dabei wiederum weiß ich aber nicht, ob GIF dies
>unterstützt.
Nein, GIF unterstützt nur LZW. Eine "Umgehung durch Verzicht auf
Datenreduktion" hab ich ja bereits beschrieben. Wobei laut der
anderswo zitierten Browser-Support-Seite IE 4+ eigentlich mit PNG (der
eigentlich sinnvollsten Lösung) umgehen müßte, solange man auf
Alpha-Werte verzichtet.
Carl, ist das evtl. das Problem? Daß Du noch Transparenzinformation im
PNG hast - entweder als voller Alpha-Kanal oder als "transparent
index"? Kannst Du mal ein Test-PNG bereitstellen?
Marco Schmidt
[...]
>Das PNG-Format ist sehr einfach, ich habe das vor ein
>paar Jahren sogar mal als proof-of-concept in PHP programmiert, wobei ich
>da noch den zlib-Stream selbst erzeugen musste (schonmal Adler-32-
>Checksummenberechnung in PHP programmiert?), was du in Java nicht musst, da
>per Deflater-Klasse schon vorhanden. Hier das Beispiel und der Quelltext
>dazu:
>
>http://www.frank-buss.de/clock.php3
>http://www.frank-buss.de/clock.phps
Auf <http://www.geocities.com/marcoschmidt.geo/java-image-coding.html>
sind auch PNG-Encoder aufgeführt. Abgesehen von der eingebauten
Unterstützung ab 1.4. Selbermachen ist diesem Fall also eigentlich
unnötig.
Stefan Matthias Aust
> Auf das Lizenz-Problem, hat Dich ja Stefan schon aufmerksam gemacht.
> Genau diese Tatsache, das Unisys nach jahrelanger Verbreitung u.a. durch
> Compuserve ganz plötzlich auf die Idee kam, man habe ja ein Patent auf
> das bei der Erstellung von GIFs verwendete LZW-Kompressionsverfahren und
^
auch
Nicht nur GIF ist betroffen, komprimierende TIFFs z.B. auch.
> Ich verstehe wirklich nciht, warum die Unterstützung für PNG immer noch
> so dürftig ausfällt, gerade seitens Microsoft.
PNGs mit allen Bells and Whistles zu unterstützen ist wohl schwerer als
das es den Aufwand lohnt. Der Anwender merkt es ja nicht, honoriert es
demzufolge nicht und daher ist so eine Änderung nicht so attraktiv.
Vielleicht sagen sie sich auch - wo wir schon bezahlt haben, sollen es
die anderen auch tun...
> Noch einmal zum GIF-Format. Ich möchte nicht lügen, aber ich meine
> einmal gehört zu haben, dass man GIFs auch ohne Kompression erzeugen
> kann und dann wahrscheinlich auch keine Lizenzgebühren bezahlen muss.
Geht, muss man nicht, ist aber ziemlich dumm, da die Dinger natürlich
riesig werden. Dann würde ich lieber unkomprimierte BMPs schreiben.
Das ist wesentlich einfacher und die gibt es auch mit 24 (und 32 Bit -
meine ich) Farbtiefe.
> Text handelt, würde Dir evtl. auch RLE genügen als
> Kompressionsverfahren, dabei wiederum weiß ich aber nicht, ob GIF dies
> unterstützt.
Nein. RLE ist aber bei BMPs möglich.
Daniel Urban
"Carl Rosenberger" <ca...@db4o.com> schrieb im Newsbeitrag
news:auqmag$mq2$02$1...@news.t-online.com...
> > http://www.acme.com/java/software/Acme.JPM.Encoders.GifEncoder.html
> > Ist das die beste und kleinste Lösung?
>
> Das funktioniert wunderbar, der Quellcode ist erträglich wenig
> und die Lizenz ist O.K.
Irre ich mich, oder sind GIFs nicht geschützt, also das Schreiben von GIFs
ist nicht lizenzsfrei?
Gruß,
Daniel
Marcus Stursberg
> ...das wird so geil.
Hoffentlich machst du hier auch einen schicken Announce, damit wir alle
deine Arbeit bewundern können.
Gruß und frohes neues Jahr
Marcus
Marco Lange
>> Ich verstehe wirklich nciht, warum die Unterstützung für PNG immer
>> noch so dürftig ausfällt, gerade seitens Microsoft.
>
> PNGs mit allen Bells and Whistles zu unterstützen ist wohl schwerer als
> das es den Aufwand lohnt. Der Anwender merkt es ja nicht, honoriert es
> demzufolge nicht und daher ist so eine Änderung nicht so attraktiv.
Da hast Du recht, es bietet keine Basis für einen Marketing-Feldzug.
"Jetzt mit 100%-PNG-Unterstützung" veranlasst wohl 99% aller IE-User nur
zu Schulterzucken.
>> Noch einmal zum GIF-Format. Ich möchte nicht lügen, aber ich meine
>> einmal gehört zu haben, dass man GIFs auch ohne Kompression erzeugen
>> kann und dann wahrscheinlich auch keine Lizenzgebühren bezahlen muss.
>
> Geht, muss man nicht, ist aber ziemlich dumm, da die Dinger natürlich
> riesig werden. Dann würde ich lieber unkomprimierte BMPs schreiben. Das
> ist wesentlich einfacher und die gibt es auch mit 24 (und 32 Bit - meine
> ich) Farbtiefe.
> [...]
> Nein. RLE ist aber bei BMPs möglich.
Ich persönlich vermeide gerade bei Web-Applikationen den Einsatz von
BMPs, da ich sie zu Windows-proprietär finde.
Viele Grüße,
Marco
Carl Rosenberger
> Carl, ist das evtl. das Problem? Daß Du noch Transparenzinformation im
> PNG hast - entweder als voller Alpha-Kanal oder als "transparent
> index"? Kannst Du mal ein Test-PNG bereitstellen?
Klar kann ich ein Test-PNG bereitstellen:
http://www.yetac.com/png/
Der einzige Browser, der das so anzeigt, wie es aussehen
soll, ist Opera6.
Eine GIF-Version habe ich auch:
http://www.yetac.com/gif/
So bin ich auch mit dem Look von Microsoft zufrieden.
Weil hier spekuliert wurde, wie die "Thumbnails" aussehen sollen:
Das Programm wird von Architekten eingesetzt, die auch gigantische
Pläne als PDFs abspeichern. Die Grösse der erzeugten "Thumbnails"
(hier eher "Voransichten") können die Architekten selbst einstellen.
Dabei können auch seitenfüllende Grafiken heraus kommen.
Zur Erzeugung der Graphiken:
Wie gehabt ersetze ich in den Image Objekten die Farbe Weiss
durch 0:
private Image makeTransLucent(Image img){
final int whiteRGB = Color.WHITE.getRGB();
ImageFilter filter = new RGBImageFilter() {
public int filterRGB(int x, int y, int rgb) {
if (rgb == whiteRGB) {
return 0;
}
return rgb;
}
};
FilteredImageSource fis =
new FilteredImageSource(
img.getSource(),
filter);
return Toolkit.getDefaultToolkit().createImage(fis);
}
Gäbe es noch eine bessere Möglichkeit, um PNGs zu erzeugen,
die auch in MSIE gut aussehen?
Viele Grüße,
Carl
Marco Schmidt
[Test-PNGs]
Also benutzt Du wirklich Transparenz, das meinte ich ja. Dein
Code-Schnipsel
[...]
>private Image makeTransLucent(Image img){
[...]
konvertiert alle weißen Pixel in durchsichtige - und das ist so
gewollt, vermute ich mal wg. translucent im Methodennamen. Brauchst Du
das Durchscheinen denn?
>Gäbe es noch eine bessere Möglichkeit, um PNGs zu erzeugen,
>die auch in MSIE gut aussehen?
Mit Transparenz glaube ich nicht, das ist halt ein Bug des IE. Wobei
ich den neuesten IE nicht habe, nur 6.0.
Frank Buss
> Klar kann ich ein Test-PNG bereitstellen:
> http://www.yetac.com/png/
> Der einzige Browser, der das so anzeigt, wie es aussehen
> soll, ist Opera6.
Ich habe mal eins der Bilder in 8 Bit mit Transparenz umgewandelt und das
wird bei IE 6 korrekt angezeigt (links 24 Bit, rechts 8 Bit):
http://www.frank-buss.de/png/index.html
In Opera 6.0 und werden beide Bilder richtig angezeigt. In Netscape 4.78,
den ich hier für Webseiten Härtetests installiert habe, wird das 24 Bit
Bild komplett schwarz angezeigt und das 8 Bit Bild mit weißem Hintergrund.
Aljoscha Rittner
> "Carl Rosenberger" <ca...@db4o.com> wrote:
>
>> Klar kann ich ein Test-PNG bereitstellen:
>> http://www.yetac.com/png/
>> Der einzige Browser, der das so anzeigt, wie es aussehen
>> soll, ist Opera6.
>
> Ich habe mal eins der Bilder in 8 Bit mit Transparenz umgewandelt und das
> wird bei IE 6 korrekt angezeigt (links 24 Bit, rechts 8 Bit):
>
> http://www.frank-buss.de/png/index.html
>
> In Opera 6.0 und werden beide Bilder richtig angezeigt. In Netscape 4.78,
> den ich hier für Webseiten Härtetests installiert habe, wird das 24 Bit
> Bild komplett schwarz angezeigt und das 8 Bit Bild mit weißem Hintergrund.
Mozilla zeigt beide ordentlich an.
Gruß,
Josch.
--
Microsoft broke Volkswagen´s world record: VW only made 22 million bugs!
Carl Rosenberger
> Ich habe mal eins der Bilder in 8 Bit mit Transparenz umgewandelt und das
> wird bei IE 6 korrekt angezeigt (links 24 Bit, rechts 8 Bit):
>
> http://www.frank-buss.de/png/index.html
Bestens!
Danke Frank, dann wäre 8-Bit-PNG wohl das optimale Format.
Jetzt brauch ich nur noch einen Encoder dafür. So wie ich
das sehe, baut der in JDK 1.4 eingebaute Encoder nur 24-Bit
oder kann man das beeinflussen?
> In Opera 6.0 und werden beide Bilder richtig angezeigt. In Netscape 4.78,
> den ich hier für Webseiten Härtetests installiert habe, wird das 24 Bit
> Bild komplett schwarz angezeigt und das 8 Bit Bild mit weißem Hintergrund.
Ich habe hier sogar noch einen Netscape 4.08. :-)
Der ist völlig egal aber wie es auf dem Mac aussieht,
würde mich schon noch interessieren. Sollte gerade
zufällig jemand mitlesen, wäre ein Tip nett.
Interessant wäre der Look von Frank's 8-Bit PNG
http://www.frank-buss.de/png/index.html
und von meiner GIF-Version
http://www.yetac.com/gif/index.html
Viele Grüße,
Carl