Bitmap hochauflösend verkleinern
-
- Wenn wir noch ein paar gute Grafiker gewinnen wollen, müssen wir gute Grafik vorzeigen können. Klingt sicher pervers, ist aber völlig klar. Also ist der olle Omega brutal und versucht das notwendige, auch wenn er weder Talent noch das richtige Werkzeug hat. Denn Aufgeben gilt nicht, dafür ist die Story zu ultimativ, die Crew zu gut. -
Ja, ich möchte immer noch Bitmaps verkleinern. Aber so, als wäre die Screenauflösung ca. 2 Stufen höher gestellt. Also Bitmapverkleinerung bei gleichzeitiger Pixelverkleinerung.
Bisher hab ich nur den möglichen Ansatz. Start-Image läd das Bild. Eine SpeicherBitmap übernimmt es und soll es incl. der Pixel verkleinern. Ziel-Image zeigt das Ergebnis, von da aus wird gespeichert.
Hab niemals Code für sowas gesehen. Die Hilfe scheint da aufzuhören, wo ich starten muß. Ich denke ScanLine (sowieso), vielleicht PixelFormat? Ich schreib es gern im Array. Hab aber noch keine Syntax, die ich anwenden könnte. Keinen Plan, wie ich überhaupt drankommen kann.
-
Original erstellt von <Omega-X>:
Hab niemals Code für sowas gesehen.Kein Wunder, soetwas wie "Pixelverkleinerung" gibt es nicht.
Ein Pixel ist ein Pixel ist ein Pixel.Wenn du ein Bild verkleinern willst musst du dessen Pixelzahl reduzieren, dabei gehen notwendigerweise Informationen verloren. Um die scheinbare Qualität des Bildes zu erhalten musst du interpolieren, das bedeutet, aus einem bestimmten Bereich des Originalbildes einen Durchschnittsfarbwert zu errechnen und diesen dem entsprechenden Pixel im Zielbild zuzuweisen.
-
Wenn ich in einem Malprogramm Pen->Width nicht als absolute Zahl sondern als Berechnung setz, zB. Pen->Width = 1/100*25, mal ich 4 kleine Px in ein normales, kann es so speichern und auch so wieder laden. Die Screenauflösung macht ja etwas in der Art, nur eben global.
In Grafikprogrammen interpoliert man, weil man das Format erhalten muß. Das Format bestimmt die Pixel-Größe. Fotorealistische Formate lösen feiner auf. Auch in Spielen wird es manchmal verwendet. Das fällt eigentlich erst auf, wenn man ScreenShots vergrößert und sie mit üblichen Bildern vergleicht. Mir genügt es als BMP-Format, weil ja nur das unterstützt wird.
Wenn ich zB. ScanLine dazu bringen kann, das Bild px für px in der Wunsch-Pixelgröße zu malen, könnte es klappen können. Andernfalls eben Pg.
-
Es gibt keine "Wunsch-Pixelgröße", der Pixel ist die kleinste darstellbare Einheit.
Entschuldige bitte, aber du hast offensichtlich keine Ahnung (oder eine komplett falsche Auffassung) vom Zusammenhang zwischen Pixeln und Auflösung.
-
Ahnung hab ich wirklich nicht. Das sind nur Beobachtungen. @Jansen, ich will dir auch nicht wiedersprechen, vielleicht muß es nur anders benannt werden. Auf jeden Fall hab ich real schon mit utopisch kleinen Pixeln gemalt. Als eigenständiges Bild oder innerhalb von "normalen" Bildern.
Mag sein, daß das Pseudopixel sind. Die in den Spielen und in hochauflösenden Fotos dann aber auch. Auf jeden Fall geht es manuell. Der BCB ünterstützt sowas nicht als Format, das will dann den Eindruck vermitteln, daß es das auf der ganzen Welt nicht gibt.
Was ist TBitmap::PixelFormat?
ShowMessage(pBitmap->PixelFormat);
6
Als int kann ich es nicht schreiben. Wie definier ich einen anderen Wert, um zu sehen, was dadurch verändert wird?
-
Nur mal so eine Defintionsbeschreibung:
Was ist ein Pixel?
Ein Computer speichert ein Bild als eine Kombination kleiner, farbiger, rechteckiger (oder quadratischer) Punkte, die Pixel genannt werden. Die Farbe der Pixel geben den durchschnittlichen Farbton, die Sättigung und die Helligkeit des Bereiches auf dem Original wieder, den der Pixel abdeckt.
Genauer gesagt, je mehr Pixel zur Bildbeschreibung genutzt werden, desto mehr Details können dargestellt werden. Sobald ein Bild mit einer bestimmten Auflösung auf dem Computer abgelegt ist (etwa mit einer bestimmten Anzahl an Pixel), sind die Details des Bildes festgelegt und können nicht erhöht werden. (Die Zahl der Pixel kann durch einen mathematischen Prozess, der Interpolation, erhöht werden. Dadurch werden aber nicht mehr Details dargestellt, sondern lediglich Pixel rechnerisch hinzugefügt, um den Übergang zwischen den Originalpixel weicher zu machen.) Der Wert jedes Pixels (Farbton, Sättigung und Helligkeit) wird normalerweise in drei 8-Bit Binärzahlen (Werte von 0 bis 255) gespeichert und zwar in je einer für die Primärfarben des Lichtes Rot, Grün und Blau. Daraus ergibt sich ein möglicher Farbumfang von 256 x 256 x 256 (16,8 Mio.) Farben für ein sogenanntes 24-Bit Farbbild.
Quelle: http://www.nikon-euro.com/nikoneuro_de/faq/general/de/FAQ_gen_de_9.htm
und
Pixel
(= Bildpunkt)
Ein Pixel ist die kleinste darstellbare Grafikeinheit, die ein Computer darstellen kann.Es ist ein Quadratischer Punkt auf dem Bildschirm, aus denen sich dan mosaikförmig ein Bild zusammensetzt. Man unterscheidet zwischen der horizontalen und der vertikalen Ausrichtung. 640 x 480 Pixel heißt, daß das Bild in jeder Zeile der Horizontalen (-) aus 640 einzelnen Punkten zusammensetzt. Das ganze hat dann in der Vertikalen ( I ) 480 Zeilen. Das sind dann insgesammt 307200 einzelne Bildpunkte.
Hier mal ein grobes Beispiel, wie man aus einzelnen Quaraden eine Form gewinnen kann. Hier wurden mit 12 x 7 Bildpunkten das unterstrichene Wort Bug dargestellt. würde man mehr Bildpunkte verwenden, würde das Wort deutlicher und feiner werden.
mfg
Steffen
[ Dieser Beitrag wurde am 15.01.2003 um 11:44 Uhr von skho editiert. ]
-
Original erstellt von <Omega-X>:
Was ist TBitmap::PixelFormat?Wie wär's mit einem Blick in die Hilfe?
-
Na wenn da keine klaren Aussagen drinstecken... Dank dir, @skho. Man darf dabei den Begriff "Einheit" nicht mit dem Wert der Einheit gleichsetzen. Die zoomende Canvas zeigt deutlich, daß die Größe der Einheit "Pixel" relativ ist, was in der oberen Definition auch besser nachvollziehbar dargestellt scheint. Eine reale Begrenzung der Darstellbarkeit ist zB. durch die Bildschirmmaske gegeben. Meine Ausführungen zu den 4 kleinen Px in einem "normalen" sind jederzeit reproduzierbar.
@Jansen, dank dir sehr für deine Anregung. Hab die Seite sowieso geöffnet, denn ich will es rausfinden.
"Die Eigenschaft PixelFormat legt fest, in welchem Bit-Format das Bitmap-Bild angezeigt wird.
__property TPixelFormat PixelFormat = {read=GetPixelFormat, write=SetPixelFormat, nodefault};
Beschreibung
Mit PixelFormat können Sie das interne Bild des Bitmaps auf ein bestimmtes Speicherformat oder eine bestimmte Farbtiefe setzen, oder ermitteln, welches Speicherformat und welche Farbtiefe ein TBitmap-Objekt verwendet. Dazu wird meist ScanLine abgefragt, da der Quelltext die Pixel-Daten, auf die ScanLine zugreift, decodieren muß. Bildbearbeitungsprogramme verwenden normalerweise ein Pixel für alle internen Bildoperationen und kopieren zum Schluß die Ergebnisse auf den Bildschirm (in jedem beliebigen Format).."
Also der olle doofe ich kann daraus gar nichts entnehmen. Liegt natürlich an der fehlenden Erfahrung. Irgendwann lern ich es sicher, Syntax zu lesen. Ich will PixelFormat (hier für pBitmap) definieren, es gelingt aber nicht. Wär für Hilfe wirklich sehr dankbar.
-
PixelFormat:
Dies ist eine Angabe dafür, wieviele Bits verwendet werden, um ein Pixel zu speichern. Beispiel: PixelFormat = 4. Dann haste 4 Bit, um ein Pixel zu speichern, d.h. 2^4 = 16 Möglichkeiten, d.h. 16 Farben. Je weniger Bits du für ein zu speicherndes Pixel verwendest desto kleiner ist natürlich die Farbauflösung.
Um im BCB TBitmap::PixelFormat zu ändern gibt es die Konstanten pf8bit, pf16bit usw., die in einem enum zusammengefasst sind (schätz ich mal).Auflösung:
Meine Auflösung ist 1152 x 846 Pixel. Das heißt, auf meinem Bildschirm finden bei der aktuellen Einstellung 1152 * 846 Pixel Platz. Der Bildschirm erstellt ein Raster für diese Pixel. Dieses Raster ist auf dem ganzen Bildschirm das gleiche. Wenn ich die Auflösung auf 600 x 800 ändere, dann erstellt der Bildschirm ein neues Raster mit 600 * 800 "Kästchen", von denen in jedem genau ein Pixel Platz hat.
Natürlich kannst du intern mit 4-tel-Pixeln arbeiten, aber so ein 4-tel-Pixel kannst du auf dem Bildschirm nicht darstellen. Du musst irgendwie den Mittelwert der 4 Farben ermitteln (oder so ähnlich) und kannst ein Pixel mit dieser Farbe auf dem Bildschirm darstellen.
-
Aaach, jetzt wird der Sinn von PixelFormat transparent. pf24bit schreibt man also. Aber die Eigenschaft des Bildes will ich ja jetzt nicht ändern. Für's Malprogramm wird deine info aber hochinteressant. Muß ich gut aufheben, da ich da später auch weitermachen will.
Das mit der Bildschirmauflösung versteh ich voll. Aber weißt du, was fies ist? Ich konnte wirklich kleinere Pixel malen und hab die einwandfrei gesehen. War natürlich nur interessehalber. Zum Retuschieren muß man im Format bleiben.
Also das ist nicht nur so daherphantasiert sondern es geht defakto. Wer mit sowas experimentieren will oder es gar braucht, NULL Problemo. Nur eben nicht die Pen->Width auf 0.5 setzen sondern eine 1/... Berechnung. Nur so geht es ohne Fehlermeldung durch.
Und nur aus dieser Erfahrung entstand die Idee, das nun auch an vorhandenen Bildern zu versuchen. Ein Bild einlesen, dann bearbeiten und ausgeben lassen. Wär das nicht auch ansich immer mal wieder interessant, über feiner aufgelöste Miniaturen verfügen zu können? - Zum Wüstenfuchs, was ich mit der Hand malen kann, darf doch auch in der Speicherbitmap klappen. :p
-
Also das ist nicht nur so daherphantasiert sondern es geht defakto. Wer mit sowas experimentieren will oder es gar braucht, NULL Problemo. Nur eben nicht die Pen->Width auf 0.5 setzen sondern eine 1/... Berechnung. Nur so geht es ohne Fehlermeldung durch.
So ein Blödsinn!!! TPen::Width ist ein int, also eine ganze Zahl. Brüche sind nicht erlaubt, und wenn du doch einen angibst, wird dieser in die ganze Zahl umgewandelt, die vorm Komma steht. Deine Zahlen werden zu 0. Aber wenn du TPen::Width auf 0 setzt, wird das nicht anerkannt und 1 angenommen. So ist das! Die Pixels sind nicht kleiner! Versuch mal sowas wie:
Canvas->PenPos = Point(10, 10); Canvas->Pen->Width = 1; Canvas->LineTo(200, 10); Canvas->PenPos = Point(10, 20); Canvas->Pen->Width = 1/2; Canvas->LineTo(200, 20); Canvas->PenPos = Point(10, 30); Canvas->Pen->Width = 0; Canvas->LineTo(200, 30);
-
Jetzt ungeprüft, ich muß es erst wieder bauen:
Control->Canvas->Pen->Width = Control->Canvas->Pen->Width / 100 * 25;
Ich glaub, diese Rechnung mußte sein, sonst ging es wirklich nicht. Pen->Widt = 0 hab ich nie bekommen. Entweder Fehlermeldung oder eben die kleineren Pixel. Kann sein, daß bei der Operation Murks entsteht, aber laufen tut es. Speicherbar und wiederladbar ist es auch. Also reproduzierbar.
-
Ich glaube, ich lasse es sein. Du wirst es eh nie kapieren!
-
Naja! Eine Liniendicke, die keine Ganzzahl ist, kann schon Sinn machen. Damit wird man dann festlegen können, wie weit ein Pixel von der Ideallinie entfernt liegen kann, damit er noch zur Linie gezählt wird. Bei einer Liniendicke von 0.5 wird der Pixel wohl maximal 0.25 Pixel Entfernung von der Ideallinie haben dürfen.
Das sagt aber letztendlich nichts über die tatsächliche Liniendicke aus. Entweder, ein Pixel gehört zur Linie oder nicht. Somit hat die tatsächliche Linie (in x- und y-Richtung) immer ein Vielfaches eines Pixels als Breite.
Die Information der Liniendicke geht aber verloren, sobald die Linie gezeichnet ist, da die meisten Bildformate nur Pixel kennen und keine Linien. Wenn man also ein gegebenes Bild vergrößern oder verkleinern will, dann bringt es einem garnichts, wenn man vorher eine Linie in einer bestimmten Dicke gemalt hat. Beim Vergrößern sind nur noch Pixeldaten vorhanden. Keine Daten über die Linie.
-
"Ich weiß es nicht!" wäre ehrlich gewesen und hätte von Größe gezeugt.
Ich bedank mich noch mal für all eure Mühe und Geduld. Ich bin borniert genug, den Schrott hier jetzt aufzustecken. KASPERLETHEATER!!!!!
-
Original erstellt von <Omega-X>:
**"Ich weiß es nicht!" wäre ehrlich gewesen und hätte von Größe gezeugt.
**Eben das hätte ich mir von DIR gewünscht! Hast ja selber zugegeben, dass du keine Ahnung hast.
[ Dieser Beitrag wurde am 15.01.2003 um 19:05 Uhr von WebFritzi editiert. ]
-
Das ist der Knackpunkt, @Gregor. Manuell nehm ich die Maus und zeichne einfach in der eingestellten Liniendicke. Ich kann auch mit Liniendicken unter 1 komplette FillRect malen (als Beispiel). Da entsteht keine Unterbrechung zwischen den Teilpixeln. Nach deinen Ausführungen ist mir auch klar, warum. Geht also auch nicht unbedingt bei jedem Format, gut zu wissen.
Wenn es auch mit dem fertigen Bild gelingen soll, dann muß ich damit genau das gleiche tun, wenn es überhaupt einen Weg gibt. Pixel für Pixel übertragen. Also ScanLine, aber was damit tun?
@WebFritzi, hab mal einen Vorgang zur genüge komplett durchgezogen und such nach Ergänzungen. Wenn dann die Diskussionspartner so drangehen, als hättest du das gar nicht gesagt/erlebt, als wäre es unmöglich und Blödsinn, weißt du ungefähr, wie mir zumute ist.
Da es reproduzierbar ist, entsteht daraus keine Diskussionsbasis. Sondern jeder kann den Versuch wiederholen oder es lassen. Wenn es jemand wiederholt oder als gegeben akzeptiert, kann man weitersehen. Sonst halt nicht. Theorie kann empirische Erfahrung jedenfalls nicht wegwischen. Entweder ist die Theorie falsch oder unvollständig, oder die Erfahrung hat nichts mit der aktuellen Situation zu tun. Das wär dann zu klären.
-
Die angeblich nachvollziehbare "empirische Erfahrung" beruht auf einer Fehlinterpretation deinerseits, und trotz der wiederholten Erklärungsversuche der technischen Grundlagen bist du offenbar ausserstande, das zu verstehen. Deshalb gibt es eigentlich in der Tat keine Diskussionsgrundlage mehr.
Aber jetzt hast du ja ein neues "Opfer" gefunden; mal sehen, wie lange Gregor durchhält.
-
Eigentlich habe ich dem nichts mehr hinzuzufügen. Aber eines will ich doch noch sagen. Ich habe mir Mühe gegeben, dir etwas zu erklären(Auflösung / Pixelformat), und du schaffst es nichteinmal, das von mir gesagte auszuprobieren. Mal dir doch einmal 2 Linien. Eine mit Pen->Width = 1 und eine mit Pen->Width < 1. Dann wirst du schon sehen, dass die Liniendicke genau die gleiche ist. Es gibt keine dünneren Linien als mit Width = 1. Das geht doch garnicht! Wenn du das nicht begreifen willst, dann bist du einfach unverbesserlich und wirst es so noch sehr schwer im Leben haben.
-
Erfahrung interpretieren? Sollte man vermeiden. Technisches wissen sammeln und vielleicht verstehen ist besser. Alles andere macht, daß die Chaostheorie 200 Jahre später als möglich ihre offizielle Anerkennung fand, daß Handauflegen was bedeutet.
Und was heißt Fehlinterpretation? 4 Pixel sauber innerhalb eines Standardpixels verlangen doch nicht nach Interpretation. Auch beliebig gebrochene Werte sind möglich. Das ist einfach nur Realität. Interessant dabei ist, daß das auch beim Speichern erhalten bleibt. Das Format kann es also verarbeiten und erhalten. Bleibt da noch Luft für Interpretation? Es ist, es funktioniert, und damit zunächst mal gut. Für mich paßt das jedenfalls sauber in die gehörten Ausführungen rein.
Mit hoher Sicherheit werde ich das Ziel nicht erreichen können, da ich es aus eigenem Vermögen heraus nicht kann. Bereits das Nahziel, eine Speicherbitmap pixelweise ohne den dunklen Balken zu übertragen, scheitert ja bereits. Das schließt aber nicht aus, daß es nicht doch Wege gibt. Nur ich kann sie eben nicht gehen. Sonst nichts.