Entwickler-Ecke :: Thema anzeigen - Das ultimative Grafikformat

.Chef - Sa 02.10.04 10:31
Titel: Das ultimative Grafikformat

Achtung, dieses Thema ist veraltet!

Hallo,

nach zweijähriger Entwicklungsphase (inkl. Langzeitreifung in irgendeiner Schublade) ist mein eigenes Grafikformat spruchreif. Es handelt sich dabei um eine verlustfreie Kompression für 24-Bit- und Graustufenbilder. Die Kompressionsrate liegt im Bereich von PNG und ist in vielen Fällen sogar noch besser.

Download Viewer [http://www.accessviolation.de/srl/srldemo.zip] (Stand-Alone-EXE)

Der Viewer konvertiert SRL-Dateien (so heißt das Format) in BMP-Dateien und umgekehrt. Auf meiner Seite [http://www.accessviolation.de] gibts auch mehr Informationen (detailierter Aufbau, Vergleich mit anderen Formaten, usw.) zum Format selbst. Sourcecode ist noch nicht online, folgt aber demnächst, weshalb ich erstmal hier unter "Freeware" gepostet habe.

Also, ich bin mal gespannt auf eure Meinungen dazu.

Gruß,
Jörg

Edit: Aktuelle Version ist weiter unten [http://www.delphi-forum.de/viewtopic.php?p=182874#182874] zu finden!

Moderiert von tommie-lie: Topic aus Freeware Projekte verschoben am Di 05.10.2004 um 12:19

tommie-lie - Sa 02.10.04 12:01

Bei dem Vergleich zu PNG fehlt mir irgendwie der Hinweis, daß PNG zusätzlich noch Transparenz unterstützt. Oder hast du für die Vergleichs-PNGs den Alpha-Kanal nicht nur nicht benutzt sondern auch deaktiviert (ich weiß nichtmal, ob das möglich ist)?
Oder fehlt einfach nur der Hinweis, daß dein Format auch Transparenz unterstützt? ;-)

.Chef - Sa 02.10.04 12:13

Wenn bei PNGs kein Alphakanal ausgewählt (z.B. im Details-Fenster bei IrfanView) ist, wird auch keiner mit gespeichert. Das ist gleichbedeutend mit "deaktiviert".

Mein Format unterstützt (bis jetzt) keine Transparenz. Ein Alphakanal ist aber eingeplant und durch die Struktur des Formats auch kein großes Problem. Ich will aber erstmal die Testergebnisse (und weitere Fragen, Wünsche, Kritikpunkte, ...) der "Öffentlichkeit" abwarten. ;-)

.Chef - Di 05.10.04 12:02

So, ich habe den kompletten Sourcecode vom Viewer hochgeladen.

Download Source [http://www.accessviolation.de/srl/srlsrc.zip]

Damit wäre das Projekt jetzt unter "Open Source" besser aufgehoben. ;-)

Verbesserungsvorschläge sind immer willkommen, vor allem, was die Geschwindigkeit betrifft.

StefanH - Fr 08.10.04 13:35

.Chef hat folgendes geschrieben:

Ich weiß nicht, was du meinst. :?

ich hab unter Optionen die CheckBox markiert (als Standardanwendung...) wenn ich etz auf eine SRL doppelklicke, öffnet er zwar dein Programm, aber die Datei öffnet er irgendwei nicht :roll:

StefanH - Sa 09.10.04 11:55

.Chef hat folgendes geschrieben:

Bei mir gehts. :nixweiss: Kannst ja mal 'nen Blick in den Source werfen. ;-) Ich arbeite grad am Alphakanal, weshalb es das nächste Update erst gibt, wenn der fertig ist.

hmmm... wenn ich bei Form2.RegisterFileType

Delphi-Quelltext

1:	reg.Writestring('',exepfad+' %1');

durch

Delphi-Quelltext

1:	reg.Writestring('','"'+exepfad+'" "%1"');

ersetz, öffnet er zwar das Bild, aber das Programm hängt sich auf :roll:

StefanH - Sa 09.10.04 17:11

.Chef hat folgendes geschrieben:

Das ist die Strafe Gottes dafür, dass du Windows ME verwendest. :twisted:

Naja, das sind aber Kleinigkeiten, die nichts mit dem Format an sich zu tun haben, welches ja hier im Vordergrund steht.

:x was nützt mir das Format, wenn ich es nicht anzeigen kann? :lol:

.Chef - Di 12.10.04 19:38

So, das Format steht vor seiner Vollendung - der Alphakanal (8 Bit) ist eingebaut.

Download Viewer 1.4 beta [http://www.accessviolation.de/srl/srlview.zip]

Zu Demozwecken gibts auch zwei High-Quality-SRLs mit integriertem Alphakanal dazu:

Bild 1 [http://www.accessviolation.de/srl/ice.srl] (901 KB)
Bild 2 [http://www.accessviolation.de/srl/eule.srl] (906 KB)

Mit dem Viewer können auch Alphakanäle zu normalen Bitmaps hinzugefügt werden. Dazu ein 8-Bit-Graustufenbild in der Größe des Zielbitmaps erstellen und im Programm unter "Alphakanal" laden. Dort kann ein vorhandener Alphakanal auch einfach aktiviert/deaktiviert werden. Die Speicherung als SRL richtet sich dann nach dieser Einstellung.

Edit: PS: Source wie immer in Kürze ...

Moritz M. - Mi 13.10.04 20:46

An sich ja ganz Nett, aber die Geschwindigkeit ist ned so dolle. Er hat ne Minuten gebraucht, um ein 2000x2000px Bild zu laden und 5 um es zu speichern. Da musst du noch was machen.
Ansonsten ganz nett :)

.Chef - Mi 13.10.04 22:56

Moritz M. hat folgendes geschrieben:

Er hat ne Minuten gebraucht, um ein 2000x2000px Bild zu laden und 5 um es zu speichern. Da musst du noch was machen.

Problem ist bekannt und in Arbeit. Neben ständiger Optimierung bin ich auf der Suche nach den häufigsten Filtereinstellung, um eben bei durchschnittlich nur minimal schlechterer Kompression auf wesentlich weniger Bearbeitungszeit zu kommen (vielleicht 5-10 Prozent der jetzigen Zeit). 2000x2000 is aber auch groß ... ;-)

BenBE - Mi 13.10.04 23:05

Naja, Ein JPG mit 2000x2000 macht der PP8 bei mir in knapp zehn Sekunden (Speichern). Öffnen braucht er knapp die Hälfte.

Aber soweit ich den Algo gesehen hab, ist das dort auch klar, dass Optimierungen schwer sind.

.Chef - Di 02.11.04 12:20

So, nun gibts endlich den Source zur neuen Version mit Alphakanal, die zwar immer noch im Betastadium ist, aber schon ein paar Verbesserungen enthält (etwas schneller, etwas bessere Kompression).

Download SRL-Viewer 1.4 beta 2 [http://www.accessviolation.de/srl/srlview.zip]
Download Source [http://www.accessviolation.de/srl/srlsrc.zip]

Dokumentation ist noch nicht dabei, im Moment ist meine Zeit mal wieder etwas knapp bemessen. :eyes:

Big_Berny - Sa 20.11.04 10:40

Hi .chef,
cooles Teil! Ich wollte letztes Jahr auch so ein Programm programmieren für meine Maturarbeit, bin dann aber an meinen mangelnden Delphi-Kenntnissen gescheitert... :(

Falls du dir mal meine schriftliche Arbeit anschauen willst: http://home.pages.at/big_berny/Maturarbeit_final.pdf
Hat ein paar interessante Ansätze drin, die man nur noch programmieren muss!

Gruss
Big_Berny

Andreas L. - So 21.11.04 11:24

Das Format ist klasse. Wäre sehr geeignet fürs Web wegen der kleinen Dateigröße...

Du brauchst nur noch ein Plug-in für IE, Mozilla und Opera schreiben damit diese Browser die Grafik auch anzeigen können. Wie könnte man sowas am besten realisieren?

Bye,
Andy

.Chef - So 21.11.04 12:57

onlinehome hat folgendes geschrieben:

Das Format ist klasse. Wäre sehr geeignet fürs Web wegen der kleinen Dateigröße...

Danke für die Blumen. :-)

onlinehome hat folgendes geschrieben:

Du brauchst nur noch ein Plug-in für IE, Mozilla und Opera schreiben damit diese Browser die Grafik auch anzeigen können. Wie könnte man sowas am besten realisieren?

Ich hab leider keine Ahnung, wie man Browser-Plug-Ins schreibt. Wenn sich allerdings jemand finden würde, könnte man ja eine Zusammenarbeit aufziehen.

Basti - So 21.11.04 22:13

Mit dem Plugin schreiben ist es ja nicht getan - ihr müsstet das Format auch verbreiten,
damit es bekannter wird. Sonst lädt sich keiner das Plugin runter und verwenden tut
es erst recht keiner, wenn es nicht bekannt ist.
Aber sonst schon ziemlich genial.

Andreas L. - Mo 22.11.04 19:52

Basti hat folgendes geschrieben:

Schon klar, aber das ist doch zweitrangig...

JayK - Mo 21.03.05 16:56

Ich hab auch das Problem mit dem Öffnen von Dateien über die Shell-Integration (Doppelklick im Explorer).
Das Programm geht auf, aber das Bild nich. :(

Ansonsten ist das Programm klasse. Vor allem wegen der Komprimiereung. :D

JayK - Mo 21.03.05 17:13

F34r0fTh3D4rk hat folgendes geschrieben:

ne alternative zu jpeg isses noch net

An JPEG kommt es nicht heran, das stimmt, aber besser als PNG isses schon mal.
Außerdem ist es im Vergleich zu JPEG verlustfrei (oder sollte ich mich da jetzt etwa irren??? :o ).

F34r0fTh3D4rk - Mo 21.03.05 17:16

nee da hast du recht, obwohls bei jpg nur bei genauerem hinsehen oder bei weiterverarbeitung auffällt (nervt nämlich).

Bei sw bildern ist es gut, dass man für jeden pixel immer nur 1 bit braucht, was bei sw bmps auch net der fall ist ... :D

delfiphan - Mo 21.03.05 19:00

Cooles Ding! Hut ab!

Vielleicht noch etwas zu langsam für den professionellen Einsatz. Was mir noch aufgefallen ist: Sobald Gradienteneffekte in den Bildern vorkommen, ist PNG besser.
Und: Hab soeben ein srl gezippt und dabei 29% an Grösse gespart. Da lässt sich doch noch mehr rauskitzeln ;)

Sonst tip top :)

Gruss,
Simon

.Chef - Mi 23.03.05 00:27

JayK hat folgendes geschrieben:

Außerdem ist es im Vergleich zu JPEG verlustfrei (oder sollte ich mich da jetzt etwa irren??? :o ).

Du irrst nicht, es IST verlustfrei.

Die ganzen Zipperchen des Tools muss ich bei Gelegenheit mal näher beleuchten. Das Projekt lag ja jetzt 'ne Weile rum. Jaja, die Zeit ... :roll:

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

delfiphan - 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 [http://www.delphi-forum.de/download.php?id=102] 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 - 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.

.Chef - 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.

PhilGo - 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

DerAndy - Do 28.07.05 20:51

.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??? :o ).

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 ;)

SMO - Fr 29.07.05 18:17

DerAndy hat folgendes geschrieben:

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 - 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. :-P

Layer=Ebenen

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

Speedmaster - 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 - 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:

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.

LigH - 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...

LigH - 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 [http://www.pjh2.de/delphi/articles/graphic/png.php?l=de]
__

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. :oops:

Neidhard von Reuental - 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 - 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 - 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!

.Chef - 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). :roll:

@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. ;)

Delete - So 14.02.16 19:46

Dieses Thema ist ja nun schon sehr alt und ich stieß nur zufällig drauf, als ich mal wieder nach Grafikbibliotheken suchte.

Keiner der Download-Links funktioniert noch, so daß ich dieses "ultimative Grafikformat" leider nicht ausprobieren kann.

Gibt es vielleicht eine Möglichkeit, veraltete Themen (sofern sie nur tote Links enthalten) wenigstens entsprechend zu kennzeichnen ? So habe ich erst alle Beiträge gelesen und mich erst dann entschlossen, es mal zu probieren. - Aber "tote Hose" ...

Christian S. - Mo 15.02.16 12:51

delnu hat folgendes geschrieben :

Gibt es vielleicht eine Möglichkeit, veraltete Themen (sofern sie nur tote Links enthalten) wenigstens entsprechend zu kennzeichnen ? So habe ich erst alle Beiträge gelesen und mich erst dann entschlossen, es mal zu probieren. - Aber "tote Hose" ...

Wenn du ein solches Thema findest, kannst du es über die Melden-Funktion ans Team melden, sodass wir uns drum kümmern.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!