Abo
  1. Foren
  2. Kommentare
  3. Foto
  4. Alle Kommentare zum Artikel
  5. › Rückkehr der Paper Disk: 256 GByte auf A4…
  6. Thema

Fake!

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


  1. Re: LOL, watt 'ne Argumentation

    Autor: h.ludens 27.11.06 - 13:42

    bei den 15 werten bin ich offengestanden davon ausgegangen, daß die logische null ja dann leider auch keine farbinformation (wegen eben null gedruckter pixel) ausdrücken würde....somit würde diese konstellation eben nur genau eine null darstellen, aber nicht null * rgb...aber zugegeben, daran kann man noch herumrechnen. dem rest deiner argumentation kann ich aber leider so nicht folgen...weil ich die viertelung der datenmenge durch die pixelquantisierung durchaus schon berücksichtigt habe. aber wie auch immer, ich wollte hier keine schlammschlacht starten, ich fand nur den beitrag des erstposters ein wenig arg vereinfachend. mfg : h.ludens


  2. Re: Fake!

    Autor: King Euro 27.11.06 - 13:44

    wurstwie schrieb:
    -------------------------------------------------------
    > aber ist das nicht genau was biärcode macht? um
    > bei deinem beispiel hier zu bleiben:
    >
    > 1000 oder 0100 oder 0010 oder 0001 oder 1100 oder
    > 0110 etc?
    >
    > weil dann brauche ich ein bit pro pixel, was
    > bedeutet dass ich genausoviele bit wie bildpixel
    > speichern kann. oder?
    >

    Dadurch, dass es verschiedene Farben sein können gibt es aber mehr als 1 und 0, oder? nimm zB nur 16, farben, dann hast du schon 0-15...

    oder so.. kA.. mir eig. auch egal :D

  3. Re: LOL, watt 'ne Argumentation

    Autor: Amüsierter Leser 27.11.06 - 13:54

    h.ludens schrieb:
    -------------------------------------------------------
    > dem
    > rest deiner argumentation kann ich aber leider so
    > nicht folgen...weil ich die viertelung der
    > datenmenge durch die pixelquantisierung durchaus
    > schon berücksichtigt habe.

    Okay, dann noch mal in Großbuchstaben.

    Du kannst in 4 Bit ->EINEN (1,0)<- von 16 MÖGLICHEN
    Werten speichern. Entsprechend hast Du EINEN Wert, den Du
    4fach auflösen kannst (was 16 Möglichkeiten entspricht),
    aber dafür die Gesamtauflösung des Blattes geviertelt.

    Gesamtauflösung = BitsProWert * AnzahlWerte
    Und die Gesamtauflösung bleibt konstant, egal wie Du die Werte
    auf dem Blatt verteilst.

    Ansonsten würde eine alternative Kodierung von Daten ja auch die
    Speicherkapazität vom anderen Datenträgern erhöhen.

  4. klingt nicht so ganz unglaubwürdig

    Autor: catweezel 27.11.06 - 13:56

    mathesechser schrieb:
    -------------------------------------------------------
    > Dass das ganze nicht gehen kann, muss jedem klar
    > sein, der rechnen kann. Siehe arstechnica.com

    Da wär ich mir nicht ganz so sicher.
    Wenn man das ganze Farbspektrum nutzt inklusive unterschiedlicher Formen, so kommt man schon auf eine erhebliche Anzahl von Werten, die ein einzelner "Punkt" speichern kann.
    Je nach DPI Auflösung könnte da schon einiges zusammen kommen.

    [quote]
    http://arstechnica.com/news.ars/post/20061126-8288.html

    There is a word for using mathematical algorithms to increase the storage space of digital information: it's called compression. No amount of circles and triangles could be better than existing compression algorithms: if it was, those formulas would already be in use!
    [/quote]
    Das Verfahren kann ohne eine Art Kompression garnicht genutzt werden, sonst könnte man keine zig Millionen Bit Kombinationen pro Punkt speichern sondern immer nur 1/0.

    Ich habe jetzt leider keine Zeit um das mal durchzurechnen, aber so ganz für abwägig halte ich das ganze nicht. :o)
    Wobei man das sicher nach unten korrigieren muss - ich bezweifle das Scanner die Farben 1:1 wiedergeben.
    Und CRC müsste wohl auch noch rein. :)

    catweezel

  5. Re: Fake!

    Autor: linos 27.11.06 - 13:58

    Die Farbabweichung dürfte uninteressant sein.
    Alles was man machen müsste wäre eine Art Refferenz auf eine definierte Position der Seite aufzudrucken für jede Grundfarbe.
    Wenn man annimmt, dass die Seite gleichmäßig ausbleicht ist die Zuordnung der Werte für jede Farbe immer gegeben. Kaffeeflecken etc. nicht berücksichtigt, aber man kann ja den Ausdruck auch verschweißen...

    huahuahua schrieb:
    -------------------------------------------------------
    > h.ludens schrieb:
    > --------------------------------------------------
    > -----
    > > mal davon abgesehen, daß ein standard-scan
    > einer
    > Din-A4-seite im Bitmap-format nicht
    > umsonst um
    > einiges über der auf dieser seite
    > errechnetem wert
    > liegt...was wohl daran
    > liegt, daß er die
    > farbinformation vergessen
    > hat, in betracht zu
    > ziehen...lass mich eine
    > gegenrechnung aufstellen
    > :
    > also - nehmen
    > wir seine 134 millionen pixel pro
    > seite und
    > geben wir jedem pixel eine
    > farbinformation
    > von 3 byte (rgb ohne alpha), dann
    > können wir
    > pro seite bei pixelgenauem scannen so
    > etwa
    > 383 MegaByte codieren (naja...rein
    >
    > theoretisch, zugegeben). aber - dabei ist der
    >
    > bildinhalt ja völlig außer betracht gelassen
    >
    > worden!
    > gibt man jeweils vier benachbarten
    > pixeln die
    > gleiche farbe und wertet die 15
    > möglichen muster
    > aus, die sich ergeben, wenn
    > man nicht alle pixel
    > druckt, ergeben sich
    > schon knappe 1450 MegaByte.
    > nimmt man
    > 16er-würfel, ist man bei theoretischen
    >
    > anderthalb terabyte, wenn ich mich nicht
    >
    > verrechnet habe.
    > das läßt natürlich jede
    > fehlerkontrolle und wohl
    > nötige
    > quantisierungen völlig außer acht, sollte
    >
    > aber eine vorstellung geben, was theoretisch
    >
    > möglich wäre. naturlich ist das nicht im sinne
    > der
    > industrie und wohl auch auf
    > consumer-geräten reine
    > utopie...aber ich
    > finde die idee trotzdem
    > interessant. mfg
    > h.ludens
    >
    > Danke, wollte eben selbst noch eine Rechnung
    > aufstellen, die diese Möglichkeiten unterstreicht,
    > doch Dein Beitrag erspart mir die Rechnerei.
    > Wer mal eine A4-Seite mit mehr als 1200 dpi
    > gescannt hat (was mit einem normalen Scanner
    > Ewigkeiten dauert!!!), der weiß auch, was für eine
    > Datei ihn erwartet, wenn er in BMP speichert.
    > JPG wäre Unsinn, da hier verlustbehaftet
    > komprimiert wird.
    > Die zu klärende Frage wird wohl die
    > Drucker-Scanner Farbkompatibilität sein, an der
    > sich die Hersteller ja eh schon die Zähne
    > ausbeißen. Lässt man allerdings eine gewisse
    > Tolleranz zu und verzichtet dafür auf etwas
    > Speicherplatz, so sollten die 256 GB schon machbar
    > sein. Bleibt die Frage des Mediums, da Papier und
    > Druckerfarben einem schnell sichtbar werdenden
    > Verfall unterliegen.
    > (Wäre mal zu Prüfen, wieviel Kapazität bei
    > Schwarz-Weiß übrigbliebe.)
    > Auch Verunreinigungen und Knicke sind wohl Gift
    > für das Verfahren.
    > Hier bin ich auf Antworten gespannt.
    > Schließlich tut es unter Umständen schon weh, wenn
    > mal eben 256 GB wichtiger Daten der Kaffeetasse
    > zum Opfer fallen...;))


  6. Re: Fake!

    Autor: smilingrasta 27.11.06 - 14:07

    h.ludens schrieb:
    -------------------------------------------------------
    > also - nehmen wir seine 134 millionen pixel pro
    > seite und geben wir jedem pixel eine
    > farbinformation von 3 byte (rgb ohne alpha), dann
    > können wir pro seite bei pixelgenauem scannen so
    > etwa 383 MegaByte codieren (naja...rein
    > theoretisch, zugegeben).

    Es sind nicht nur drei Byte die man pro Farbpunkt speichern kann, sondern derer bei True-Color 16.777.216 mögliche Bytekombinationen. Ein erheblicher Unterschied. ;)
    Dies beinhaltet allerdings (notwendige) Kompression, sprich eine Farbe steht für eine bestimmte Bytekombination.
    Ein Farbpunkt könnte also eine Menge Bytes speichern, keine Lust das jetzt auszurechnen. :)

    > gibt man jeweils vier benachbarten pixeln die
    > gleiche farbe und wertet die 15 möglichen muster
    > aus, die sich ergeben, wenn man nicht alle pixel
    > druckt, ergeben sich schon knappe 1450 MegaByte.

    Darüber habe ich eben auch nachgegrübelt.
    Wenn ich die Auflösung halbiere aber die Kombinationsmöglichkeiten dadurch um ^4 steigen, so ist der Zugewinn nicht von schlechten Eltern.

    Beispiel:

    100x100 Dots, True Color, 1 Dots per Value = 167.772.160.000 Bytekombinationen
    (100*100 * 256x256x256 * 1)

    50x50 Dots, True Color, 4 Dots per Value = ziemlich groß.
    ((50*50 * 256x256x256 )^4)

    Von daher nicht sooo unwahrschenlich das ganze.
    Steht und fällt mit der Kompression.
    Ajo und TrueColor ist was fehleranfällig, würde maximal mit HighColor arbeiten. Und eine Fehlerkorrektur muss auch unbedingt rein. Das schmälert die Ausbeute...

    MfG
    smilingrasta

  7. Re: LOL, watt 'ne Argumentation

    Autor: h.ludens 27.11.06 - 14:14

    > Okay, dann noch mal in Großbuchstaben.
    >
    > Du kannst in 4 Bit ->EINEN (1,0)<- von 16
    > MÖGLICHEN
    > Werten speichern. Entsprechend hast Du EINEN Wert,
    > den Du
    > 4fach auflösen kannst (was 16 Möglichkeiten
    > entspricht),
    > aber dafür die Gesamtauflösung des Blattes
    > geviertelt.
    >
    > Gesamtauflösung = BitsProWert * AnzahlWerte
    > Und die Gesamtauflösung bleibt konstant, egal wie
    > Du die Werte
    > auf dem Blatt verteilst.
    >
    > Ansonsten würde eine alternative Kodierung von
    > Daten ja auch die
    > Speicherkapazität vom anderen Datenträgern
    > erhöhen.

    ich wage nicht, dir zu widersprechen, du hast hundertprozentig recht. ich kann mit vier einfarbigen pixeln genau 16 verschiedene kombinationen darstellen. der knackpunkt ist aber, daß ich mit vier rgb-pixeln 3 Byte mal 15 möglichkeiten (und eine recht farblose null) darstellen kann. nebenbei bemerkt enthält ein mit binärdaten vollgeschriebener datenträger natürlich deutlich weniger information, als ein im hexadezimalcode beschriebener. aber wie gesagt, es ging mir keineswegs darum, eine schlammschlacht zu starten - also nichts für ungut. mfg : h.ludens

  8. Mal dumm gefragt.

    Autor: Dumm 2.0 27.11.06 - 14:15

    Ich habe 256 Farben.

    Jeder Pixel kann also 256 Wert annehmen.

    Nun sagst Du wenn ich 4 solcher Punkte Zweidimensional zusammenfasse kann ich mehr Informationen unterbringen.

    Ich bin nun weit davon heir in Sachen Informatik oder mathematik wirklich mitzuhalten, aber dieses Zusammenfassen von 4 Werten erinnert mich eher an Kodierung wie z. B. bei ASCII üblich.

    01000001 = 65 = A

    Durch das zusammenfassen vn 8 bit habe ich 1 byte. Damit kann ich z. B. ein A beschreiben. Mehr Informationen habe ich durch das clustern von 8 bit zu einem byte nicht bekommen.

  9. Re: LOL, watt 'ne Argumentation

    Autor: smilingrasta 27.11.06 - 14:17

    Amüsierter Leser schrieb:
    -------------------------------------------------------
    > Du kannst in 4 Bit ->EINEN (1,0)<- von 16
    > MÖGLICHEN
    > Werten speichern. Entsprechend hast Du EINEN Wert,
    > den Du
    > 4fach auflösen kannst (was 16 Möglichkeiten
    > entspricht),
    > aber dafür die Gesamtauflösung des Blattes
    > geviertelt.

    Falsch -> Kompression.
    Jede Farbe repräsentiert eine Bytekombination, ergo kommt man
    auf 256x256x256 Bytekombinationen pro Farbpunkt, welche natürlich definiert sein müssen.

    Halbiert man jetzt die Auflösung, um mehr Punkte für einen Wert zu nutzen, so steigert sich die Kombinationsmöglichkeit dadurch um Hoch 4.
    Und (x / 2)^4 ist immer noch mehr als x.
    Oder sehe ich da was falsch?

  10. neenee

    Autor: nee 27.11.06 - 14:18

    > der knackpunkt ist aber,
    > daß ich mit vier rgb-pixeln 3 Byte mal 15
    > möglichkeiten (und eine recht farblose null)
    > darstellen kann.

    nee. entweder du ballerst die rgb-werte dahin, oder du machst muster, kannst dann aber nicht mehr nach belieben rgb-farbwerte benutzen - du willst ja das muster haben.

  11. lochmuster

    Autor: raccoon 27.11.06 - 14:19

    h.ludens schrieb:
    -------------------------------------------------------
    > stell dir einfach vier gleichfarbige pixel
    > nebeneinander vor, dann kannst du das so aussehen
    > lassen :
    > .--- oder -.-- oder --.-- oder ---. oder ..-- oder
    > -..- usw...mit zwei binären variablen (pixel ist
    > gedruckt, pixel ist nicht gedruckt) lassen sich
    > eben 15 kombinationen codieren. ok ?
    >
    >


    und die farbe des nicht gedruckten pixels erhält man durch?

    wen du jetz fragst:
    warum die farbe des nicht gedruckten pixels; dann überlege ma, wenn die seite voll ist, hat das papier einen informationsgehalt von ca 100 Mbyte (bei 239pixel je cm -->
    (239pixel/cm)^2*21cm*29cm*3byte/pixel² =~ 100Mbyte)
    jedes mal wenn du ein pixel entfernst bedeutet das, dass du 3 byte entfernst zwar bekommst du dann ein hübsches und evtl informatives lochmuster jedoch sind dies nur 4MB ((239pixel/cm)^2*21cm*29cm*1bit/pixel² ) im durchschnitt discardest du aber 50% der pixel( turn 2 white, noprint... ) was also 50Mbyte farb daten ausmacht
    naja um denn doch noch nen halbwegs positiven effekt aus dem weglassen der pixel zu erreichen könnte man ca alle mehr als 2^24 einen weglassen,
    dies würde durch die position wieder die 3 byte die durch weglassen des pixels "verloren gingen" wiederherstelen in 2^32 würde dies sogar ein byte "gewin bedeuten", jedoch müsste das papier dazu etwas größer sein, denn 2^32 pixel gibet erst bei 123 mal soviel speicher


    je weniger bit jedoch je pixel codiert werden desto lukrativer wird ein "lochmuster".



    ab hier gehts dann eher in richtung kompression, und dabei haben sich algorythmen bewährt die die selbstähnlichkeit, und redundanz der daten berücksichtigen, jedoch fürt dies z.z. auch nur zu kompressionsraten von 30 bis 50 %


    zukünftige kompressionsalgorythmen werden die datenchunks in bekante und allgemeine teile , und unbekante und einzigartige teile aufteilen und nur diese speichern, ähnlich unseres gedächtnisses.
    (mit geschätzten 20%, mehr redundanz ist meist nich )


    PS: ich hab mich absichtlich nich über fehlerkorektur und syncronisation ausgelassen





  12. Re: Mal dumm gefragt.

    Autor: Tja 27.11.06 - 14:22

    Richtig heisst es, ein Pixel kann nur einen von 256 Wertenn annehmen. Ein Pixel ist nunmal entweder nur 8 oder 133 oder 255 und nie gleichzeigt 111 und 155. Deswegen stecken in 8 Bit eben nur 8 Bit, die einen Bereich von 0 bis 255 abdecken.
    Bei einer Auflösung von 100 * 100 Pixel sind das also nur 8 * 100 * 100 = 80.000 Byte und nicht 256 * 100 * 100 = 2.560.000 Byte.
    Und 16 Millionen Farben sind auch nichts anderes als 3 Byte, also 24 Bit und nicht nicht etwa 15 Millionen Bit.
    Und Kreise und Kurven und sonstige schöne Formen beschränken ehr die Informationsdichte, als dass sie sie erhöhen.


    Dumm 2.0 schrieb:
    -------------------------------------------------------
    > Ich habe 256 Farben.
    >
    > Jeder Pixel kann also 256 Wert annehmen.
    >
    > Nun sagst Du wenn ich 4 solcher Punkte
    > Zweidimensional zusammenfasse kann ich mehr
    > Informationen unterbringen.
    >
    > Ich bin nun weit davon heir in Sachen Informatik
    > oder mathematik wirklich mitzuhalten, aber dieses
    > Zusammenfassen von 4 Werten erinnert mich eher an
    > Kodierung wie z. B. bei ASCII üblich.
    >
    > 01000001 = 65 = A
    >
    > Durch das zusammenfassen vn 8 bit habe ich 1 byte.
    > Damit kann ich z. B. ein A beschreiben. Mehr
    > Informationen habe ich durch das clustern von 8
    > bit zu einem byte nicht bekommen.


  13. Re: Fake!

    Autor: h.ludens 27.11.06 - 14:22

    > Du nimmst 4 Pixel, die je 256 Farben darstellen
    > können (4294967296 Möglichkeiten), und ersetzt
    > alle durch die gleiche Farbe. Jetzt kannst du 16
    > Zustände darstellen. Es wird nur weniger. Ich sehe
    > nicht, wie es mehr werden sollte. Die 16 Zustände
    > sind in den 4294967296 Möglichkeiten schon
    > berücksichtigt.
    >
    > Man kann nur entweder 4294967296 Möglichkeiten
    > nutzen ODER 16 Zustände haben. Es gibt kein
    > 4294967296 * 16.
    >
    > X-stian

    nein nein. du nimmst vier pixel, die je 3 byte farbe darstellen können (jedes pixel entsteht aus farbmischung und hat einen rgb-wert), modellierst mit diesen vier pixeln aber 15 zustände durch setzen bzw nichtsetzen eines der vier pixel. damit stellst du mit diesen vier pixeln zwar nur einen farbwert dar, aber fünfzehn figuren (und null, die aber dann leider keinen farbwert darstellt)...erhöhst also die letzendliche datenrate auf das knapp vierfache...so ? mfg : h.ludens


  14. Re: Fake!

    Autor: Pixelnase 27.11.06 - 14:31

    Der fehlende Pixel ist doch auch nur ein Farbwert. Jetzt mal rein optisch gesehen, auf Papier: weiß.

  15. Re: LOL, watt 'ne Argumentation

    Autor: Amüsierter Leser 27.11.06 - 14:31

    h.ludens schrieb:
    -------------------------------------------------------
    > der knackpunkt ist aber,
    > daß ich mit vier rgb-pixeln 3 Byte mal 15
    > möglichkeiten (und eine recht farblose null)
    > darstellen kann.

    3 Byte * 16 Möglichkeiten.
    Stimmt. Du könntest auch einfach 12 Byte aneinander
    packen, kommt auf's gleiche raus.
    Oder 12 * 8 Bits. Da ändert sich nix.

    > nebenbei bemerkt enthält ein mit
    > binärdaten vollgeschriebener datenträger natürlich
    > deutlich weniger information, als ein im
    > hexadezimalcode beschriebener.

    Nein. Auch hier ändert sich nichts.
    Du kannst die Zahlensysteme beliebig austauschen.
    Auf dieser 'Basis' arbeitet zum Beispiel Base64, dass
    3 Bytes, also ein 256-er Zahlensystem auf 4 Zahlen im
    64er Zahlensystem umwandelt.

    Du kannst also 4 Werte zur Basis 64 in 3 Werten zur
    Basis 256 speichern. Am Schluss sind es so oder so
    3 Byte Nutzdaten. Oder 24 Bit. Wie immer Du möchtest.

    Durch den wechsel des Zahlensystems erreicht man keine
    höhere Datendichte.
    Ob Du einen FarbPunkt als einen Wert mit einer Auflösung von
    24 Bit ansiehst, oder als 24 einfarbige Punkte, die auf einen
    Bildpunkt komprimiert sind. Es bleiben 24 Bit. Wenn Du
    vier unabhängige 24 Bit Punkte zusammenfasst, werden es
    4*24 Bit = 96 Bit.

    Du speicherst die vierfache Datenmenge, hast aber eben nur
    1/4 des Platzes zur Verfügung.

    Es verändert sich also nichts.

  16. Re: LOL, watt 'ne Argumentation

    Autor: smilingrasta 27.11.06 - 14:32

    smilingrasta schrieb:
    -------------------------------------------------------
    > Halbiert man jetzt die Auflösung, um mehr Punkte
    > für einen Wert zu nutzen, so steigert sich die
    > Kombinationsmöglichkeit dadurch um Hoch 4.
    > Und (x / 2)^4 ist immer noch mehr als x.
    > Oder sehe ich da was falsch?

    Ich meinte natürlich vierteln, für eine 2x2 Matrix halt.
    Also (x / 4)^4

  17. Re: Mathenachhilfe

    Autor: k-weddige 27.11.06 - 14:34

    smilingrasta schrieb:
    -------------------------------------------------------
    > Darüber habe ich eben auch nachgegrübelt.
    > Wenn ich die Auflösung halbiere aber die
    > Kombinationsmöglichkeiten dadurch um ^4 steigen,
    > so ist der Zugewinn nicht von schlechten Eltern.

    :'-( Nochmal gaaaanz laaaangsaaaam...

    Ein Pixel kann n Zustände haben. (z.B. rot, gelb, blau, schwarz und weiß -> n=5) Wenn du jetzt 4 Pixel zusammenfasst, kann dieser Metapixel n^4 Zustände annehmen. Dafür hast du nurnoch 1/4 der ursprünglichen Pixel (zwei Pixel nach rechts und zwei Pixel nach unten fasst du zu einem Metapixel zusammen).

    Dann rechnen wir das jetzt einmal durch. N sei die Anzahl der Pixel auf einem Blatt. Die Anzahl der Metapixel ist daher N/4.

    1. Fall:

    Informationen auf einem Blatt = n^N

    2. Fall: (deine tollen Metapixel)

    Informationen auf einem Blatt = (n^4)^(N/4)

    Jetzt schaust du in eine Formelsammlung: (Falls du sowas hast. In der Grundschule gibt es sowas noch nicht.)

    (a^x)^y = a^(x*y)

    Was sehen wir?

    (n^4)^(N/4) = n^(4*N/4) = n^N

    Wow! Da kommt genau das gleiche raus. Kaum zu glauben, is' aber so.

    n^N ist die maximale Menge an Informationen, die auf dem Blatt gespeichert werden können.

    Konstantin

  18. Wenns funktioniert - genial!

    Autor: Jonnyblue 27.11.06 - 14:44

    Also hier argumentieren alle, dass aktuelle Scanner nicht genau genug wären etc. Wenn ich mir jetzt aber überleg, dass man ja locker dann spezielle Laufwerke dafür entickeln könnte für Wechseldatenträger etc.? Dann wäre das ja kein Problem. Würde man z.B. eine Art Minidisc mit Papier in der mitte machen und schiebt das dann wo rein, wäre das ein super Datenträger. Und wenn man wirklich auf ein A4 Blatt ~100GB bekommt wäre Blueray und Co bald geschichte...

    Also von bestehender Scanner Hardware würde ich mal nicht ausgehen...


    alles theoretisch natürlich...

  19. Re: LOL, watt 'ne Argumentation

    Autor: Amüsierter Leser 27.11.06 - 14:44

    smilingrasta schrieb:
    -------------------------------------------------------

    > Falsch -> Kompression.

    Kompression erhöht nicht die Speicherrate.

    Eine 250G Platte speichert 250G komprimierter oder 250
    unkomprimierter Daten.
    Daten sind Daten, aber auf die Platten kommen garantiert
    nicht mehr als 250G.

    > Jede Farbe repräsentiert eine Bytekombination,
    > ergo kommt man
    > auf 256x256x256 Bytekombinationen pro Farbpunkt,
    > welche natürlich definiert sein müssen.

    Soweit so gut.

    > Halbiert man jetzt die Auflösung, um mehr Punkte
    > für einen Wert zu nutzen, so steigert sich die
    > Kombinationsmöglichkeit dadurch um Hoch 4.
    > Und (x / 2)^4 ist immer noch mehr als x.
    > Oder sehe ich da was falsch?

    Allerdings. x ist nicht die Anzahl der Kombinationen, sondern die Anzahl der
    Ziffern, der Bits, was auch immer. Diese Ziffern lassen sich aber beliebig
    kombinieren.
    4 Binärziffern erlauben nicht nur vier Kombinationen: 0 0 0 0, 0 0 0 1,
    0 0 1 0, 0 0 1 1... das geht noch weiter...

    Nehmen wir an x sind 4 Werte a 1 Bit.

    0 1 1 0

    Kombinationsfähigkeit: 2 Möglichkeiten pro Wert hoch(!) 4 Werte
    = 2^4 = 2 * 2 * 2 * 2 = 16

    Ordnen wir die Sache neu: x/2, wir halbieren die Auflösung und erdoppeln
    die Kombinationsfähigkeit der EINZELNEN Werte

    01 10

    Kombinationsfähigkeit: 4 Möglichkeiten pro Wert hoch(!) 2 Werte
    = 4^2 = 4 * 4 = 16

    0110

    Kombinationsfähigkeit: 16 Möglichkeiten pro Wert hoch(!) 1 Werte
    = 16^1 = 16 = 16

    Ihr könnt sortieren wie ihr wolt, am Schluss werden immer die gleiche Menge an Kombinationen herauskommen.

  20. Rechnen will gelernt sein...

    Autor: Slartibartfast 27.11.06 - 14:48

    h.ludens schrieb:
    -------------------------------------------------------
    > du nimmst je vier pixel und gibst ihnen die
    > gleiche farbe. dadurch reduziert sich die
    > datenmenge von 380 MB auf so etwa 95 MB, ok ? da
    > du aber mit den entstandenen vierergruppen je 16
    > zustände darstellen kannst, entstehen im endeffekt
    > eben 95 * 16 MB

    *möööp* schwerwiegender Rechenfehler!

    Du kannst mit 1 RGB-Pixel bei 8 Bit pro Farbkomponente 3 Byte speichern, so weit ists klar. Jetzt nimmst du statt 1 Pixel 4 - okay, dann pro 4 Pixel 3 Byte = 24 Bit. Jetzt nimmst du noch die Kombinationen dazu - macht bei 4 Pixel und binärer Codierung (Pixel an / Pixel aus, mehr gibts ja nicht) 4 Bit. Du erhältst also insgesamt pro 4er-Block jetzt 24 Bit durch die Farbe + 4 Bit durch das binäre Raster = 28 Bit, also 3 1/2 Byte Speicherplatz. Vorher hattest du aber 3 * 4 = 12 Byte pro 4 Pixel.

    So, jetz erklär mir bitte nochmal, wo da der Gewinn herkommen soll...

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Universitätsmedizin der Johannes Gutenberg-Universität Mainz, Mainz
  2. BWI GmbH, Germersheim
  3. BWI GmbH, Bonn, Berlin, Strausberg
  4. Rational AG, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 39,99€ (Release am 3. Dezember)
  2. (aktuell u. a. Corsair Glaive RGB Gaming-Maus für 32,99€, Microsoft Office 365 Home 1 Jahr für...
  3. (u. a. HP 34f Curved Monitor für 389,00€, Acer 32 Zoll Curved Monitor für 222,00€, Seasonic...
  4. (u. a. Star Wars Battlefront 2 für 9,49€, PSN Card 20 Euro für 18,99€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Change-Management: Die Zeiten, sie, äh, ändern sich
Change-Management
Die Zeiten, sie, äh, ändern sich

Einen Change zu wollen, gehört heute zum guten Ton in der Unternehmensführung. Doch ein erzwungener Wandel in der Firmenkultur löst oft keine Probleme und schafft sogar neue.
Ein Erfahrungsbericht von Marvin Engel

  1. IT-Jobs Der Amtsschimmel wiehert jetzt agil
  2. MINT Werden Frauen überfördert?
  3. Recruiting Wenn das eigene Wachstum zur Herausforderung wird

Gemini Man: Überflüssiges Klonexperiment
Gemini Man
Überflüssiges Klonexperiment

Am 3. Oktober kommt mit Gemini Man ein ambitioniertes Projekt in die deutschen Kinos: Mit HFR-Projektion in 60 Bildern pro Sekunde und Will Smith, der gegen sein digital verjüngtes Ebenbild kämpft, betreibt der Actionfilm technisch viel Aufwand. Das Seherlebnis ist jedoch bestenfalls komisch.
Von Daniel Pook

  1. Filmkritik Apollo 11 Echte Mondlandung als packende Kinozeitreise

Minecraft Earth angespielt: Die Invasion der Klötzchen
Minecraft Earth angespielt
Die Invasion der Klötzchen

Kämpfe mit Skeletten im Stadtpark, Begegnungen mit Schweinchen im Einkaufszentrum: Golem.de hat Minecraft Earth ausprobiert. Trotz Sammelaspekten hat das AR-Spiel ein ganz anderes Konzept als Pokémon Go - aber spannend ist es ebenfalls.
Von Peter Steinlechner

  1. Microsoft Minecraft hat 112 Millionen Spieler im Monat
  2. Machine Learning Facebooks KI-Assistent hilft beim Bau von Minecraft-Werken
  3. Nvidia Minecraft bekommt Raytracing statt Super-Duper-Grafik

  1. Australien: "Wir bauen ein Netzwerk auf 7,7 Millionen Quadratkilometern"
    Australien
    "Wir bauen ein Netzwerk auf 7,7 Millionen Quadratkilometern"

    Der staatliche australische Betreiber NBN Co wehrt sich gegen das schlechte Abschneiden seines Netzes in Speedtest. Es gehe um mehr als MBit/s. Doch die Absage an FTTH hat das Projekt NBN weitgehend entwertet.

  2. Code-Hoster: Gitlab will nicht über Politik und Moral diskutieren
    Code-Hoster
    Gitlab will nicht über Politik und Moral diskutieren

    Die Diskussion um Geschäfte mit moralisch fragwürdigen Kunden will Code-Hoster Gitlab nicht führen und einfach alle Kunden akzeptieren. Den Angestellten werden zudem politische Diskussionen verboten.

  3. IT-Probleme: Serverausfall legt Produktion bei Porsche still
    IT-Probleme
    Serverausfall legt Produktion bei Porsche still

    Es sei kein Angriff aus dem Internet gewesen, sondern ein IT-Problem, erklärte Porsche. Rund 200 Server sind am 15. Oktober ausgefallen - die Bänder in mehreren Werken standen still.


  1. 14:43

  2. 14:18

  3. 13:53

  4. 13:17

  5. 12:55

  6. 12:40

  7. 12:25

  8. 12:02