8-Bit-Kamerafiles in der Postproduktion

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Ian schrieb:

      Ist nicht die Rechentiefe der Schnittsoftware sowieso immer höher und nur die Ausgabe wird auf 8Bit (oder was eben eingestellt ist) gerundet? Noch in der DV-Zeit schnitt ich mit Mediastudio-Pro und manche Korrekturen rissen völlig aus. Nach dem Umstieg auf Premiere in der damaligen Version war das Ergebnis bei denselben Dateien viel besser.
      Gerechnet wird in Edius (lt. GV) intern mit 32bit float.
      Ergebnisse werden z.B. in HQX als 10 bit gespeichert.
    • Deswegen fällt es ja leichter Banding in den Himmelpartien oder bei Scheinwerferausleuchtungen bei dem Grading
      selbst auf einem 8bit-Monitor zu erkennen und somit zu vermeiden.

      Wie man das Resampling korrekt realisiert hat ja MMM schon in einigen älteren Tutorials gezeigt, auch [MTS]FILMS hat
      das schon gezeigt worauf ich hier schon hingewiesen habe.
      Beste Grüsse;
      FZ-300/RX100ThiEYET5EDGEXperiaZ2eGimbalEDIUS 9.xMedionErazeri76700UHDaufFHD
    • Ian schrieb:

      Ist nicht die Rechentiefe der Schnittsoftware sowieso immer höher und nur die Ausgabe wird auf 8Bit (oder was eben eingestellt ist) gerundet?
      Gerechnet wird in den 64 Bit Versionen in 64 Bit.
      Speicherintern abgelegt lt. GV in 32 Bit Fließkomma.
      Von Filter zu Filter sowie zurück an die Timeline wird in 10 Bit Ganzzahl übergeben.

      Das ist der Punkt, der den Anwender interessiert. Was kommt aus dem einen Filter raus und wird in den nächsten Filter wieder reingegeben.
      Da kappt Edius auf 10 Bit Ganzzahl.

      Bei Adobe kann man es umstellen zwischen 8, 16 und 32 Bit

      Resolve arbeitet da immer in 32 Bit Fließkomma, sodaß also auch bei Datenübergabe von einem Filter zum nächsten kein Datenverlust entsteht - selbst wenn in den Berechnungen "Überweiß" und "Unterschwarz" entsteht.


      Man sieht, es ist von NLE zu NLE unterschiedlich.

      Viele Grüße
      Peter
    • Achilles schrieb:

      Vor 32 Jahren hatte ich einen Sinclair QL Homecomputer,
      die Grafikauflösung war: 256×256 in 8 Farben und 512×256 in 4 Farben

      Ich war damals sehr zufrieden damit. 8)

      Vor 32 Jahren hatte ich einen Commodore C128D, der konnte 320x200 in 16 Farben, lief wahlweise unter CP/M und konnte dadurch in Turbo-Pascal programmiert werden.

      Trotzdem wurde er ein Jahr später durch einen selbstgebauten "IBM-Kompatiblen" mit 80286 + 80287 und einer EGA-Grafikkarte ersetzt, denn der konnte schon 640x350 bei 256 Farben ... das war dann schon toller. :)


      Auch damals hat sich schon gezeigt, dass Auflösung und Farbdarstellung einen rasanten Entwicklungsweg vor sich haben. :)

      Viele Grüße
      Peter
    • PeterC schrieb:

      Man sieht, es ist von NLE zu NLE unterschiedlich

      1. Gerechnet wird in den 64 Bit Versionen in 64 Bit.
      2. Speicherintern abgelegt lt. GV in 32 Bit Fließkomma.
      3. Von Filter zu Filter sowie zurück an die Timeline wird in 10 Bit Ganzzahl übergeben.

      // Was kommt aus dem einen Filter raus und wird in den nächsten Filter wieder reingegeben? Da kappt Edius auf 10 Bit Ganzzahl.

      Bei Adobe kann man es umstellen zwischen 8, 16 und 32 Bit
      Resolve arbeitet da immer in 32 Bit Fließkomma, sodaß also auch bei Datenübergabe von einem Filter zum nächsten kein Datenverlust entsteht - selbst wenn in den Berechnungen "Überweiß" und "Unterschwarz" entsteht.

      // Man sieht, es ist von NLE zu NLE unterschiedlich.


      Danke für die ausführliche Präzisierung!
      // Mein Rechenbeispiel in Post-38 bezog sich auf Punkt 3., weil (Filter zu Filter bzw. Timeline) für den Benutzer relevant.
      Gruß kurt
    • Hi,

      es ist m.E. noch ein klein wenig anders, und Rechentiefe des NLE hat damit jetzt auch nicht so wirklich damit zu tun.


      Wie Kurt ja schon in #38 schreibt, habe ich in einem 10bit-Farbraum 1024 statt der 256 "Möglichkeiten" im 8bit-Farbraum.

      Logisch ist, dass wenn die Kamera echte Farbtiefe von 10bit aufnimmt, ich auch 10bit Farbinformationen (also theoretisch die ganze Farbpalette) erhalte und mit dieser dann arbeiten kann.

      Eine 8bit-Farbtiefe hat nur 256 "Möglichkeiten". Bringe ich nunmehr diese Informationen in einen Raum mit 10bit-Farbtiefe, werden die "Zwischenräume" praktisch mit der gleich Information aufgefüllt (und darauf - denke ich - will Wolfgang hinaus).
      Also in dem Beispiel von Kurt (Punkt 8) wäre dann die Farbinformation von 504 bis 507 zunächst einmal gleich. Erst ab 508 bis 511 gäbe es eine andere "Farbe".
      Belasse ich alles so wie es ist, habe ich also keinerlei Vorteil ob ich eine 8bit-Aufnahme in 8bit oder 10bit betrachte!


      Nehme ich jetzt Veränderungen vor, so fängt es an interessant zu werden.

      Durch das Grading wird die Informationen verschoben - aber natürlich ausgehend vom ursprünglichen Inhalt!!
      Da in unserem oben genannten Bereich 504 bis 507 die Ausgangsinformation (Farb- und Luminazwerte) gleich sind, kommt die Berechnung grundsätzlich auch wieder zum gleichen Ergebnis. Da es eine Berechnungskure ist, könnte durch die "feinere" Rasterung der 10bit-Farbtiefe natürlich an der einen oder anderen Stelle eine andere Rundung zu tragen kommen. Doch dies hat eben nicht mit einer wirklichen "besseren" Farbwiedergabe zu tun, da die Werte ja "künstlich" erzeugt sind und gegenüber den Werten eines echten 10bit-Material abweichen werden.
      Oder um mal bei Kurts Beispiel zu bleiben, müsste die Farbinformation 507 "viel blauer" sein, als aus dem 8bit-Material errechnete.


      Weshalb macht es dann aber Sinn 8bit-Material mit 10bit (oder bei Fotobearbeitung im 16bit) Farbtiefe zu bearbeiten?

      Ganz einfach - durch die Stauchung oder Streckung bei der Bearbeitung gingen mir im 8bit-Farbraum Farben verloren, da ich weiterhin nur eine 265 "breite" Basis habe, die dann nur entsprechend anders gefüllt würde.
      Bei 10bit-Farbtiefe habe ich für meine 8bit Informationen ein breiteres Raster. Dadurch bleibt in den "Zwischenräumen" die ursprüngliche Informationsbreite erhalten.


      Ob sich das dann allerdings auch auf dem Bildschirm wirklich sichtbar auswirkt, ist eine andere Frage.



      Meiner Meinung nach sollte man auch das Grading von 8bit-Material durchaus immer mit 10bit Farbtiefe vornehmen, solange man am Rechner nicht Probleme durch die Datenmenge bekommt. Das sollte aber nicht passieren, wenn der Rechner für seine Aufgaben auch richtig ausgelegt ist. Sonstige Nachteile sehe ich dadurch jedenfalls nicht.


      Aber - und da hat Wolfgang nun mal recht - "echtes" 10bit ist besser.


      Gruß
      Peter
    • gurlt schrieb:

      Aber - und da hat Wolfgang nun mal recht - "echtes" 10bit ist besser.
      Ja natürlich, wie oft muss das aber hier noch bestätigt werden?
      Im Kern ging es doch darum, dass man mit einer überlegten Belichtung der 8bit Materials
      ebenfalls gut anzusehende Videos selbst nach einem Grading schaffen kann, wenn man
      bestimmte Randbedingungen beachtet, auch der Hobbyfilmer kann das.
      Beste Grüsse;
      FZ-300/RX100ThiEYET5EDGEXperiaZ2eGimbalEDIUS 9.xMedionErazeri76700UHDaufFHD
    • Hallo Peter:

      1) "Also in dem Beispiel von Kurt (Punkt 8. wäre dann die Farbinformation von 504 bis 507 zunächst einmal gleich."
      2) "Bei 10bit-Farbtiefe habe ich für meine 8bit Informationen ein breiteres Raster. Dadurch bleibt in den "Zwischenräumen" die ursprüngliche Informationsbreite erhalten."


      Das ist eine interessante Frage, die ich so sehe:
      a) Ein Farbkanal speichert (binär) einen Wert, der den Helligkeitsanteil des entsprechenden Kanals definiert.

      b) Wenn ein Pixel im blauen (8bit-) Kanal den (binären) Wert 127 enthält und nach 10 bit umgerechnet/umgewandelt wird, ergibt sich IMO bloß ein neuer Wert, der (binäre) Wert 508 für den blauen 10bit-Kanal. Für dieses spezielle Pixel kann es keine "Zwischenräume" geben. Mehr als einen binären Wert (zu einem bestimmten Zeitpunkt) für einen 10bit-Kanal gibt es nicht. Genau so, wie es für einen 8bit-Kanal auch nur einen binären Wert (zu einem bestimmten Zeitpunkt) geben kann (pro Pixel).

      c) Im 10bit-Kanal darf/kann die Umwandlung von 8 auf 10 bit keine zusätzlichen Bits im 10bit-Kanal setzen! Das ergäbe einen anderen Wert (und damit eine andere Farbe) und die Umrechnung/Umwandlung wäre dann ja falsch.

      d) Zusätzliche Bits im 10bit-Kanal werden IMO daher erst durch das "Grading" gesetzt (generiert), der ursprüngliche Umrechnungswert (die Farbe) also dem Gradingwunsch entsprechend geändert.

      Ich habe also - kurz gesagt - ein Problem mit dem Begriff "Zwischenräume" in den einzelnen Kanälen eines Pixels.

      // Wie ich schon erwähnte: Ein interessantes Thema.
      PS: Mit den internen Umrechnungen/Speicherungen (64bit rechnen, 32float speichern) habe ich kein Verständnisproblem. Da sind wir uns wohl einig.
      Gruß kurt
    • Ja Kurt, Du hast ja völlig recht. Da habe ich mich blöd ausgedrückt, bzw. versucht zu stark zu vereinfachen.
      Und mir viel leider zur Benennung nichts vernünftigeres als "Zwischenraum" ein. ;(

      Gemeint war, dass eben die "folgenden" Kanäle ohne Bearbeitung keine abweichende Farbinformation besitzen. Ich wollte hier nur weiteren Streit vermeiden, wenn ich diese als "leer" bezeichnet hätte (wie es ja Wolfgang richtiger weise tat).

      Auch bei Punkt d) stimme ich Dir zu.
      Nur ist es hier m.E. so, dass es ja eben nur die Informationen aus der 8bit-Farbtiefe gibt. Ein Grading erzeugt dann daraus wiederum neue Werte in einer Matrix mit 10bit Farbtiefe.
      Diese Werte können durch eine andere Rundung in der Rechenoperation eben einen abweichenden Wert erhalten, von dem bei einer Berechnung mit 8bit-Farbtiefe. Bzw. es bleiben Werte erhalten, die bei einer Bearbeitung mit 8bit-Farbtiefe "wegfallen" würden.

      Und weiter, würde man die oben beschriebenen Werte mit denen von echtem 10bit-Material, das mit den gleichen Parametern gegradet wurde vergleichen, ergäben sich ebenfalls Abweichungen.


      Insoweit sind wir uns (wieder einmal) völlig einig. Aber wie Du ja selbst weißt, ist es sehr schwierig solche Vorgänge allgemein verständlich zu formulieren.


      Gruß
      Peter
    • gurlt schrieb:

      Auch bei Punkt d) stimme ich Dir zu.
      (1) Nur ist es hier m.E. so, dass es ja eben nur die Informationen aus der 8bit-Farbtiefe gibt. Ein Grading erzeugt dann daraus wiederum neue Werte in einer Matrix mit 10bit Farbtiefe.

      (2) Diese Werte können durch eine andere Rundung in der Rechenoperation eben einen abweichenden Wert erhalten, von dem bei einer Berechnung mit 8bit-Farbtiefe. Bzw. es bleiben Werte erhalten, die bei einer Bearbeitung mit 8bit-Farbtiefe "wegfallen" würden.

      (3) Und weiter, würde man die oben beschriebenen Werte mit denen von echtem 10bit-Material, das mit den gleichen Parametern gegradet wurde vergleichen, ergäben sich ebenfalls Abweichungen.

      (4) Insoweit sind wir uns (wieder einmal) völlig einig. Aber wie Du ja selbst weißt, ist es sehr schwierig solche Vorgänge allgemein verständlich zu formulieren.

      Hallo Peter:

      ad (1): Erster Satz ist klar. Im zweiten Satz spreche ich lieber von einem Vektor: Es gibt drei Farbkanäle (R, G, B), die zu jedem Zeitpunkt jeweils nur einen Wert enthalten können, z.B. (127,127,127) für ein mittleres Grau.
      // Da Vektoren üblicherweise senkrecht geschrieben werden, handelt es sich hier natürlich um die transponierte Form (die für normale Texte geeigneter ist).
      ad (2): ... und durch das "Einpassen" in den 10er-Raum ....
      ad (3): Ja, mit hoher Wahrscheinlichkeit vermutlich.
      ad (4): Ja, weil verschiedene Erklärungsparadigmen bei den Menschen unterschiedliche Vorstellungsmuster erzeugen können.
      // Als ich vor zig Jahren mit Null Ahnung in die EDV eintrat, hatte ich mit dem damals schon gängigen Begriff "Kanal" größte Probleme, weil vor meinem geistigen (EDV-unbelasteten) Auge immer das Bild eines Abwasserkanals mit Ratten auftauchte. Bis ich feststellte, dass im Englischen channel eine etwas andere Bedeutung hat als das englische Wort canal (da verschwanden dann wenigsten die Ratten :) ).

      Resümee: Damit sollten jetzt aber dann alle diesbezüglichen Klarheiten beseitigt sein :teufel:

      Gruß kurt
    • kpot11 schrieb:

      Im zweiten Satz spreche ich lieber von einem Vektor:
      ...das könnte dann aber wiederum zu Irritationen, nämlich einer Verwechslung mit einer Vektorgrafik führen. :evil:

      kpot11 schrieb:

      Als ich vor zig Jahren mit Null Ahnung in die EDV eintrat, hatte ich mit dem damals schon gängigen Begriff "Kanal" größte Probleme...
      So ging es mir mit angle (Winkel) und angel (Engel)… :rolleyes: (frag lieber nicht....)

      Gruß
      Peter
    • gurlt schrieb:

      ...das könnte dann aber wiederum zu Irritationen, nämlich einer Verwechslung mit einer Vektorgrafik führen.
      Hmmm...
      a) Matrix ist aber nicht zutreffend, Vektor wäre korrekter.
      b) Neutral wäre (geordnetes) Tripel (Rot-wert, Grün-wert, Blau-wert), also z.B. [120, 64, 180] // Diese Farbe weiß ich jetzt aber nicht auswendig ?(
      // "Geordnet" kann weggelassen werden, da in der Mathematik "Tupel" (Tripel, Quadrupel,...) als geordnet angesehen werden.
      c) Beispiel:
      - Reines Blau im 8bit-Raum ... (0, 0, 255)
      - Dasselbe Pixel nach einem Grading im 10bit-Raum ... (1020, 0, 0) // Da wurde z.B. ein blauer Pullover ziemlich rot gefärbt.
      ... und warte sonst auf bessere Bezeichnungen :beer:
      // Bloß nicht Menge {R-wert, G-wert, B-wert}. // Denn in einer Menge sagt die Position nichts über deren Bedeutung aus (sehr kompliziert unser Leben).
      Gruß kurt
      PS: Im Falle eines RGB-Pixels mit Alpha hätte man dann ein (geordnetes) Quadrupel (pro Pixel) vorliegen: (127,127,127,180) (Rot-wert, Grün-wert, Blau-wert, Alpha-Wert).
    • Matrix ist aber nicht zutreffend, Vektor wäre korrekter.
      Na, wenn wir schon in der Mathematik sind:
      Ein Vektor kann auch als Matrix angesehen werden (1 Zeile, n Spalten resp. 1 Spalte, n Zeilen)
      Auch eine Zahl ist nur ein Sonderfall eines Vektors/einer Matrix (eine Zeile, eine Spalte).
    • K.-D. Schmidt schrieb:

      Matrix ist aber nicht zutreffend, Vektor wäre korrekter.
      Na, wenn wir schon in der Mathematik sind:(1) Ein Vektor kann auch als Matrix angesehen werden (1 Zeile, n Spalten resp. 1 Spalte, n Zeilen)
      (2) Auch eine Zahl ist nur ein Sonderfall eines Vektors/einer Matrix (eine Zeile, eine Spalte).
      ad (1) Ja, wenn man sich mit Matrizenrechnung beschäftigt, kann ein derartiger Sonderfall praktisch sein.

      ad (2) Meist bezeichnet man solche Strukturen als Skalare. Bei einem (1,1)-Vektor fehlt halt irgendwie die Richtung, die man in der Vektorrechnung meist schätzt oder braucht.

      Damit klinke ich mich aber jetzt aus den Mathematiküberlegungen aus, weil es einerseits genug gut geschriebene Mathe-Bücher gibt und andererseits, weil ich mir vorstellen könnte, dass der mathematisch interessierte Benutzerkreis sich sowieso in Grenzen halten wird.

      Im Hinblick auf unsere Pixel gefällt mir der Begriff Tripel (bzw. Quadrupel) eigentlich noch am besten.
      Gruß kurt
    • kpot11 schrieb:

      11. Da die RGB-Farbe eines Pixels durch drei Kanäle dargestellt wird, hat das "Grading" im 8bit-Raum i.a. 3 bit zur Verfügung (numerisch also: 2 hoch 3 = 8 Möglichkeiten).
      12. Im 10bit-Raum hat das "Grading" i.a. 6 bit ( wegen 9. je Farbkanal 2 bit) zur Verfügung (numerisch also: 2 hoch 6 = 64 Möglichkeiten).
      Klar, grundsätzlich hast eine feinere Möglichkeit der Abstufung - was ja der Sinn ist von 8bit auf 10bit auf 12bit auf 16bit zu gehen. Was bedeutet dass ich für ein Grading eben mehr Spielraum bekomme, 16bit ist eben besser als 12bit ist eben besser als 10bit ist eben besser als 8bit.

      Ob jetzt 8bit oder auch 10bit ausreichen hängt vom Motiv und den Arbeitsschritten das Anwenders ab - klar reicht 8bit sehr oft. Allerdings rechnen Gradingapplikationen eben immer intern mit 32bit Floating Point, und die wissen schon warum sie das machen.

      PeterC schrieb:

      Das ist der Punkt, der den Anwender interessiert. Was kommt aus dem einen Filter raus und wird in den nächsten Filter wieder reingegeben.
      Da kappt Edius auf 10 Bit Ganzzahl.
      und

      kpot11 schrieb:

      1. Gerechnet wird in den 64 Bit Versionen in 64 Bit.
      2. Speicherintern abgelegt lt. GV in 32 Bit Fließkomma.
      3. Von Filter zu Filter sowie zurück an die Timeline wird in 10 Bit Ganzzahl übergeben.
      Von GV bzw. den Moderatoren wird immer wieder gesagt, dass an "kritischen Stellen" im Signalfluß in Edius in 32bit Floating Point gerechnet wird. Abgesehen von diesen Aussagen gibt es dafür aber keine Dokumentation - und umstellbar ist das auch nirgends. Das kann man denen also glauben oder auch nicht. Ich persönlich glaube das denen sehr wohl, auch wenn ich mir dazu eigentlich mehr Information etwa in Form von White papers erwarten würde.

      Der Vorteil läge auf der Hand - höhere Rechenpräzission. Und klar kann man sein 8bit Material auch im 10bit Modus rechnen. Verhindert in der Praxis durchaus Banding welches man in einigen Fällen sonst beim Rausrendern bekommt. Dass dabei Zwischenfarbtöne entstehen kann man so oder so sehen - bevor man aber Banding hat nimmt man das wohl oft gerne in Kauf.

      gurlt schrieb:

      Eine 8bit-Farbtiefe hat nur 256 "Möglichkeiten". Bringe ich nunmehr diese Informationen in einen Raum mit 10bit-Farbtiefe, werden die "Zwischenräume" praktisch mit der gleich Information aufgefüllt (und darauf - denke ich - will Wolfgang hinaus).

      gurlt schrieb:

      Bei 10bit-Farbtiefe habe ich für meine 8bit Informationen ein breiteres Raster. Dadurch bleibt in den "Zwischenräumen" die ursprüngliche Informationsbreite erhalten.


      Ob sich das dann allerdings auch auf dem Bildschirm wirklich sichtbar auswirkt, ist eine andere Frage.
      Das Problem mit den Zwischenräumen sehe ich primär dann, wenn man eben von 8bit Material ausgeht und mit mehr Farbpräzision rendert. Da gabs mal Beispiele einer "roten Ente" auf slashcam, vom User wowu, wo durch derartige Operationen plötzlich gelbe Farbtöne an Rändern wo das Rot an einen weißen Hintergrund gestossen ist aufgetreten ist. Einfach, weil da überraschende Zwischenfarben errechnet werden die es sonst in dem Motiv gar nicht gab. Ist ein altes Beispiel, Link habe ich da keinen und gehe den auch nicht suchen. Vermeidbar ist sowas halt viel besser wenn ich gleich von 10bit ausgehe und schon im Originalmaterial das 4-fache an Informationen sitzt.

      8bit hat eben nur maximal 256 Datenstellen - und wenn ich die 256 Datenstellen auf 1024 lege sind dazwischen einfach 3/4 der Datenstellen leer. Ich weiß auch nicht warum man so etwas direkt einsichtiges weiter begründen soll, denn woher soll den die wundersame Datenvermehrung kommen. Aus Nix wird Nix.

      kpot11 schrieb:

      2) "Bei 10bit-Farbtiefe habe ich für meine 8bit Informationen ein breiteres Raster. Dadurch bleibt in den "Zwischenräumen" die ursprüngliche Informationsbreite erhalten."
      Nicht im O-Material, maximal hast Platz für errechnete Zwischenwerte. Eben mit der grundsätzlichen Thematik dass man 3/4 der Zwischenwerte interpoliert.

      kpot11 schrieb:

      d) Zusätzliche Bits im 10bit-Kanal werden IMO daher erst durch das "Grading" gesetzt (generiert), der ursprüngliche Umrechnungswert (die Farbe) also dem Gradingwunsch entsprechend geändert.

      Ich habe also - kurz gesagt - ein Problem mit dem Begriff "Zwischenräume" in den einzelnen Kanälen eines Pixels.
      Nur sind die Zwischenräume mathematische Realität - das ist aber gar nicht die relevante Frage. Die Frage ist eher ob man mit den Zwischenräumen ein tatsächliches Problem nach der Berechnung bekommt, und das hängt eben vom spezifischen Motiv ab. Das kann Vorteile haben (Banding vermeiden), aber eben auch Nachteile (überraschende Farben die entstehen).
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • wolfgang schrieb:

      (1) Nicht im O-Material, maximal hast Platz für errechnete Zwischenwerte. Eben mit der grundsätzlichen Thematik dass man 3/4 der Zwischenwerte interpoliert.


      (2) 1. Gerechnet wird in den 64 Bit Versionen in 64 Bit.
      2. Speicherintern abgelegt lt. GV in 32 Bit Fließkomma.
      3. Von Filter zu Filter sowie zurück an die Timeline wird in 10 Bit Ganzzahl übergeben.
      Hallo Wolfgang:
      Mit allen Kommentaren von dir zu meinem Rechenbeispiel einverstanden, außer zwei kleine Klarstellungen:
      ad (1): Hier habe ich Peter (gurlt) zitiert (interessiert mich aber trotzdem).
      ad (2): Hier habe ich PeterC zitiert bzw. zusammengefasst.
      Deswegen habe ich die entsprechenden Textstellen dort auch blau markiert.

      Ist aber alles nicht wirklich wichtig. Wichtig ist die Summe der Erkenntnisse und da stimmen wir eigentlich alle überein ! // Bis auf die etwas ungeklärbare 32float Berechnung.
      Gruß kurt
    • Bei einem (1,1)-Vektor fehlt halt irgendwie die Richtung
      Aber nur, wenn man mit einem Vektor aus der Schulmathematik einen Pfeil verbindet. Vektoren sind aber abstrakte Gebilde eines Vektorraums. Das musste ich als Mathematiker dann doch noch anmerken.
      Ansonsten:

      Damit klinke ich mich aber jetzt aus den Mathematiküberlegungen aus, weil es einerseits genug gut geschriebene Mathe-Bücher gibt und andererseits, weil ich mir vorstellen könnte, dass der mathematisch interessierte Benutzerkreis sich sowieso in Grenzen halten wird.
    • K.-D. Schmidt schrieb:

      Bei einem (1,1)-Vektor fehlt halt irgendwie die Richtung
      Aber nur, wenn man mit einem Vektor aus der Schulmathematik einen Pfeil verbindet. Vektoren sind aber abstrakte Gebilde eines Vektorraums. Das musste ich als Mathematiker dann doch noch anmerken.
      Jetzt sollten wir aber keinen Wettstreit darüber führen, wer von uns beiden der präzisere Mathematiker ist :shake:
      Wenn man von meinem vollständigen Zitat
      "Bei einem (1,1)-Vektor fehlt halt irgendwie die Richtung, die man in der Vektorrechnung meist schätzt oder braucht."
      entsprechende Teile ausblendet, kann man endlos (aber auch nutzlos) weiterdiskutieren.
      Das bringt doch bitte niemandem etwas.
      Ich glaube auch nicht, dass es wirklich jemandem interessiert, ob und wer sich von uns beiden vom Mathe-Studium am meisten gemerkt hat.
      Gruß kurt