Bitmap hochauflösend verkleinern



  • 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.



  • Da wär ich nicht so sicher, daß ich das nicht mach, @WebFritzi. Ich weiß, daß ich genau das jetz mit Ruhe aufbau, denn jetzt hab ich Bedarf dafür. Ob es geht oder nicht, darüber brauch ich mir nicht mehr den Kopf zerbrechen. Hab es schon vor Jahren wirklich ausgiebig getestet. Hatte es in die mitwachsende Lern-Multi-Aufgaben-MDI integriert (was in dieser Multiart Quatsch ist, weil es todsicher instabil wird) und immer wieder damit expirimentiert. An dieser Realität gibt es überhaupt nichts zu klingeln. Eine ListBox mit verschiedenen Werten, von starken +Größen bis runter in den Extremen Bereich. Unter 1/3000 kam dann mal die Meldung "Der Parameter stimmt nicht". Ansonsten kann ich frei beliebig große Pixel ineinander malen. Und nicht nur auf einer imaginären Linie. Ich kann geschlossene Flächen aus diesen Kleinteilen aufbauen.

    Ja was brauch ich denn noch? Ja richtig. Das ganze vielleicht mal auf ScanLine-Basis, um die Möglichkeit bei fertigen Bildern zu proben. Vielleicht irgendwann. Heute bin ich noch zu doof dazu - vielleicht bleibt das auch so. Aber die Hoffnung auf Hilfe hab ich aufgegeben. Die Möglichkeit scheint für andere obstrus zu sein. Sie würden sich also niemals dafür interessieren. Das ist auch in Ordnung so. Nur mir ungeprüft ausreden, was Wahrheit ist... na ja, auch recht. Das ist das geringste Prob.

    --Karamba, die Argumentationen sind immer noch so, als würde ich mir das aus den Fingern saugen. Als hätte ich es nie wirklich praktiziert, würde es nur behaupten. Das kapier ich nicht, muß es aber akzeptieren.



  • Also, ich zweifele jetzt wirklich daran, dass du das Ganze hier ernst meinst. Vielleicht willst du uns alle nur zum Narren halten?! OK, nochmal ein kleiner Versuch, dich doch noch zu überzeugen. Mach dir eine ListBox mit Height = 1 und eine mit Height = 1/2000 direkt nebeneinander. Dann machst du dir einen Screenshot. Schau dir das Ganze in Paint an und benutze die Lupe. Du wirst sehen: Beide ListBoxen sind gleich groß! Nämlich genau 1 Pixel.



  • OnShow der App:
    ListBox2->Height = 1/100*99;
    genügt, und sie ist weg, ganz ohne Rand. Auch als 0.99 geschrieben ist das so. Hab den Shot im IrfanView maximal vergrößert, die zweite bleibt verschwunden.

    Das wär der Beweis dafür, daß Werte unter 1 auf 0 gehen, ohne Rundung. Aber die ListBox war verschwunden, nicht ein Pixel.

    Hast du den Versuch mal mit Pixeln gemacht? Dann wirst du nicht mehr rätseln müssen. Für mich ist das Thema sowieso selbstverständlich. Und du weißt auch definitiv, daß ich niemanden auf den Arm nehme. Der Versuch ist zu simpel nachvollziehbar.

    Warum halten wir uns also über selbstverständlichkeiten auf, die jeder kennt? Das kann ich jetzt nicht unterbringen. Als ich sagte, der ScanLine-Versuch bringt einen dunklen Balken, kam kein Echo dazu. Aber hier hab ich doch einen Fehler gemacht, der mich definitiv am Weiterkommen hindert. Ich wollte wirklich mal wissen, was man mit ScanLine machen kann. Aber immer nur "kleiner geht nicht". natürlich geht's, kein Thema. Wen interessiert das? Wer fragt danach vor dem Versuch? Ich bin es gewöhnt zu handeln, wenn ich es für richtig halte. Und sei es drum, eine Theorie zu bestätigen. Gerade sowas find ich übrigens interessant.

    Zermürben? Irgendwann geb ich ja auf? Der Vorteil wär, daß nicht ermittelt wird, ob es auch mit einer SpeicherBitmap geht. Der Gag dabei: Wenn es geht, sind tolle Möglichkeiten realisierbar. Und das will niemand rausfinden? Anns? Vor wem? Vor was? Vor sich selbst? Vor der Selbstverständlichkeit, daß man mal nicht alles wußte?... Was ist Trumpf? Alles wissen? Oder alles lernen können? Also ich komm nicht mit.


Anmelden zum Antworten