Autor |
Beitrag |
delfiphan
Beiträge: 2684
Erhaltene Danke: 32
|
Verfasst: Mi 23.03.05 01:54
.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.
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Mi 23.03.05 02:22
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.
|
|
.Chef
Beiträge: 1112
|
Verfasst: Mi 23.03.05 09:34
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.
_________________ Die Antworten auf die 5 häufigsten Fragen:
1. Copy(), Pos(), Length() --- 2. DoubleBuffered:=True; --- 3. Application.ProcessMessages bzw. TThread --- 4. ShellExecute() --- 5. Keine Vergleiche von Real-Typen mit "="!
|
|
PhilGo
Beiträge: 315
Win 98, Win Longhorn ;-)
|
Verfasst: Mi 23.03.05 10:24
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
_________________ Sie werden dich finden und töten... Söhne der großen Bärin!
|
|
DerAndy
Hält's aus hier
Beiträge: 14
WinXP, Linux (Debian Sarge)
D5 Pro, D6 Pers, D7 Ent, D2005 Pers, Free-Pascal+Lazarus
|
Verfasst: Do 28.07.05 20:51
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Fr 29.07.05 17:44
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.
|
|
SMO
Beiträge: 120
Erhaltene Danke: 18
D2005 Personal
|
Verfasst: Fr 29.07.05 18:17
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.
|
|
DaRkFiRe
Beiträge: 526
WinXP Home & Professional
C, C++, Delphi
|
Verfasst: Fr 29.07.05 18:37
Vorschlag: vielleicht kannste ja zu Deinem Format noch mehrere Layer hinzufügen à la PSD.
_________________ Lang ist der Weg durch Lehren - kurz und wirksam durch Beispiele! Seneca
|
|
JayK
Beiträge: 1013
|
Verfasst: Fr 29.07.05 19:24
DaRkFiRe hat folgendes geschrieben: | mehrere Layer hinzufügen à la PSD. |
Meinst du Ebenen? Das hat PSD aber nicht als einziges.
|
|
DaRkFiRe
Beiträge: 526
WinXP Home & Professional
C, C++, Delphi
|
Verfasst: Sa 30.07.05 04:46
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"...
_________________ Lang ist der Weg durch Lehren - kurz und wirksam durch Beispiele! Seneca
|
|
Speedmaster
Beiträge: 79
Windows XP
C#, VS2005 / VS2008
|
Verfasst: Sa 30.07.05 10:58
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!
|
|
.Chef
Beiträge: 1112
|
Verfasst: Di 09.08.05 10:23
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.
_________________ Die Antworten auf die 5 häufigsten Fragen:
1. Copy(), Pos(), Length() --- 2. DoubleBuffered:=True; --- 3. Application.ProcessMessages bzw. TThread --- 4. ShellExecute() --- 5. Keine Vergleiche von Real-Typen mit "="!
|
|
LigH
Beiträge: 239
Win98SE, Win2000SP4
D7
|
Verfasst: Di 09.08.05 14:15
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...
|
|
.Chef
Beiträge: 1112
|
Verfasst: Di 09.08.05 14:47
Bitte aber hier keine Diskussionen über andere Formate führen! Danke.
_________________ Die Antworten auf die 5 häufigsten Fragen:
1. Copy(), Pos(), Length() --- 2. DoubleBuffered:=True; --- 3. Application.ProcessMessages bzw. TThread --- 4. ShellExecute() --- 5. Keine Vergleiche von Real-Typen mit "="!
|
|
LigH
Beiträge: 239
Win98SE, Win2000SP4
D7
|
Verfasst: Di 09.08.05 15:23
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.
|
|
Speedmaster
Beiträge: 79
Windows XP
C#, VS2005 / VS2008
|
Verfasst: Fr 02.09.05 15:51
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 )!
|
|
Neidhard von Reuental
Beiträge: 268
XP
BDS 2006 Prof
|
Verfasst: Fr 02.09.05 17:10
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
|
|
zangelo
Beiträge: 50
|
Verfasst: Mi 07.09.05 12:06
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
|
|
FriFra
Beiträge: 557
Win XP Prof, Win XP Home,Win Server 2003,Win 98SE,Win 2000,Win NT4,Win 3.11,Suse Linux 7.3 Prof,Suse Linux 8.0 Prof
D2k5 Prof, D7 Prof, D5 Standard, D3 Prof, K3 Prof
|
Verfasst: Do 08.09.05 20:20
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!
Einloggen, um Attachments anzusehen!
_________________ Michael
(principal certified lotus professional - developer)
|
|
.Chef
Beiträge: 1112
|
Verfasst: Do 08.09.05 22:44
@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.
_________________ Die Antworten auf die 5 häufigsten Fragen:
1. Copy(), Pos(), Length() --- 2. DoubleBuffered:=True; --- 3. Application.ProcessMessages bzw. TThread --- 4. ShellExecute() --- 5. Keine Vergleiche von Real-Typen mit "="!
|
|