Autor | Thema: Bmp als TXT |
| Datum:06.07.02 15:46 
| |
mir ist gerade heute morgen mal ne komische idee gekommen:
man kann ja mit getpixel den punkt einer beispielsweisen BMP auslesen. wenn man nun jeden Punkt der BMP auslesen würde und nun diese ganzen koordianten in eine Txt schreibt, könnte man so doch bestimmt bilder sehr gut transportieren
natürlich braucht man dann auch ein Programm, das dann weiderum alle Angaben am Bild zusammensetzt.
ist sowas möglich?
|
|
| Datum:06.07.02 15:58 
(webmaster@rokosoft.de) | |
Hi
möglich ist vieles.
Hier Höhe und Breite des Bildes (in Pixel) auslesen,
dann in einer Schleife diese per Getpixel lesen und in eine
Datei schreiben.
Jedoch um diese wieder herzustellen müstest Du auch Zusatzinfos in der Datei speichern.
Höhe und Breite für die Wiederherstellschleife.
Ausserdem bestimmt noch einige andere Sachen, an die ich jetzt ausm Kopf nicht drauf komme :)
Ausserdem würde jedes Pixel als Rgbstring in der Datei stehen.
Nun halt die Frage:
Wofür sollte es gut sein, denn die erstellte Datei würde doch bestimmt größer als die vorhandene BMP-Datei?
Rolf
|
|
| Datum:06.07.02 17:41 
| |
das müsste halt herausgefunden werden, ich denke aber das wie du es schon erzählt hast, sehr gross sein wird :(
|
|
| Datum:06.07.02 20:31 
(schmidts@flat2serv.de) | |
Etwas anderes macht eine BMP Datei ja auch nicht, nur komprimierter. Nehmen wir an, Du möchtest die Zahl "230" speichern. Als Textdatei wären das schonmal 3 Byte (2,3,0), als binär Datei lediglich ein Byte mit dem Wert 230 (1 Byte = 0-255). Daher macht es wenig Sinn ...
Mfg.
Sven Schmidts
|
|
| Datum:06.07.02 23:48 
| |
Hallo,
binär wären es ebenfalls 3 Byte (bei einem 24 Bit-Bild). Ein Bmp gespeichert als Text wäre also ziemlich genau gleich so groß wie eine normale Bmp-Datei.
Allerdings würdest du für ein 1024 x 768 großes Bild 786432 mal GetPixel anwenden müßen, wie lange würde das in Profan dauern ?
Gruß, Frank
|
|
| Datum:07.07.02 11:42 
| |
ich denke bestimmt eine Minuten, bei einer schlechte Umsetzung, bis alle Pioxs gelesen sind dauert das ein wenig......
klar ist das keine gute idee, doch so kann man nebenbei auch dateien verschlüsseln und niemand kann was mit dem ganzen anfangen wenn er das sieht
mfg
|
|
| Datum:07.07.02 15:29 
(galaxy@mkk.de) | |
Das mit Get und Set Pixel zu machen, ist aber die schlechteste
Lösung. Schneller gets, die Roh-Daten aus der Datei selber
zu nehmen und in ASCI Zeichen umzusetzen / zu Codieren,
dauert mit Profan zwars auch bei einem ca 500 KB Bild
so 20 Secunden, aber schneller als "Pixeln" ist es allemal.
Übrigens ist in der Crypt.DLL so eine Funktion eingebaut,
wo Binär Daten in ASCII Zeichen umgesetzt werden, allerdings
wird die Datei dabei etwas grösser ....
|
|
| Datum:08.07.02 08:18 
(schmidts@flat2serv.de) | |
Vielleicht ne dumme Frage, aber willst Du Rohdaten als ASCII haben? Hat doch keinerlei Vorteile ...
|
|
| Datum:08.07.02 12:27 
(uwe.beisler@t-online.de) | |
Wenn man darüber nachdenkt wofür sollte das gut sein kommt man oft nicht drauf. Ich habe gerade einen ähnlichen (exotischen Fall) bei dem ich die Konvertierung allerdings nur zur Generierung von Dateinamen (beim Erstellen und beim Lesen) nutze.
Mein Verhältniss ist 15 Bit : 3 Zeichen.
Ich nutze die 26 Buchstaben und 6 Ziffern => 32 Varianten.
Mit 3 Buchstaben habe ich also 32*32*32 = 32768 Varianten.
Wer kein True-Color braucht kommt damit vielleicht hin.
Wenn man alle Ziffern und die in Frage kommenden Sonderzeichen nutzen würde käme man nätürlich auf bessere Werte. Man muß ja nicht unbedingt immer alle alle Möglichen Varianten nutzen.
In einem 2048 * 2048 Pixel großen Bild gibt es maximal 4 Millionen verschiedene Farben. Das menschliche Auge kann max. ca. 2 Millionen unterscheiden. Es gibt von daher also keinen Grund die 24-Bit oder 32-Bit auszunutzen. Wenn man von 20 Bit (als ca. 1 Mio.) ausgeht schafft man die Info nach der oben beschriebenen Methode auch ohne Optimierung in 4 Zeichen :
32 * 32 * 32 * 32 = 1 048 576 Varianten.
Uwe
|
|
| Datum: 08.07.02 13:12 
| |
Klar wäre das sehr langsam, da meistens nur eine Funktion die pixel abfragt und die infos speichert, würde man aber beispielsweise bei der bmp beginnen, unten und oben die pixel auszulesen, also an zwei stellen damit beginnt, würde sich die zeit schon verringern, ich denke wenn es von der größe her gleichbleiben würde, wäre es doch eine gute verschlüsselung vom bilder möglich, wenn natülrich nicht die lange ermittlung der pixel wären........
mir ist ds schon aufgefallen bei dem quellcode, mit dem sich bmp bilder in schwarz-weis, grau oder auch weichzeichnen lassen, hierbei ist die ladezeit ernorm.......
|
|