Abo
  1. Foren
  2. Kommentare
  3. Audio/Video
  4. Alle Kommentare zum Artikel
  5. › Displayport über USB-C: Huckepack…

Signalkompression...

  1. Thema

Neues Thema Ansicht wechseln


  1. Signalkompression...

    Autor: ichbinsmalwieder 15.01.15 - 16:50

    Ich freue mich schon auf die dann allgegenwärtigen JPEG/MPEG-Artefakte... Reicht ja noch nicht, dass heutzutage auch Strichgrafiken und Texte als JPEGs geliefert werden...

  2. Re: Signalkompression...

    Autor: robinx999 15.01.15 - 17:35

    Dürfte eine Frage sein wie gut die ist. So etwas nutzen ja schon teilweise Extender, also geräte die ein HDMI Signal per Funk oder über Ethernet übertragen (wobei es bei letzteren auch geräte gibt die ein Cat5e oder besser Kabel verlangen, was dann aber ohne Switches oder ähnliches zwischen Empfänger / Sender gelegt werden muss und nichts komprimieren, aber die sind AFAIK nur bis HDMI 1.2 oder 1.3 tauglich)

    Aber man muss sich natürlich auch gedanken machen was 8K mit 30 oder gar 60 fps für Datenmengen sind wenn es Unkomprimiert übertragen wird, da stößt man wohl schon stark an grenzen

  3. Re: Signalkompression...

    Autor: regiedie1. 15.01.15 - 18:13

    Was versteht ihr an "ohne Qualitätsverluste" nicht? Das wird eine Lossless-Kompression sein.

  4. Re: Signalkompression...

    Autor: robinx999 15.01.15 - 18:18

    Muss sich zeigen ob es wirklich Lossless ist. Damit hat man natürlich die Probleme das man da keine Garantierte Mindestkompression hat. Vorallem da man nicht sehr gut im Vorraus berechnen kann (da man ja möglichst geringe Latenzen will)

    Persönlich würde ich schon mit irgendetwas verlustbehaftetem Rechnen. Wobei bei hohen Bandbreiten auch Verlustbehaftete Kompression für die Mehrheit nicht als solche zu erkennen sein sollte.

  5. Re: Signalkompression...

    Autor: HubertHans 20.01.15 - 11:47

    robinx999 schrieb:
    --------------------------------------------------------------------------------
    > Muss sich zeigen ob es wirklich Lossless ist. Damit hat man natürlich die
    > Probleme das man da keine Garantierte Mindestkompression hat. Vorallem da
    > man nicht sehr gut im Vorraus berechnen kann (da man ja möglichst geringe
    > Latenzen will)
    >
    > Persönlich würde ich schon mit irgendetwas verlustbehaftetem Rechnen. Wobei
    > bei hohen Bandbreiten auch Verlustbehaftete Kompression für die Mehrheit
    > nicht als solche zu erkennen sein sollte.

    Bei 24bit farben und 4K wird bei Lossless garantiert ein Mindestfaktor an Kompression moeglich sein. 8Bit pro Farbe sind sehr eingeschraenkt. Und auch nicht mehr zeitgemaeß, da es bei groeßeren Flaechen und bereits niedrigen Aufloesungen zu Colorbanding fuehrt.

  6. Re: Signalkompression...

    Autor: robinx999 20.01.15 - 14:03

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > robinx999 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Muss sich zeigen ob es wirklich Lossless ist. Damit hat man natürlich
    > die
    > > Probleme das man da keine Garantierte Mindestkompression hat. Vorallem
    > da
    > > man nicht sehr gut im Vorraus berechnen kann (da man ja möglichst
    > geringe
    > > Latenzen will)
    > >
    > > Persönlich würde ich schon mit irgendetwas verlustbehaftetem Rechnen.
    > Wobei
    > > bei hohen Bandbreiten auch Verlustbehaftete Kompression für die Mehrheit
    > > nicht als solche zu erkennen sein sollte.
    >
    > Bei 24bit farben und 4K wird bei Lossless garantiert ein Mindestfaktor an
    > Kompression moeglich sein. 8Bit pro Farbe sind sehr eingeschraenkt. Und
    > auch nicht mehr zeitgemaeß, da es bei groeßeren Flaechen und bereits
    > niedrigen Aufloesungen zu Colorbanding fuehrt.
    Wird nicht teilweise auch 10Bit Pro Farbkanal gefordert bei 4K? aber selbst wenn man das Vernachlässigt so kann man bei Lossless niemals irgendwelche Garantieren abgeben. Es kann ja bei einem Monitor Bild wirklich jeder Pixel eine andere Farbe haben ohne das es eine Korelation zu den Nachbarn gibt. Und so etwas ließe sich nicht mehr Komprimieren und es würde zu fehlern fürhen. Klar in der Praxis wird es selten vorkommen, aber deshalb glaube ich das nur Kompressionen mit Verlsut wirklich möglich sind, dinge wie x264 könnte man Problemlos sagen komprimiere das 4K Bild Statisch mit 1 Gbit/s. und es wird vermutlich gut aussehen (wobei x264 jetzt nur ein Beispiel ist und es aufgrund der Latenz vermutlich auch eine Schlechte wahl wäre)

  7. Re: Signalkompression...

    Autor: HubertHans 23.01.15 - 15:58

    robinx999 schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > robinx999 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Muss sich zeigen ob es wirklich Lossless ist. Damit hat man natürlich
    > > die
    > > > Probleme das man da keine Garantierte Mindestkompression hat. Vorallem
    > > da
    > > > man nicht sehr gut im Vorraus berechnen kann (da man ja möglichst
    > > geringe
    > > > Latenzen will)
    > > >
    > > > Persönlich würde ich schon mit irgendetwas verlustbehaftetem Rechnen.
    > > Wobei
    > > > bei hohen Bandbreiten auch Verlustbehaftete Kompression für die
    > Mehrheit
    > > > nicht als solche zu erkennen sein sollte.
    > >
    > > Bei 24bit farben und 4K wird bei Lossless garantiert ein Mindestfaktor
    > an
    > > Kompression moeglich sein. 8Bit pro Farbe sind sehr eingeschraenkt. Und
    > > auch nicht mehr zeitgemaeß, da es bei groeßeren Flaechen und bereits
    > > niedrigen Aufloesungen zu Colorbanding fuehrt.
    > Wird nicht teilweise auch 10Bit Pro Farbkanal gefordert bei 4K? aber selbst
    > wenn man das Vernachlässigt so kann man bei Lossless niemals irgendwelche
    > Garantieren abgeben. Es kann ja bei einem Monitor Bild wirklich jeder Pixel
    > eine andere Farbe haben ohne das es eine Korelation zu den Nachbarn gibt.
    > Und so etwas ließe sich nicht mehr Komprimieren und es würde zu fehlern
    > fürhen. Klar in der Praxis wird es selten vorkommen, aber deshalb glaube
    > ich das nur Kompressionen mit Verlsut wirklich möglich sind, dinge wie x264
    > könnte man Problemlos sagen komprimiere das 4K Bild Statisch mit 1 Gbit/s.
    > und es wird vermutlich gut aussehen (wobei x264 jetzt nur ein Beispiel ist
    > und es aufgrund der Latenz vermutlich auch eine Schlechte wahl wäre)

    Jeder Bildpunkt ein eigenes Pixel. Wenn ich jetzt mal 4:3 nehme und 4096 x3072 als Aufloesung nehme, werden wir es schwer haben bei 8Bit pro Pixel die 16Mio Farben abzudecken. Denn es sind nur 12,5Mio ungefaehr an einzelnden pixeln verfuegbar. Und bedenke, ich habe bewusst eine extreme Aufloesung mit 4:3 gewaehlt. Wuerden wir 16:9 oder 16:10 nehmen, waere das Bild ne Ecke schmaler und somit weniger Pixel in der Hoehe. Wie du siehst: Sehr viel Luft :) Und es gibt Moeglichkeiten ein Bild zu komprimieren, auch wenn jedes Pixel eine andere Farbe hat.

    10Bit pro Farbkanal schuetzen leider nicht vor Colorbanding.



    1 mal bearbeitet, zuletzt am 23.01.15 16:00 durch HubertHans.

  8. Re: Signalkompression...

    Autor: robinx999 23.01.15 - 20:33

    > Und es gibt Moeglichkeiten ein Bild zu komprimieren, auch
    > wenn jedes Pixel eine andere Farbe hat.
    >
    Aber nicht verlustfrei mit einer Garantierten Kompression, sonst hätte man die Perfekte kompression.
    Ich kann ja jede Datei wenn ich will auch als Bild darstellen.
    mal ein beispiel (hexdumd erste zeile von dd)
    ---
    0000000 457f 464c 0102 0001 0000 0000 0000 0000
    ---
    Nehm ich den ersten Pixel und gebe im den rot wert 45, gelb wert 7f, blau wert 46, dann den zweiten Pixel rot 4c, gelb 01 blau 02 u.s.w.
    wenn ich so etwas mit einer garantierten datenrate looslees komrpimieren könnte dann hätte ich die Perfekte Kompression vor allem könnte ich das Komprimierte wieder als Bild darstellen und wieder komprimieren und irgendwann würde es auf ein paar byte zusammen schrumpfen.

    Und da man halt nicht weiß wie stark das ergebniss einer Kompression ist kann man da meiner meinung nach mit looslees nicht viel machen. Verlustbehaftete Kompression ist kein Problem wenn es die kompression nicht schaft gibt es halt Artefakte was bei einem normalem Bild wohl nicht auffallen dürfte bei verlustloster kompression haben wir dann aber ein Problem, dann wird evtl. nur noch ein teil des bildes gefüllt da der rest nicht mehr rein passt

  9. Re: Signalkompression...

    Autor: HubertHans 24.01.15 - 07:55

    Schon in der Aufstellung, die du mir zeigst, zeigen sich mir Moeglichkeiten, Daten zu komprimieren. Wie gesagt, schon bei 8Bit pro Kanal bekommst du nicht genuegend Pixel auf dem Bildschirm, um alle Farben dar zu stellen. Das naechste ist, das zwar jeder Pixel eine andere Farbe haben koennte, was aber nicht bedeutet das jedes Pixel alle drei Kanäle mit verschiedenen Werten angefeuert wird. Waere das so waeren wir auf 8Bit gesamt beschraenkt. Also mir tun sich hier eigentlich schon recht viele Moeglichkeiten auf, wenn auch primitiv, wie man das Bild komprimieren koennte, ohne Qualitaetsverlust und obendrein je nach Aufloesung und Farbtiefe mit garantierten Minimalwerten. Einen Farbkanal auf 7Bit zu druecken duerfte z.B. kein Problem sein.

  10. Re: Signalkompression...

    Autor: robinx999 24.01.15 - 08:05

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Schon in der Aufstellung, die du mir zeigst, zeigen sich mir
    > Moeglichkeiten, Daten zu komprimieren. Wie gesagt, schon bei 8Bit pro Kanal
    > bekommst du nicht genuegend Pixel auf dem Bildschirm, um alle Farben dar zu
    > stellen. Das naechste ist, das zwar jeder Pixel eine andere Farbe haben
    > koennte, was aber nicht bedeutet das jedes Pixel alle drei Kanäle mit
    > verschiedenen Werten angefeuert wird. Waere das so waeren wir auf 8Bit
    > gesamt beschraenkt. Also mir tun sich hier eigentlich schon recht viele
    > Moeglichkeiten auf, wenn auch primitiv, wie man das Bild komprimieren
    > koennte, ohne Qualitaetsverlust und obendrein je nach Aufloesung und
    > Farbtiefe mit garantierten Minimalwerten. Einen Farbkanal auf 7Bit zu
    > druecken duerfte z.B. kein Problem sein.
    Ob der Bildschirm die Farben auch alle Darstellen kann ist eine Frage, aber wenn ich mit 8 Bit pro Kanal übertrage dann sollte ich auch die vollen 8 Bit übertragen, wer sagt mir denn dass zukünftige Bildschuirme nicht alle Farben sauber darstellen können.
    Und warum wäre bei jeweils unterschiedlichen farbwerten eine Beschränkung auf 8 Bit Insgesamt vorhanden. Bei 8 Bit pro Farbkanal kann jedes Pixel 24 Bit Informationen aufnehmen.
    Das im Durchschnitt vermutlich 50% Kompression möglich sind bezweifle ich nicht, aber es gibt ebenso Bilder die man nicht komprimieren kann und genau da wird man Probleme haben.

    Klar in der Praxis wird man vermutlich extrem selten ein völlig chaotisches Bild darstellen wollen, bei dem jedes Pixel eine komplett andere Farbe hat.
    Aber eine Garantierte Kompression dürfte nur bei Verlustbehafteter Kompression möglich sein. Und wenn ich einen Farbkanal auf 7 Bit statt 8 Bit Reduziere, dann habe ich auf jedenfall einen verlust, ob man ihn wahrnimt kann ist eine andere Frage, aber generell dürfte eine Verlustbehaftete Kodierung bei hoher Bitrate sehr gute ergebnisse liefern.

  11. Re: Signalkompression...

    Autor: HubertHans 26.01.15 - 13:04

    robinx999 schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Schon in der Aufstellung, die du mir zeigst, zeigen sich mir
    > > Moeglichkeiten, Daten zu komprimieren. Wie gesagt, schon bei 8Bit pro
    > Kanal
    > > bekommst du nicht genuegend Pixel auf dem Bildschirm, um alle Farben dar
    > zu
    > > stellen. Das naechste ist, das zwar jeder Pixel eine andere Farbe haben
    > > koennte, was aber nicht bedeutet das jedes Pixel alle drei Kanäle mit
    > > verschiedenen Werten angefeuert wird. Waere das so waeren wir auf 8Bit
    > > gesamt beschraenkt. Also mir tun sich hier eigentlich schon recht viele
    > > Moeglichkeiten auf, wenn auch primitiv, wie man das Bild komprimieren
    > > koennte, ohne Qualitaetsverlust und obendrein je nach Aufloesung und
    > > Farbtiefe mit garantierten Minimalwerten. Einen Farbkanal auf 7Bit zu
    > > druecken duerfte z.B. kein Problem sein.
    > Ob der Bildschirm die Farben auch alle Darstellen kann ist eine Frage, aber
    > wenn ich mit 8 Bit pro Kanal übertrage dann sollte ich auch die vollen 8
    > Bit übertragen, wer sagt mir denn dass zukünftige Bildschuirme nicht alle
    > Farben sauber darstellen können.
    > Und warum wäre bei jeweils unterschiedlichen farbwerten eine Beschränkung
    > auf 8 Bit Insgesamt vorhanden. Bei 8 Bit pro Farbkanal kann jedes Pixel 24
    > Bit Informationen aufnehmen.
    > Das im Durchschnitt vermutlich 50% Kompression möglich sind bezweifle ich
    > nicht, aber es gibt ebenso Bilder die man nicht komprimieren kann und genau
    > da wird man Probleme haben.
    >
    > Klar in der Praxis wird man vermutlich extrem selten ein völlig chaotisches
    > Bild darstellen wollen, bei dem jedes Pixel eine komplett andere Farbe
    > hat.
    > Aber eine Garantierte Kompression dürfte nur bei Verlustbehafteter
    > Kompression möglich sein. Und wenn ich einen Farbkanal auf 7 Bit statt 8
    > Bit Reduziere, dann habe ich auf jedenfall einen verlust, ob man ihn
    > wahrnimt kann ist eine andere Frage, aber generell dürfte eine
    > Verlustbehaftete Kodierung bei hoher Bitrate sehr gute ergebnisse liefern.

    Du hast es nicht verstanden: Selbst bei extremen 4K Aufloesungen sinds immer noch zu wenig Pixel, um alle Farben darstellen zu koennen, die eine 24Bit - Uebertragung bieten koennte. Was im Umkehrschluss bedeutet, das es nicht notwendig ist, 24Bit zu uebertragen. Weißt du was Paletten sind? Spaetestens wenn man gut moegliche 14Bit pro Farbkanal haben moechte (Weil sonst Farbverlaeufe nur mit Colorbanding darstellbar sind) kann man die unbenoetigte Anzahl an Informationen einfach weglassen. Bei 14Bit pro Kanal tun sich sogar Welten auf bezueglich der Kompression. Bei 8Bit und 4096x3072 haben wir ja gerade mal 12,5Mio pixel fuer maximal 16Mio Farben. Bei 10 Bit >> 14Bit wird der Abstand ja noch groeßer. Und ich habe zudem ein 4:3 Format genommen, Wie schon gesagt, ist bei einem 16:9 Geraet und 4K Horizontal noch mal wesentlich weniger an Pixeln vorhanden. Und das laesst sich auf jeden Fall wegkomprimieren, ohne Qualitaetsverlust.

    Beschaeftige dich doch mal mit Datenkompression allgemein. Dann wuerdest du verstehen, wovon ich rede



    1 mal bearbeitet, zuletzt am 26.01.15 13:06 durch HubertHans.

  12. Re: Signalkompression...

    Autor: robinx999 26.01.15 - 14:05

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > robinx999 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > HubertHans schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Schon in der Aufstellung, die du mir zeigst, zeigen sich mir
    > > > Moeglichkeiten, Daten zu komprimieren. Wie gesagt, schon bei 8Bit pro
    > > Kanal
    > > > bekommst du nicht genuegend Pixel auf dem Bildschirm, um alle Farben
    > dar
    > > zu
    > > > stellen. Das naechste ist, das zwar jeder Pixel eine andere Farbe
    > haben
    > > > koennte, was aber nicht bedeutet das jedes Pixel alle drei Kanäle mit
    > > > verschiedenen Werten angefeuert wird. Waere das so waeren wir auf 8Bit
    > > > gesamt beschraenkt. Also mir tun sich hier eigentlich schon recht
    > viele
    > > > Moeglichkeiten auf, wenn auch primitiv, wie man das Bild komprimieren
    > > > koennte, ohne Qualitaetsverlust und obendrein je nach Aufloesung und
    > > > Farbtiefe mit garantierten Minimalwerten. Einen Farbkanal auf 7Bit zu
    > > > druecken duerfte z.B. kein Problem sein.
    > > Ob der Bildschirm die Farben auch alle Darstellen kann ist eine Frage,
    > aber
    > > wenn ich mit 8 Bit pro Kanal übertrage dann sollte ich auch die vollen 8
    > > Bit übertragen, wer sagt mir denn dass zukünftige Bildschuirme nicht
    > alle
    > > Farben sauber darstellen können.
    > > Und warum wäre bei jeweils unterschiedlichen farbwerten eine
    > Beschränkung
    > > auf 8 Bit Insgesamt vorhanden. Bei 8 Bit pro Farbkanal kann jedes Pixel
    > 24
    > > Bit Informationen aufnehmen.
    > > Das im Durchschnitt vermutlich 50% Kompression möglich sind bezweifle
    > ich
    > > nicht, aber es gibt ebenso Bilder die man nicht komprimieren kann und
    > genau
    > > da wird man Probleme haben.
    > >
    > > Klar in der Praxis wird man vermutlich extrem selten ein völlig
    > chaotisches
    > > Bild darstellen wollen, bei dem jedes Pixel eine komplett andere Farbe
    > > hat.
    > > Aber eine Garantierte Kompression dürfte nur bei Verlustbehafteter
    > > Kompression möglich sein. Und wenn ich einen Farbkanal auf 7 Bit statt 8
    > > Bit Reduziere, dann habe ich auf jedenfall einen verlust, ob man ihn
    > > wahrnimt kann ist eine andere Frage, aber generell dürfte eine
    > > Verlustbehaftete Kodierung bei hoher Bitrate sehr gute ergebnisse
    > liefern.
    >
    > Du hast es nicht verstanden: Selbst bei extremen 4K Aufloesungen sinds
    > immer noch zu wenig Pixel, um alle Farben darstellen zu koennen, die eine
    > 24Bit - Uebertragung bieten koennte. Was im Umkehrschluss bedeutet, das es
    > nicht notwendig ist, 24Bit zu uebertragen. Weißt du was Paletten sind?
    > Spaetestens wenn man gut moegliche 14Bit pro Farbkanal haben moechte (Weil
    > sonst Farbverlaeufe nur mit Colorbanding darstellbar sind) kann man die
    > unbenoetigte Anzahl an Informationen einfach weglassen. Bei 14Bit pro Kanal
    > tun sich sogar Welten auf bezueglich der Kompression. Bei 8Bit und
    > 4096x3072 haben wir ja gerade mal 12,5Mio pixel fuer maximal 16Mio Farben.
    > Bei 10 Bit >> 14Bit wird der Abstand ja noch groeßer. Und ich habe zudem
    > ein 4:3 Format genommen, Wie schon gesagt, ist bei einem 16:9 Geraet und 4K
    > Horizontal noch mal wesentlich weniger an Pixeln vorhanden. Und das laesst
    > sich auf jeden Fall wegkomprimieren, ohne Qualitaetsverlust.
    >
    > Beschaeftige dich doch mal mit Datenkompression allgemein. Dann wuerdest du
    > verstehen, wovon ich rede

    Eine Palette Bringt mich doch erst weiter wenn ich mehr Pixel wie Farben habe und hier ist es genau umgedreht. Grundsätzlich könnte man damit schon sparen. Aber gehen wir mal vom Extremfall aus den ein System ja darstellen können muss.
    Wenn ich 12,5 Mio Pixel habe die alle eine Unterschiedliche Farbe haben, dann muss ich die Farbwerte doch irgendwo speichern. Eine Palette würde nur vorteile bringen wenn ich weniger farben habe. z.B.: Die klassischen 256Farben Bilder da kann ich los gehen jede Farbe Definieren (256 * 3 * 8 Bit) und dann brauche ich für jeden Pixel nur noch 1 Byte, da ich auf die Palette verweise. Aber was mache ich denn wenn ich 12,5 Mio Pixel habe die alle eine Unterschiedliche Farbe habe, dann müßte ich erst eine Palette aufbauen (12,5 Mio * 3 * 8 Bit) da 12,5 Mio eine Große Palette ist bräuchte damit für Jedes Pixel 24 Bit (2^23 ist nur etwas über 8Mio) um die Position in der Palette zu kennzeichnen, da hätte ich die Bildgröße Glatt verdoppelt. Und bei höherere Farbtiefe ändert sich da auch nicht ich bräuchte immer noch eine Palette die so groß ist wie die Pixel Anzahl, ich müßte die Palette auch jedesmal neu übertragen da im nächsten Bild ja wieder Farben vorkommen können die im vorherigen nicht vorhanden waren.

    Also wie du mit Paletten weiter kommen wilst wenn jeder Pixel Prinzip bedingt eine eigene Farbe haben kann verstehe ich überhaupt nicht. http://en.wikipedia.org/wiki/Indexed_color#Disadvantages

    ---
    It's provably impossible to create an algorithm that can losslessly compress any data.[7] While there have been many claims through the years of companies achieving "perfect compression" where an arbitrary number N of random bits can always be compressed to N − 1 bits, these kinds of claims can be safely discarded without even looking at any further details regarding the purported compression scheme. Such an algorithm contradicts fundamental laws of mathematics because, if it existed, it could be applied repeatedly to losslessly reduce any file to length 0. Allegedly "perfect" compression algorithms are often derisively referred to as "magic" compression algorithms for this reason.
    ---
    http://en.wikipedia.org/wiki/Lossless_compression#Limitations
    Ja mir ist klar du beziehst dich auf Bilder aber Technisch gesehn kann ich jede Datenmenge als Bild Darstellen, bzw. eine Folge von Bildern (mit Padding). Ich kann jedes Byte nach einander auf die Pixel verteilen (beispiel bei 8 bit pro farbe)
    1 Byte der Datei Rot Wert Pixel 1
    2 Byte der DateiGrün Wert Pixel 1
    3 Byte der Datei Blau Wert Pixel 1
    4 Byte der Datei Rot Wert Pixel 2 u.s.w.
    Das wäre ein Legales Bild (zwar vermutlich kein schön anzusehendes, aber es spricht nichts dagegen so etwas zu machen). Nur das läßt sich leider nicht mehr verlustfrei komprimieren. (wenn das Ausgangsmaterial z.B.: eine Binär Datei oder schon eine Komprimierte datei war, die sich nicht mehr vernünftig komprimieren läßt)

  13. Re: Signalkompression...

    Autor: HubertHans 27.01.15 - 08:47

    robinx999 schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > robinx999 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > HubertHans schrieb:
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > > -----
    > > > > Schon in der Aufstellung, die du mir zeigst, zeigen sich mir
    > > > > Moeglichkeiten, Daten zu komprimieren. Wie gesagt, schon bei 8Bit
    > pro
    > > > Kanal
    > > > > bekommst du nicht genuegend Pixel auf dem Bildschirm, um alle Farben
    > > dar
    > > > zu
    > > > > stellen. Das naechste ist, das zwar jeder Pixel eine andere Farbe
    > > haben
    > > > > koennte, was aber nicht bedeutet das jedes Pixel alle drei Kanäle
    > mit
    > > > > verschiedenen Werten angefeuert wird. Waere das so waeren wir auf
    > 8Bit
    > > > > gesamt beschraenkt. Also mir tun sich hier eigentlich schon recht
    > > viele
    > > > > Moeglichkeiten auf, wenn auch primitiv, wie man das Bild
    > komprimieren
    > > > > koennte, ohne Qualitaetsverlust und obendrein je nach Aufloesung und
    > > > > Farbtiefe mit garantierten Minimalwerten. Einen Farbkanal auf 7Bit
    > zu
    > > > > druecken duerfte z.B. kein Problem sein.
    > > > Ob der Bildschirm die Farben auch alle Darstellen kann ist eine Frage,
    > > aber
    > > > wenn ich mit 8 Bit pro Kanal übertrage dann sollte ich auch die vollen
    > 8
    > > > Bit übertragen, wer sagt mir denn dass zukünftige Bildschuirme nicht
    > > alle
    > > > Farben sauber darstellen können.
    > > > Und warum wäre bei jeweils unterschiedlichen farbwerten eine
    > > Beschränkung
    > > > auf 8 Bit Insgesamt vorhanden. Bei 8 Bit pro Farbkanal kann jedes
    > Pixel
    > > 24
    > > > Bit Informationen aufnehmen.
    > > > Das im Durchschnitt vermutlich 50% Kompression möglich sind bezweifle
    > > ich
    > > > nicht, aber es gibt ebenso Bilder die man nicht komprimieren kann und
    > > genau
    > > > da wird man Probleme haben.
    > > >
    > > > Klar in der Praxis wird man vermutlich extrem selten ein völlig
    > > chaotisches
    > > > Bild darstellen wollen, bei dem jedes Pixel eine komplett andere Farbe
    > > > hat.
    > > > Aber eine Garantierte Kompression dürfte nur bei Verlustbehafteter
    > > > Kompression möglich sein. Und wenn ich einen Farbkanal auf 7 Bit statt
    > 8
    > > > Bit Reduziere, dann habe ich auf jedenfall einen verlust, ob man ihn
    > > > wahrnimt kann ist eine andere Frage, aber generell dürfte eine
    > > > Verlustbehaftete Kodierung bei hoher Bitrate sehr gute ergebnisse
    > > liefern.
    > >
    > > Du hast es nicht verstanden: Selbst bei extremen 4K Aufloesungen sinds
    > > immer noch zu wenig Pixel, um alle Farben darstellen zu koennen, die
    > eine
    > > 24Bit - Uebertragung bieten koennte. Was im Umkehrschluss bedeutet, das
    > es
    > > nicht notwendig ist, 24Bit zu uebertragen. Weißt du was Paletten sind?
    > > Spaetestens wenn man gut moegliche 14Bit pro Farbkanal haben moechte
    > (Weil
    > > sonst Farbverlaeufe nur mit Colorbanding darstellbar sind) kann man die
    > > unbenoetigte Anzahl an Informationen einfach weglassen. Bei 14Bit pro
    > Kanal
    > > tun sich sogar Welten auf bezueglich der Kompression. Bei 8Bit und
    > > 4096x3072 haben wir ja gerade mal 12,5Mio pixel fuer maximal 16Mio
    > Farben.
    > > Bei 10 Bit >> 14Bit wird der Abstand ja noch groeßer. Und ich habe zudem
    > > ein 4:3 Format genommen, Wie schon gesagt, ist bei einem 16:9 Geraet und
    > 4K
    > > Horizontal noch mal wesentlich weniger an Pixeln vorhanden. Und das
    > laesst
    > > sich auf jeden Fall wegkomprimieren, ohne Qualitaetsverlust.
    > >
    > > Beschaeftige dich doch mal mit Datenkompression allgemein. Dann wuerdest
    > du
    > > verstehen, wovon ich rede
    >
    > Eine Palette Bringt mich doch erst weiter wenn ich mehr Pixel wie Farben
    > habe und hier ist es genau umgedreht. Grundsätzlich könnte man damit schon
    > sparen. Aber gehen wir mal vom Extremfall aus den ein System ja darstellen
    > können muss.
    > Wenn ich 12,5 Mio Pixel habe die alle eine Unterschiedliche Farbe haben,
    > dann muss ich die Farbwerte doch irgendwo speichern. Eine Palette würde nur
    > vorteile bringen wenn ich weniger farben habe. z.B.: Die klassischen
    > 256Farben Bilder da kann ich los gehen jede Farbe Definieren (256 * 3 * 8
    > Bit) und dann brauche ich für jeden Pixel nur noch 1 Byte, da ich auf die
    > Palette verweise. Aber was mache ich denn wenn ich 12,5 Mio Pixel habe die
    > alle eine Unterschiedliche Farbe habe, dann müßte ich erst eine Palette
    > aufbauen (12,5 Mio * 3 * 8 Bit) da 12,5 Mio eine Große Palette ist bräuchte
    > damit für Jedes Pixel 24 Bit (2^23 ist nur etwas über 8Mio) um die Position
    > in der Palette zu kennzeichnen, da hätte ich die Bildgröße Glatt
    > verdoppelt. Und bei höherere Farbtiefe ändert sich da auch nicht ich
    > bräuchte immer noch eine Palette die so groß ist wie die Pixel Anzahl, ich
    > müßte die Palette auch jedesmal neu übertragen da im nächsten Bild ja
    > wieder Farben vorkommen können die im vorherigen nicht vorhanden waren.
    >
    > Also wie du mit Paletten weiter kommen wilst wenn jeder Pixel Prinzip
    > bedingt eine eigene Farbe haben kann verstehe ich überhaupt nicht.
    > en.wikipedia.org#Disadvantages
    >
    > ---
    > It's provably impossible to create an algorithm that can losslessly
    > compress any data.[7] While there have been many claims through the years
    > of companies achieving "perfect compression" where an arbitrary number N of
    > random bits can always be compressed to N − 1 bits, these kinds of
    > claims can be safely discarded without even looking at any further details
    > regarding the purported compression scheme. Such an algorithm contradicts
    > fundamental laws of mathematics because, if it existed, it could be applied
    > repeatedly to losslessly reduce any file to length 0. Allegedly "perfect"
    > compression algorithms are often derisively referred to as "magic"
    > compression algorithms for this reason.
    > ---
    > en.wikipedia.org#Limitations
    > Ja mir ist klar du beziehst dich auf Bilder aber Technisch gesehn kann ich
    > jede Datenmenge als Bild Darstellen, bzw. eine Folge von Bildern (mit
    > Padding). Ich kann jedes Byte nach einander auf die Pixel verteilen
    > (beispiel bei 8 bit pro farbe)
    > 1 Byte der Datei Rot Wert Pixel 1
    > 2 Byte der DateiGrün Wert Pixel 1
    > 3 Byte der Datei Blau Wert Pixel 1
    > 4 Byte der Datei Rot Wert Pixel 2 u.s.w.
    > Das wäre ein Legales Bild (zwar vermutlich kein schön anzusehendes, aber es
    > spricht nichts dagegen so etwas zu machen). Nur das läßt sich leider nicht
    > mehr verlustfrei komprimieren. (wenn das Ausgangsmaterial z.B.: eine Binär
    > Datei oder schon eine Komprimierte datei war, die sich nicht mehr
    > vernünftig komprimieren läßt)

    Eine Palette funktioniert auch umgekehrt. Du verstehst es leider nicht. Und rumspammen nervt.

  14. Re: Signalkompression...

    Autor: robinx999 27.01.15 - 09:28

    >
    > Eine Palette funktioniert auch umgekehrt. Du verstehst es leider nicht. Und
    > rumspammen nervt.


    Also möglichweise bin ich ja blöd oder du erklärst es nur schlecht.
    Ich kenne Paletten nur als Indexed Colors http://en.wikipedia.org/wiki/Indexed_color
    Man hat eine Gewisse anzahl von farben in einer Tabelle (typischerweise 256) man speichert einmal die RGP Werte für jede der Farben und muss dann für jedes Pixel nur noch die Position in der Tabelle speichern. Sehr effizient mit Bildern mit wenig Farben (z.B.: Diagramme)
    Nur wie genau funktioniert eine Umgekehrte Palette ich wäre für eine erklärung bzw. einen Link dankbar.

  15. Re: Signalkompression...

    Autor: HubertHans 03.02.15 - 11:21

    eben. du uebertraegst eine Farbpalette zum Monitor. Du kannst eh nicht alle Farben gleichzeitig darstellen. Fertig.

  16. Re: Signalkompression...

    Autor: robinx999 03.02.15 - 11:37

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > eben. du uebertraegst eine Farbpalette zum Monitor. Du kannst eh nicht alle
    > Farben gleichzeitig darstellen. Fertig.
    Aber wie oft soll ich die Farbpalette denn neu übertragen? Bei jedem Bild, dann bringt es keine Vorteile. Da die Datenmenge nicht kleiner wird. Und da ich zukünftige Bilder nicht kenne kann ich die Palette nicht im Vorraus übertragen, da man nicht weiß welche Farben benötigt werden. Und rein theoretisch können bei 10 Bit Farbtiefe sogar alle Pixel innerhalb einer Sekunde komplett unterschiedliche Farben haben.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. DMG MORI Global Service Milling GmbH, Pfronten, Seebach
  2. symmedia GmbH, Bielefeld
  3. ilum:e informatik ag, Mainz, Frankfurt am Main, Berlin, München, Köln, Hamburg, Leipzig, Düsseldorf, Stuttgart, Home-Office
  4. Lidl Dienstleistung GmbH & Co. KG, Neckarsulm

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 99,90€
  2. für 229,99€ vorbestellbar
  3. 169,90€ + Versand
  4. 58,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


P30 Pro im Kameratest: Huawei baut die vielseitigste Smartphone-Kamera
P30 Pro im Kameratest
Huawei baut die vielseitigste Smartphone-Kamera

Huawei will mit dem P30 Pro seinen Vorsprung vor den Smartphone-Kameras der Konkurrenez ausbauen - und schafft es mit einigen grundlegenden Veränderungen.
Ein Test von Tobias Költzsch

  1. CIA-Vorwürfe Huawei soll von chinesischer Regierung finanziert werden
  2. Huawei-Gründer "Warte auf Medikament von Google gegen Sterblichkeit"
  3. 5G-Ausbau Sicherheitskriterien führen nicht zu Ausschluss von Huawei

Anno 1800 im Test: Super aufgebaut
Anno 1800 im Test
Super aufgebaut

Ach, ist das schön: In Anno 1800 sind wir endlich wieder in einer heimelig-historischen Welt unterwegs - zumindest anfangs. Das neue Werk von Blue Byte fesselt dank des toll umgesetzten und unverwüstlichen Spielprinzips. Auch neue Elemente wie die Klassengesellschaft funktionieren.
Von Peter Steinlechner

  1. Ubisoft Blue Byte Anno 1800 erhält Koop-Modus und mehr Statistiken
  2. Ubisoft Blue Byte Preload der offenen Beta von Anno 1800 eröffnet
  3. Systemanforderungen Anno 1800 braucht schnelle CPU

Elektromobilität: Was hat ein Kanu mit Autos zu tun?
Elektromobilität
Was hat ein Kanu mit Autos zu tun?

Veteranen der deutschen Autoindustrie wollen mit Canoo den Fahrzeugbau und den Vertrieb revolutionieren. Zunächst scheitern die großen Köpfe aber an den kleinen Hürden der Startupwelt.
Ein Bericht von Dirk Kunde

  1. EU Unfall-Fahrtenschreiber in Autos ab 2022 Pflicht
  2. Verkehrssenatorin Fahrverbot für Autos in Berlin gefordert
  3. Ventomobil Mit dem Windrad auf Rekordjagd

  1. Trotz US-Kampagne: Huawei steigert weiter Umsatz und Gewinnmarge
    Trotz US-Kampagne
    Huawei steigert weiter Umsatz und Gewinnmarge

    Gewinn und Umsatz wachsen bei Huawei weiter. Für das Jahr 2019 erwartet der Konzern hohe Gewinne durch 5G-Technologie. 70.000 5G-Basisstationen sind nun ausgeliefert.

  2. 5G: Swisscom refarmt UMTS-Frequenz bei 2.100 MHz
    5G
    Swisscom refarmt UMTS-Frequenz bei 2.100 MHz

    UMTS bei 2.100 MHz kann man in der Schweiz bald nicht mehr nutzen. Der Bereich geht per Refarming an effizientere 4G- und 5G-Technologien.

  3. Copyright: Nintendo hat offenbar Super Mario Bros für C64 gestoppt
    Copyright
    Nintendo hat offenbar Super Mario Bros für C64 gestoppt

    Sieben Jahre hat ein Programmierer nach eigenen Angaben an einer Umsetzung von Super Mario Bros für den C64 gearbeitet. Wenige Tage nach der Veröffentlichung verschwindet das Spiel nun schon wieder von größeren Portalen - vermutlich wegen Nintendo.


  1. 19:00

  2. 17:41

  3. 16:20

  4. 16:05

  5. 16:00

  6. 15:50

  7. 15:43

  8. 15:00