.Chef hat folgendes geschrieben:

Ob sich kompressionstechnisch nochwas rauskitzeln lässt in der jetzigen Spezifikation ist schwer zu sagen. Mir ist noch nichts eingefallen.

In dem Bild hier scheint PNG einiges besser abzuschneiden. Das resultierende SRL lässt sich aber mit ZIP reduzieren (ist dann zwar immer noch grösser als PNG...).
Eine statistische Auswertung zeigt, dass die Datei zu 11% aus dem Zeichen #255 besteht, und zu 5% aus dem Zeichen #0. Da könntest du z.B. den Huffmann Algorithmus o.ä. nehmen.

Bzw. eine VLE oder AVLE-Methode (d.h. z.B. Arithmethische Komprimierung). Die bringt im Allgemeinen sogar noch paar Bytes mehr als Huffmann. Weiterhin sollte eine nachgeschaltete LZ78 oder LZW auch noch ein wenig bringen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Dazu kann ich folgendes sagen:

- Bei Screenshots bzw. speziell "Bildern von Windows-Fenstern" schneidet mein Format schlechter ab als die Konkurrenz, was auch die Statistik auf meiner Homepage zeigt.

- Ich verwende bereits Huffman, allerdings nicht global, sondern nur in bestimmten Abschnitten. Die globale Anwendung einer Rohdatenkompression (Stichwort Entropie...) ist außer in Spezialfällen nicht sinnvoll, da die Daten nach der bitweisen SRL-Kompression als Bytes kaum noch logische Folgen beinhalten.

- Wenn noch Kompressionsreserven vorhanden sind, dann wahrscheinlich eher in Spezialabschnitten. Dafür müsste ich herausfinden, wo genau die FFs und 0en stehen, um die dort gezielt zu komprimieren.

Hallo
Also da ich in letzter Zeit bissel Zeit ham =), hab ich mich mal informiert wegen Plug-In.
Beschrieben wird, dass das kein "Hexenwerk" sein soll...
Über Mozilla stand auch was:

Zitat:

Für die Entwicklung eignen sich sowohl das Software Development Kit (SDK) von Mozilla als auch ein älteres von Netscape (siehe „Fundorte im Web“). Wer Mozillas SDK wählt, muss zuerst den gesamten Quelltext übersetzen, da das Kit die notwendigen Konfigurationsinformationen bestimmt. Die Alternative, das SDK von Netscape, stammt zwar aus dem Jahr 1997, unterstützt aber im Prinzip die gleichen Schnittstellen. Das Beispiel bezieht sich auf Letzteres.

Werde mich in die Richtung weiter informieren, da mich das nämlich auch interessiert


Gruß
PhilGo

.Chef hat folgendes geschrieben:

JayK hat folgendes geschrieben: Außerdem ist es im Vergleich zu JPEG verlustfrei (oder sollte ich mich da jetzt etwa irren??? ). Du irrst nicht, es IST verlustfrei.

Es gibt zum einen verlustfreie Kompression, wie sie PNG z.B. liefern sollte, sowie verlustbehaftete Kompression, wozu JPEG 100%ig dazu gehört. Wollte diese grundsätzliche Sache nur mal eben klar stellen

Wie ist's denn eigentlich ATM um das Format bestellt?

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

DerAndy hat folgendes geschrieben:

Es gibt zum einen verlustfreie Kompression, wie sie PNG z.B. liefern sollte, sowie verlustbehaftete Kompression, wozu JPEG 100%ig dazu gehört. Wollte diese grundsätzliche Sache nur mal eben klar stellen

Die Aussage "JPEG = verlustbehaftet" stimmt nicht ganz, denn im JPEG Standard ist auch eine verlustfreie Kompression definiert. Die ist allerdings nicht weit verbreitet und dementsprechend relativ unbekannt.

Vorschlag: vielleicht kannste ja zu Deinem Format noch mehrere Layer hinzufügen à la PSD.

DaRkFiRe hat folgendes geschrieben:

mehrere Layer hinzufügen à la PSD.

Meinst du Ebenen? Das hat PSD aber nicht als einziges.

JayK hat folgendes geschrieben:

DaRkFiRe hat folgendes geschrieben: mehrere Layer hinzufügen à la PSD. Meinst du Ebenen? Das hat PSD aber nicht als einziges.

Layer=Ebenen

Und dass das PSD als einziges Format besitzt, hab ich auch nie behauptet - deswegen "à la"...

Das Format könnte sehr interresant sein um Texturen für Spiele in diesem Format zu Speichern( IMHO )! Ich habe mir den Source noch nicht angeguckt, aber könntest du das Erstellen und öffnen deines Formates nicht als Klasse zur Verfügung stellen. Dann muss ich es mir nur noch in C# übersetzen!

BenBE hat folgendes geschrieben:

Wie ist's denn eigentlich ATM um das Format bestellt?

Dornröschenschlaf. Im Moment habe ich keine Zeit dafür, da ich wegen meiner sportlichen Gegenwart viel im Ausland unterwegs bin und nebenbei an meiner beruflichen Zukunft feile, die beginnt, wenn ich meine Sportkarriere Ende der Saison beenden werde.

Speedmaster hat folgendes geschrieben:

Das Format könnte sehr interresant sein um Texturen für Spiele in diesem Format zu Speichern( IMHO )! Ich habe mir den Source noch nicht angeguckt, aber könntest du das Erstellen und öffnen deines Formates nicht als Klasse zur Verfügung stellen. Dann muss ich es mir nur noch in C# übersetzen!

Schau dir den Source nur erstmal an. Ich habe das Format als eigene Klasse von TBitmap abgeleitet. Das sollte äquivalent auch in C machbar sein.

1) Die wahrscheinlich beste PNG-Kompression bietet zur Zeit das PNGOUT-Plugin von IrfanView. Allerdings braucht es dafür u.U. auch ein paar Minuten!

2) Es gibt auch eine PNG-Variante mit mehreren Bildern: "Multiple Network Graphics" = MNG. Ist übrigens auch das Animations-Hausformat von Jasc Animation Shop 3 - auch enthalten bei PaintShop Pro 7/8/9...

Bitte aber hier keine Diskussionen über andere Formate führen! Danke.

So derart "anders" ist MNG im Vergleich zu PNG aber nicht - in etwa vergleichbar mit Multi-Page-TIFFs, denke ich. Nur eben zu einem anderen Zweck (mehrere Seiten, statt mehrere Ebenen).

Kleine Übersicht: PNG/MNG-Bibliotheken für Delphi
__

Ach so - entschuldige, hätte doch besser den Anfang des Beitrags noch mal lesen sollen. Hab mich ein wenig in der Bedeutung geirrt - ich dachte, hier werden existierende Formate verglichen. War wohl ein Irrtum.

Naja, ich denke mal ich werde das Format wenn dann per Hand einlesen müssen( D.h. ohne Fremdklassen( Für Bilder ) -> mit einem Stream )!

hab mir eben mal den viewer und die erste beispieldatei geladen.
negativ ist mir die lange zeit beim öffnen der beispieldatei aufgefallen. beim speichern würd ich das noch verstehn aber beim öffnen schränkt das doch einiges an einsatzgebieten ein. als grafikformat in spielen ist das so leider nicht zu verwenden
hab mal paar tests mit einem bild(3264x2448) durchgeführt
srl-speichern: 1m36sek (ergebnis 8,004MB)
srl-laden: 27sek

png-speichern: 15sek (ergebnis 8,348MB)
png-laden: 1sec

Bei mir klap das Prog, nur müsste man da noch ein setup Prog dazumachen, das irgendwie einstellt, dass alle .srl dateien mit dem Viewer geöffnet werden, dass man nur noch doppelklick draufmachen muss.
Und die Farbe is nich so berauschen

Also mich überzeugt dieses Grafikformat noch nicht...
Ich hab es mal mit ein paar Bildern getestet

test1.bmp 16 Farben, 246 Byte => test1.srl ?? Farben, 1,26 KB > srl ist Fehlerhaft und ist über 420% größer als das bmp (jpg mit pbrush = 707 Byte)

test2.bmp 24 Bit, 822 Byte => test8.srl 24 Bit, 1,08 KB > srl ist ca. 30% größer als das bmp (jpg mit pbrush = 707 Byte)

test3.bmp 24 Bit, 4,50 MB => test3.srl 24 Bit, 1,68 MB > srl ist ca. 63% kleiner als das bmp (jpg mit pbrush = 374 KB)
!! test3 liegt aus Platzgründen nur als jpg in der zip-Datei !!


Ich sehe den Vorteil dieses Formates nicht so ganz... Die Ladezeit von test3.srl ist extrem lang. Auf einem PIII 1.2 GHz dauert das öffnen z.B. zwischen 14 und 43 Sekunden!

@FriFra: Die ersten zwei Testbilder sind ja nicht gerade repräsentativ, und dafür ist das Format auch nicht gemacht (16 Bit schonmal gar nicht, deshalb der Fehler). Das dritte Bild liegt in der "Zielgruppe", und wie ich hier schon unzählige Male erklärt habe, ist JPG (verlustbehaftet) kein geeignetes Vergleichsformat für SRL (verlustfrei).

@zangelo: Das Konvertierungsprogramm ist weder hundertprozentig ausgereift noch DAU-sicher. Es dient lediglich als Notnagel für die Umwandlung. Ich hatte halt doch mehr Spaß an der Entwicklung des Formates.

Die Geschwindigkeit ist noch ein ungelöstes Problem. Bei der Entwicklung stand die Kompression im Vordergrund. Wer die ultimative Beschleunigungslösung hat, darf sich gern melden. Dafür ist das hier ja Open Source.