Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 16:22

Foren-Übersicht » Programmierung » Allgemein
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 26 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: JPG und Alpha
BeitragVerfasst: Mo Sep 07, 2015 17:00 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Mai 31, 2002 19:41
Beiträge: 1276
Wohnort: Bäretswil (Schweiz)
Programmiersprache: Pascal
Für Texturen ist JPG ein sehr kompaktes Format, verbraucht sehr wenig Speicher auf der HD, nutr leider wird kein Alpha-Kanal unterstützt.
Gut, man könnte dafür PNG nehmen, das komprimiert aber viel schlechter als JPG, da es ohne Verlust komprimiert.

Gibt es ein Format, welches so gut wie JPG komprimiert und Alpha unterstützt ?

_________________
OpenGL


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Mo Sep 07, 2015 17:48 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Ja, JPEG2000 oder JPEG XR.
Besonders JPEG 2000 ist allerdings nicht so schnell zu dekomprimieren.
Ich würde mir eventuell überlegen, den Alpha-Kanal in einer seperaten Datei(zB. PNG oder JPEG) als Graustufen abzulegen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Mo Sep 07, 2015 21:22 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Mai 31, 2002 19:41
Beiträge: 1276
Wohnort: Bäretswil (Schweiz)
Programmiersprache: Pascal
Zitat:
Ich würde mir eventuell überlegen, den Alpha-Kanal in einer seperaten Datei(zB. PNG oder JPEG) als Graustufen abzulegen.

Kann man den JPG auch als Graustufen (8Bit) abspeichern ?

_________________
OpenGL


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Mo Sep 07, 2015 21:32 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2067
Programmiersprache: C++
Bitte schreib doch deine Anforderungen ausführlich hier rein.
Nicht jeder kennt deine Anforderungen von OpenGL ES wo es um kleine Größen und Alpha-Format nicht Standard bei dem DXT-Subset ist.

Und du solltest Texturen für PNG auch verlustbehaftet optimieren können. Dies ist nur ein Extraschritt vor der Komprimierung.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Di Sep 08, 2015 14:04 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Zitat:
Kann man den JPG auch als Graustufen (8Bit) abspeichern ?

Ja, das kann man.

Zitat:
Und du solltest Texturen für PNG auch verlustbehaftet optimieren können. Dies ist nur ein Extraschritt vor der Komprimierung.

Das geht zwar in der Theorie schon, aber in der Praxis kenne ich kein Programm das dies kann und ich glaube auch, dass das Qualität bei gegebenener Dateigröße viel schlechter als bei JPEG ausfallen würde.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Di Sep 08, 2015 17:11 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Nun wenn du gegen eine bestimmte Grafik oder GUI Bibliothek entwickelst dann hast du ja sowieso Vorgaben vom Hersteller und
so gut wie keine andere Wahl. Bei manchen,*hust* Android *hust*, musst aber erst einmal eine richtige Antwort zusammensuchen.

Wenn du aber keine solche Einschränkungen hast dann spricht ja auch nichts dagegen sich schnell ein eigenes Format zu bauen. Das
kannst du beim Build aus einigen richtigen Datein zusammenbauen. Dort kann man dann auch ruhig so eine primitive Geschichte
machen wie RGBA = JPEG (rgb) + ByteArray (a) und das dann noch mal durch zlib. :)

Ansonsten für 3D gibt es ja noch die "nativen" Formate wie DDS und co..


Außerdem kannst du ja sowieso immer noch alles in ein Archiv packen... Dateigröße alleine dürfte also egal sein.

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Di Sep 08, 2015 17:25 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
KTX ;)

P.S. : JPG für Texturen geht mMn überhaupt nicht. Da hat man beim Erzeugen ja keinerlei Einfluss auf die fürs Rendern relevanten Werte. Also z.B. wie Mipmap-Chains erzeugt werden, wie Alpha behandelt wird (Pre-Multiplied), und v.a. kann JPG ja nur 2D, also keine Texturearrays, Cubemaps, etc. Grade auf dem Handy spart man sich z.B. mit einer kompletten Mipchain die man direkt hochladen kann viel Rechenzeit beim Starten einer Anwendung ober beim Streamen von Texturen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Di Sep 08, 2015 17:40 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Mai 31, 2002 19:41
Beiträge: 1276
Wohnort: Bäretswil (Schweiz)
Programmiersprache: Pascal
i0n0s hat geschrieben:
Bitte schreib doch deine Anforderungen ausführlich hier rein.
Nicht jeder kennt deine Anforderungen von OpenGL ES wo es um kleine Größen und Alpha-Format nicht Standard bei dem DXT-Subset ist.

Und du solltest Texturen für PNG auch verlustbehaftet optimieren können. Dies ist nur ein Extraschritt vor der Komprimierung.


Ich habe einen Texturrierten Globus, welcher mit Wolken überzogen ist.
Die Wolken drehen ein bisschen schneller als der Globus, welches eine realistische Darstellung gibt.
Unter WebGL sieht das so aus: http://mathias1000.bplaced.net/VLI/index.html

Die Erd-Oberfläche (JPG) hat ca. 200KB und die Wolken-Textur (PNG) hat ca. 3MB.
Die Auflösung ist bei allen Texturen gleich gross.

_________________
OpenGL


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Di Sep 08, 2015 17:44 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Bei verlustlosen Dateiformaten (wie PNG) kommt es auch darauf an, aus welcher Quelle die Bilddaten kommen, bzw. welche Bearbeitungsschritte sie schon durchlaufen haben. Jedes Mal, wenn man ein Bild in JPG abspeichert kommen neue Artefakte ins Bild - auch wenn man die vielleicht nicht sieht. Die Artefakte sorgen aber dafür, dass sich das Bild erheblich schlechter verlustfrei komprimieren lässt. Ich habe gerade mal einen kleinen Test gemacht:

Original als PNG: 170 kB
Original als JPG: 161 kB
Dieses JPG wiederum in PNG umgewandelt: 530 kB

Wie stark sich das auswirkt, hängt natürlich immer auch von der Art des Bildmaterials ab. Wenn man bei PNG Platzsparen will, kann ich übrigens IrfanView empfehlen. Bisher habe ich kein Programm gesehen, welches PNGs besser komprimiert (was mich wundert, da theoretisch alle Programme libpng + zlib benutzen). Generell gilt natürlich, wie auch schon angesprochen, nicht mehr Farben/Farbkanäle benutzen als nötig und so weiter.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Mi Sep 09, 2015 00:05 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Es kommt echt auf den Anwendungsfall an.
Wenn die API PNG oder JPEG will dann bist du verdammt dazu in der Hölle zu schmorren xD
JPEG und JPEG 2000 sind total katastrophal designed vom Aufbau und man weiß nie ob man gerade ein Bild, Video oder die Bedienungsanleitung vom Toaster(ohne Witz, mein Raspberry Pi hat mir schon ne jpg gegeben wo nur die Video Kamera Einstellungen drin waren) vor sich hat.
Im Format gbit es ein Application Segment, welches kein Längenfeld besitzt und damit darf man erstmal die ganzen Pseudo Formate implementieren, denn für diese segmente gibt es nur eine Regel, ein 0xff muss mit einem 0x00 makiert sein, sonnst wird es als Segmentmarker interpretiert. Zum glück gibt es nur 4-5 verschiedene Varianten und von der Adobe weitere 3-4 Versionen(die haben aber alle nen short für segmentgröße) in der Wildbahn.

Von der Kompressionsstärke ist JPEG2k das beste, vom Stromverbrauch PNG, entpackgeschwindigkeit ist stark von der Lib abhängig aber PNG ist immer hoch im Kurs in einigen Fällen JPEG2k und JPEG ist das Schlusslicht.
PNG ist nicht gut zu parallelisieren, JPEG und JPEG2k schon, JPEG2k kann wesentlich mehr Daten pro Operation entpacken und 2k kann als Integer und Floatingpoint(höhere Quali, schlechtere Kompressionsfaktor) Variante genutzt werden, kommt in diversen Transformationsarten, je nachdem ob man Random Access(unglaublich schnell) oder Progressive laden will.

Wenn du nicht an ein Format gebunden bist, dann empfehle ich Texture Crunch.
Das erzeugt eine DDS DXT1-5 file und tut das Ergebnis dann in JPEG2k Unterformat ähnlichen Algo packen.
Man bekommt nahe JPEG größe, ist wesentlich schneller beim entpacken und liefert ein fertiges natives OpenGL ES format.

Wenn du OpenGL ES solltest zu mal gucken ob du die nativen Kompressionsformate nutzen kannst.
ASTC wäre der beste Kanditat, dann ECT2 und dann PVRTC.
Bei modernerer Hardware vieleicht auch BC7 und 3 in einer zip(sind nicht kleiner aber der PSNR ist um einiges besser als alle anderen compressed GPU Formate).

Ist immer ein Trade-Off Größe vs Qualität.

Frostbite, ID Tech, Unity und UE packen die Texturen in normale lzma2/lz77 Archive und teilweise wird noch die DDS transformiert(geht schnell und spart in eigenen Test ~10-20%) um die kompressionsrate zu erhöhen, bzw. ID Tech erzeugt die DXT Texturen zur Laufzeit für das Terrain(ist ein clipmap basiertes Virtual Texture System, ich vermute Wavelet basiert).
Unity nutzt PVRTC für iOS, ETC2 für Android, DXT3/5 für PC und packt die DDS wie schon gesagt dann in ein lzma2 archieve.
Was UE für Mobile macht weiß ich ned.

Ich bin mir nicht mehr sicher ob es Frostbite war, aber einer der großen hat ein custom Format, was wie Texture Crunch ein fertiges DDS als Input nimmt und dann in ein neues Format transformiert und komprimiert(auch verlustbehaftet). Gab ein GDC Vault Vortrag, leider ohne Slides nur Abo-Video.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Mi Sep 09, 2015 10:05 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
TAK2004 hat geschrieben:
Texture Crunch

Hast du einen Link zu dem Tool? Meinst du das hier auf google code? Das scheint ziemlich outdated zu sein.

viele Grüße,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Mi Sep 09, 2015 11:20 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Lord Horazont hat geschrieben:
TAK2004 hat geschrieben:
Texture Crunch

Hast du einen Link zu dem Tool? Meinst du das hier auf google code? Das scheint ziemlich outdated zu sein.

viele Grüße,
Horazont

Ist richtig, Texture Crunch wird nicht mehr gepflegt. Die Bugs sind behoben und neue Features sind nicht geplant.
Er hatte ziemlich viel trouble mit Patenten und Lizenzen, damit Crunch benutzt werden darf.
Im Mailverteiler hatte er viel drüber geschrieben und auch das er eine nicht öffentliche neue Variante geschrieben hat und prinzipiell es so trivial wäre was eigenes zu basteln, dass er nix neues veröffentlicht hat.

Heute gibt es GPU gegossene DXT Kompression(texconv von MS nutzt die Hardware in DX), sowie MipMap-Chain generierung, es ist also einfacher ein Wavelet basiertes Kompressionsverfahren zu benutzen, was man auf decodierung optimiert und dann die DXT auf der GPU zu erzeugen und bei Harr-Wavelets bekommt man die MipMap Chain kostenfrei mitgeliefert.
Outerra benutzt ein komplexeres Wavelet Konstrukt, wo beim dekodieren die jeweiligen MipMap Level, die schon dekodiert sind in die Textur geupdated werden.
Die GPU rendert immer die Höchste verfügbare Mipmap, man hat dann den Effekt, das es immer detailierter wird.
World of Warcraft Draenor, Doom3, Rage hab ich auch das gleiche beobachtet, die Streamen die MipMap Level von den Worker Threads rein.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Mi Sep 09, 2015 12:47 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Ich kann nicht zustimmen, wie hier über JPEG hergezogen wird. Das Format ist ziemlich schnell und besonders in einer Web-Umgebung wo die Download-Größe entscheidend ist, scheinen mir alle Alternativen ungeeignet.

JPEG kann eigentlich schon ziemlich schnell gehen: http://www.briancbecker.com/blog/2010/analysis-of-jpeg-decoding-speeds/ Auf einem alten Core2 Duo mit der alten Vorgänger von LibJpeg-turbo erreicht er in den relevanten Tests 300 bis 500MB/s. Threading scheint er nicht über mehrere Bilder hinweg zu verwenden. Das ist schon eine Zahl die eine durchschnittliche Festplatte schon nicht erreicht. Das Laden von Komprimierten Daten kann also an einem Desktop PC sogar schneller sein als das Laden von Unkomprimierten. Besonders wenn man sich bewusst werden lässt, dass die Rechenleistung weiter steigen wird während der Speicher kaum schneller vorraussichtliche kaum schneller wird. Selbst heute sollte der Benchmark auch schon besser abschneiden. Neben etwas schnellerer Befehlsauführung sind 4 Threads inzwischen Atandard. Hier hat jemand einen JPEG Dekoder für GPGPU getestet (leider propritär). Selbst auf einer mittelmäßigen Grafikkarte ist das besser als eine Speicherlösung.

Auch PNG ist prinzipiell langsamer als JPEG. Ich konnte leider keinen guten Benchmark zu LibPng finden. Da PNG intern die aber Kompression von zlib und Zip verwendet, kann PNG maximal so schnell wie die zlib/Zip Kompression sein, wo es hier einen Benchmark gibt. Die Rede ist von etwa 175 bis 250 MB/s also langsamer also als JPEG.

JPEG im Sinne von JFIF scheint mir auch ein ziemlich klar definiertes Format zu sein. Der Raspberry Pi hat möglicherweise die Kameradaten als MetaDaten abgelegt. JPEG kann da prinzipiell relativ wenig dafür.

Nur JPEG2000 ist leider kritisch langsam. Einen älteren Benchmark konnte ich hier finden. Man kann zwar auch hier davon ausgehen, dass es inzwischen auch ein wenig schneller geht, aber ~20MB/s für die optimierte Lösung sind nicht gerade schnell und die offene Implementierung ist auch noch doppelt so langsam. Das also in die selbe Schublade wie JPEG zu stecken, finde ich ziemlich falsch.TextureCrunch muss intern eigentlich einen anderen Algorithmus verwenden. Ich kann mir eigentlich nicht vorstellen, wie das im Vergleich zu JPEG2000 sonst so schnell sein kann.

Hier nochmal ein weiterer Vergleich:
http://jacksondunstan.com/articles/2117


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Mi Sep 09, 2015 15:05 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
OpenglerF hat geschrieben:
Ich kann nicht zustimmen, wie hier über JPEG hergezogen wird. Das Format ist ziemlich schnell und besonders in einer Web-Umgebung wo die Download-Größe entscheidend ist, scheinen mir alle Alternativen ungeeignet.

Äpfel und Birnen, Web hat nur die Möglichkeit native die Formate zu nutzen, die vom Browser angeboten werden, weil alles andere läuft auf Javascript basis und das ist natürlich irre lahm.

Mobile hingegen kann ich jedes beliebige Format native einbinden und je nach qualität der Bilbiothek ist sie schneller oder langsamer.

OpenglerF hat geschrieben:
JPEG kann eigentlich schon ziemlich schnell gehen: http://www.briancbecker.com/blog/2010/a ... ng-speeds/ Auf einem alten Core2 Duo mit der alten Vorgänger von LibJpeg-turbo erreicht er in den relevanten Tests 300 bis 500MB/s. Threading scheint er nicht über mehrere Bilder hinweg zu verwenden. Das ist schon eine Zahl die eine durchschnittliche Festplatte schon nicht erreicht. Das Laden von Komprimierten Daten kann also an einem Desktop PC sogar schneller sein als das Laden von Unkomprimierten. Besonders wenn man sich bewusst werden lässt, dass die Rechenleistung weiter steigen wird während der Speicher kaum schneller vorraussichtliche kaum schneller wird. Selbst heute sollte der Benchmark auch schon besser abschneiden. Neben etwas schnellerer Befehlsauführung sind 4 Threads inzwischen Atandard. Hier hat jemand einen JPEG Dekoder für GPGPU getestet (leider propritär). Selbst auf einer mittelmäßigen Grafikkarte ist das besser als eine Speicherlösung.

Natürlich kann JPEG ziemlich schnell sein, ich hatte deswegen auch bewusst geschrieben, dass es implementierungsabhängig unterschiedliche Rangordnungen geben kann.
230-600MB/s dekodiert, also Raw RGB Daten die raus kommen.
Als referenz wurde ein 7MPixel Bild(~3k x 2,4k) genommen und mit verschiedenen Kompressionsraten getestet, je stärker man quantisiert des so schneller das entpacken.
Interessant ist eigentlich genau diese Kennzahl, aus wieviel komprimierten bytes bekomme ich wieviele rawbytes pro sekunde + ladezeit der komprimierten bytes.
In der regel ist 2. länger, wenn man es nicht in einem Virtuellem Archieve liegen hat und je mehr files in ein Ordner liegen des so länger dauert es, selbst bei SSD.
Bei rund 3k files im Ordner explodiert die Zugrifsszeit bei Windows und bei Ext4 ca bei 10k. bei 70k files hab ich auf ner Server HDD schon Zugriffszeiten von 1sekunde gehabt.
Valve hat im Devblog mal über ihr aktuelles Steam Paket Format geredet und die Benchmarks für Dateianzahl, Dateigröße, Dateinamen auf NTFS/EXT3-4 veröffentlicht.
Ich hab nach deren Daten bereits 2 Produktiv genutzte Virtuelle Dateisysteme umgesetzt.
Es ist am Effizientesten ~200MB Files mit sinkender Änderung im Namen und weniger als 3k files pro Ordner zu arbeiten.
Snappy(übrigens eine zlib basierte lib) kann ~500MB/s an gepackten Daten dekodieren also um ein vielfaches schneller als JPEG dekomprimierung.
Wenn ich nun schon eh Archieve habe, die Entpackt werden, machen png,jpeg und jpeg2k eh weniger Sinn, weil doppelt komprimiert und dekomprimiert wird.
Also brauch ich mir eigentlich nur noch gedanken machen, wie ich meine Texturen kompressionsfreudig hin bekomme.

Drakensang Online z.B. nutzt ~5MB Archieve die Kontext bezogen gebündelt werden und das ganze funktioniert native, mit javascript/html und mobile.
Die DDS files sind ~25-30% komprimierbar aber die und ich hatte ein bisschen mit den Datensätzen experimentiert und die DDS Blöcke neu geordnet, damit konnte ich dann spitzen von 50% raus holen.
Swizzeln ist native super schnell, weil es SIMD Operationen für gibt aber für Javascript braucht man dann Browser extensions.

Ich hab auch schon mit OpenCL basierten Dekomprimierung experimentiert und man bekommt tatsächlich total große Werte raus, was sich mit deinem Link deckt aber erwähnt wird nicht, dass das erzeugen des Programmcodes, hochladen auf die GPU, triggern, runter laden bzw. in den OpenGL Context kopieren, DXT bauen und dann in die Textur laden auch zeit kostet und man nicht 100MB Jpeg Bilder hat sondern eher 500kb und dann der OpenCL Kernel ständig unbeschäftigt ist. Noch dazu kommt, dass Single GPU es nicht toll finden OpenGL und OpenCL laufen zu lassen, wie vor kurzem raus kam haben NV Karten sogar ne richtige Allergie dagegen ^^
Praktisch war meine CPU Lösung schneller bei normalen Bildern und bei riesen Datenmengen mit extrem hoher Auflösung wurde die GPU Lösung schneller.
Das Problem ist, man muss dann immer noch mit den Rawdaten hantieren und ich will ja GPU Unterstützte Komprimierte Texturen und nicht Raw RGBA.

Zitat:
JPEG im Sinne von JFIF scheint mir auch ein ziemlich klar definiertes Format zu sein. Der Raspberry Pi hat möglicherweise die Kameradaten als MetaDaten abgelegt. JPEG kann da prinzipiell relativ wenig dafür.

Du hast mich da falsch verstanden, das Format EXIF und JFIF sind klar definiert, nur ziemlich schlecht designed.
Es gibt wie gesagt ein Application und ImageScan Segment, wo die einzige Regel ist 0xff mit 0 zu maskieren damit ein parser weiß, wann das nächste Segment anfängt.
Es gab dann Trolle, die die Reset Segmente im Application Segment nutzen und kein 16Bit Größe schreiben, wie es im ImageScan Segment der Fall ist.
Man kann also alle Segmente bis auf Application mit maximal 4byte lesen und auswerten überspringen, bis auf Application, da darf man byteweise durch schlurfen.

OpenglerF hat geschrieben:
Nur JPEG2000 ist leider kritisch langsam. Einen älteren Benchmark konnte ich hier finden. Man kann zwar auch hier davon ausgehen, dass es inzwischen auch ein wenig schneller geht, aber ~20MB/s für die optimierte Lösung sind nicht gerade schnell und die offene Implementierung ist auch noch doppelt so langsam. Das also in die selbe Schublade wie JPEG zu stecken, finde ich ziemlich falsch.TextureCrunch muss intern eigentlich einen anderen Algorithmus verwenden. Ich kann mir eigentlich nicht vorstellen, wie das im Vergleich zu JPEG2000 sonst so schnell sein kann.

Wie so üblich gibt es die Mathematiker/Programmierer auf der Algorithmus Seite und dann die Trolle die das Format designen.
JPEG2k ist noch schlimmer als JPEG, weil das Format ist kein Container Format sondern ein Format mit unendlich vielen Möglichkeiten und Kombinationen und Animationen.
Mein alter Prof hat mit in der Algorithmus Fraktion gesessen und die Algos sind einfach der Wahnsinn aber die Verpackung ist murks.
Daher benutze ich lieber die Algos und bau mir ne eigene Verpackung.
Wenn man nicht aufpasst, mit welchen Programm man die JPEG2k Bilder exportiert und was man da so rein speichert und welche Algos man verwendet wird das ganze unglaublich langsam beim einlesen aber die Algos sind so gut in der Quantisierung, dass die dekompression wieder einiges gut macht.
Unsere Kameras im Rover benutzen ein auf JPEG2k basierten Kompressionsalgo und damit können wir problemlos 60Hz auf 2k in realtime komprimieren und dekomprimieren, geht auch mit jpeg aber so langsam kann dann jpeg2k nicht sein. Soviel zu Subjektiven Meinungen ^^

Ich bleibe bei der Meinung, dass ich, egal in welcher Umgebung, bei DDS als Format in einem Archieve beiben würde und ob ich davor noch Transformationen mache wie Texture Crunch ist dann Anwendungsspezifisch.
Als Datenformat würde ich zwischen DXT1-5,BC7, PVRTC, ETC2 und ASTC wählen, welches für die jeweilige Textur das beste ist.
Der Grund ist, dass DDS ein so einfachen Dateistruktur hat, alle üblichen Arten von Texturen, wie Cube, 1D, 2D und 3D kann und das lesen schnell von statten geht.
Zum verarbeiten von DDS hab ich früher ein NV Tool benutzt und heute nutzt ich von MS texconv, weil das komplett GPU basiert arbeitet, DDS wie ein Meister beherrscht und schon BC7 kann.
Als Viewer benutze ich Visual Studio 2013.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: JPG und Alpha
BeitragVerfasst: Mi Sep 09, 2015 22:31 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Vorhin hast du geschrieben habe bezog sich vor allen Dingen auf dieser Aussage von dir:
Zitat:
entpackgeschwindigkeit ist stark von der Lib abhängig aber PNG ist immer hoch im Kurs in einigen Fällen JPEG2k und JPEG ist das Schlusslicht.

Ich interpretiere das so:
Entpackgeschwindigkeit PNG > Entpackgeschwindigkeit JPEG2000 > Entpackgeschwindigkeit JPEG

Tatsächlich ist es aber so:
Entpackgeschwindigkeit JPEG > Entpackgeschwindigkeit PNG ≫ Entpackgeschwindigkeit JPEG2000

Es mag sein, dass es anders ist wenn man sich einen JPEG Dekoder mit aktivierter Handbremse aussucht. Allerdings gehe ich mal davon aus, dass das eher vermeidet (auch der Browserhersteller). Und es kann auch sein, dass zum Beispiel Snappy und TextureCrunch eine schöne Alternative mit entfernt verwandten Ideen sein könnten, allerdings haben die mit PNG und JPEG2000 erstmal ziemlich wenig zu tun, weil das so genannte Format nunmal anders definiert ist.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 26 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » Allgemein


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 19 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.074s | 17 Queries | GZIP : On ]