In gezoomtes TImage pasten

WebFritzi

Bis zum letzten Absatz ist dein Beitrag und deine Beschreibung völlig OK. So wünscht man es sich. Super, dachte ich. Nur dann der letzte Absatz. Was ist der "logische Platz" und der "physikalische Platz"??? Versuche, auf solche Blödsinns-Ausdrücke zu verzichten. Der Helfer hat so keine andere Wahl, als die Ausdrücke zu deuten und zu interpretieren. Ich interpretiere das mal so: Das Paste-Image befindet sich über dem Image genau dort, wo es sein soll. Nun soll der Inhalt des Paste-Images in das Image genau an dieser Stelle kopiert werden. Ist das so richtig?? Wenn ja, dann verstehe ich nicht, warum dein "Algorithmus" von oben (erster Beitrag) nicht funktioniert. Er muss funktionieren!
Mir ist da noch was aufgefallen:

Die Positionsberechnung bezieht sich auf die Form.

Das Image befindet sich in einer ScrollBox, richtig? D.h., die Eigenschaften Left und Top beziehen sich auf die ScrollBox und nicht auf die Form.

[EDIT] Jau, das muss der Fehler sein! Du musst darauf achten, dass das PasteImage und das Image das gleiche Parent haben - in diesem Falle die ScrollBox. [/EDIT]

[ Dieser Beitrag wurde am 09.03.2003 um 13:21 Uhr von WebFritzi editiert. ]

DerAltenburger

Hi Omega-X

Folgende Ueberlegung:

Dein FImage wird z.B. mit VFac=0.5 angezeigt.
  Das 'gepastete' Image skalierst Du gleich.
  ->In Scrollbox (Am Bildschirm erscheinen beide in halber Groesse!!!

  Das 'gepastet' Image positioniers Du z.B. 50 Pixel weiter rechts (DX)
  und 100 Pixel tiefer (DY).
  ->Auf FImage- Inhalt bezogen macht das das Doppelte (VFac!!!) ;) 
    ->DRect->Left muss 2x50 =100 sein
    ->DRect->Top  muss 2x100=200 sein.

:::Positionsdifferenzen muessen DURCH VFac DIVIDIERT werden!!!(typecast nach double nehmen!!! :D 

:::Die Groessenskalierung muesste mit 1:1 OK sein (das machen die gezoomten Images!)

Ja, hab inzwischen auch gemerxt, die ScrollBox liefert als fensterorientierter Parent den Koordinatenbezug. Wußte ich noch nicht, das stört hier aber zT. kollossal. Die Berechnungen beziehen sich auf den sichtbaren Bereich der ScrollBox. Mit den Zeilen

MarkBase->Left = Image->Canvas->ClipRect.Left;
MarkBase->Top = Image->Canvas->ClipRect.Top;

wird MarkBase Top/Left in der ScrollBox positioniert, nicht Top/Left über dem Image (versteh aber nicht, warum, die Anweisung scheint klar zu sein). Usw. Ich bekomm nie einen immer richtig arbeitenden Algor. Probs hab ich auch, die Strecken außerhalb und innerhalb des Image zu berechnen. Beim Wechsel der Vergrößerung kann ich ua. die Position den MarkBase-Image nicht halten.

@WebFritzi, die Begriffe "logisch" und "physikalisch" hab ich aus dem Buch "C++ Builder3 im Team, C&L". Muß ich akzeptieren, daß die Begriffe nicht allgemein gebräuchlich sind, sorry.

@DerAltenburger, die Methode, mit festen Werten je Faktor zu arbeiten, muß ich probieren. Das ist immer genau, eine Division nicht unbedingt. ... Hey, erst beim 2. Lesen seh ich, daß mit (DX) und (DY) alles fein normierbar aufgebaut werden kann. Ein Bedingungssatz statt der Division, das wird exakt.

Du schlägst sogar double vor, nicht float? float sollte weit mehr können, als ich in einem (größeren) Bild benötige. Aber einfach mal checken... Aber s.O., ich seh so aus, als ob mir das viiieel besser gefällt. :p

Bei 1:1 hab ich keine Probs.

Ole, war dann auf eine andere Basislösung gekommen, bei der die Probs vermieden werden. Ich leg die beiden TImage's Image und MarkBase auf einem Panel ab. Das Panel paßt sich bei jeder ändernden Operation dem Image an. Damit hab ich einen eindeutigen Bezug für alle Operationen. Jetzt kann ich so scalieren, wie es auch beim Malen klappt. - Muß aber noch den Code gründlich durchgehen und alles anpassen. Ich denk, damit sollte ich aus dem Schneider sein, ich sag dann bescheid.

<edit>Es wird wirklich interessant sein, wenn alles stimmt, aus dem Aufbaukomplex eine Kompo zu machen. Aber Operationen würde ich nicht mit reinnehmen. Nur die Methoden wie zB. Canvas->LineTo..., aber auch zB. die Synchronschaltung von FImage und FPanel, die wahlfreie Zentrierung/Positionierung in der Scrollbox, ZoomHandling usw.</edit>

WebFritzi

MarkBase->Parent = ScrollBox;

DerAltenburger

@Webfritzi

Tust Du ueberhaupt wissen tun ueber was fuerne Komponente hier diskutiert wird?

WebFritzi

Ja. Über deine tolle Komponente, du Angeber.

DerAltenburger

Dann haeteste Dir Dein' vorletzten Beitrag sparen koennen!

PS: Den letzten auch! :p

[ Dieser Beitrag wurde am 09.03.2003 um 22:44 Uhr von DerAltenburger editiert. ]

WebFritzi

Wir hätten uns beide die letzten Beiträge sparen können, wenn du hier nicht so geheimnisvoll darüber reden würdest. Nun mal raus damit.

DerAltenburger

@WebFritzi

Fuer Dich blinden Uhu nochmal langsaaaaaaaaam!:

Lies den Beitrag 'Bild- Viewer Problem' von <GOMEZ> vom 2.3.2003 nochmal genau durch! Dann kannste vieleicht mitreden, was hier gebastelt wird.

DAS WIRD DIE FORTSETZUNG!!!

War das langsaaaaaam genug?

PS: Haettest Du damals mitgelesen und nicht nur 'Reingequatscht, gaeb's nun kein Problem!

[ Dieser Beitrag wurde am 09.03.2003 um 23:10 Uhr von DerAltenburger editiert. ]

WebFritzi

Original erstellt von DerAltenburger:
Haettest Du damals mitgelesen und nicht nur 'Reingequatscht, gaeb's nun kein Problem!

*vogelzeig* Du tust ja gerade so, als wäre deine blöde Kompo diejenige, zu der man sich jeden Thread anschauen muss. Ich hab anderes zu tun und bastel lieber an guten Kompos.

Jansen

Verwarnung an DerAltenburger und WebFritzi, bitte sachlich und beim Thema bleiben!

:p ... Wer haut sich denn schon um gute Kompos?. Das lohnt sich höchstens um die goooilste Kopmo. Und das kann daauuuern.

Schluß mit Peter Lustig , Image liegt also zentriert in der ScrollBox auf einem identisch justierten Panel. Parent von MarkBase ist auch das Panel. Das Bild von MarkBase wird jetzt richtig ins Image eingefügt.

void __fastcall TPixi::MarkBaseImageMouseDown(TObject *Sender, TMouseButton Button,
            TShiftState Shift, int X, int Y)
{
    FDragging = false;
    // double wäre gar nicht nötig, hab keinen Unterschied entdeckt
    MarkBase->Left = (int)((double)MarkBase->Left/VFac);  
    MarkBase->Top = (int)((double)MarkBase->Top/VFac);
    DRect.Left = MarkBase->Left;
    DRect.Top = MarkBase->Top;
    DRect.Right = MarkBase->Left+MarkBase->Width;
    DRect.Bottom = MarkBase->Top+MarkBase->Height;
    Image->Canvas->CopyRect(DRect, MarkBase->Canvas, MarkBase->ClientRect);
    MarkBase->Hide();
    MarkBase->Picture = NULL;
    MarkBase->Width = 1;
    MarkBase->Height = 1;
    DRect = Rect(0,0,0,0);
}

Bei +Zoom klappt es, bei -Zoom wird das eingefügte Bild proportional kleiner. Klar, Bildinfos gehen verloren. Pasten wird also erst ab 100% Sinn machen, darunter werd ich die Function sperren.

Vorher wurde MarkBase verschoben:

/* Im MarkBaseMouseDown:
(int - global) markleft = X, marktop = Y;
void __fastcall TPixi::MarkBaseMouseMove(TObject *Sender,
            TShiftState Shift, int X, int Y)
{
    Screen->Cursor = crHand;
    if(Shift.Contains(ssLeft))
    {
        MarkBase->Left = MarkBase->Left + X - markleft;
        MarkBase->Top = MarkBase->Top + Y - marktop;
        /* Zu brutal, bin mit einem Schlag an der Scrollgrenze.
           Suche was besseres */
        // ScrollBox->ScrollInView(MarkBase);
    }
}

Bei Vergrößerungen wird weiterhin nach Canvas-Pixeln verschoben. Die Bild-Pixel sind größer, ich kann also auch auf Zwischenpositionen verschieben. Beim Einfügen wird dann auf das nächstgelegene Pixel in Top/Left-Richtung korrigiert. Ob sich das noch verbessern läßt? Ich wollte im jeweils aktuellen Bildpixelraster verschieben können. Mir fällt im Moment kein Algor ein. Hat jemand 'ne Idee?

*Bin geleidigt* Der BCB3 kennt kein DoubleBuffered. Aber ich verschieb hier ein gezoomtes TImage in einem gezoomten TImage. Da hat der das zu kennen! :o Oder auf hochdeutsch: Je gezoomt, desto langsamere Refreshrate. Das Flickert wie'd Sau.

Genügend Threads, einiges probiert, es will nicht besser werden. Hab trotzdem eine Lösung:

if(Shift.Contains(ssLeft))
    {
        MarkBase->Refresh();
        MarkBase->Left = MarkBase->Left + X - markleft;
        MarkBase->Top = MarkBase->Top + Y - marktop;
        MarkBase->Refresh();
    }

MarkBase läuft jetzt schön glatt. Der Preis: Image refresht während dem Verschieben des MarkBase nicht, das Bild wird total zugeschmiert, bis ich das Verschieben kurz unterbreche.

Gibt es da noch einen Trick? Bzw, wäre ggf. für das DoubleBuffering eine Bibliothek einzubinden, die man irgendwo bekommen kann - BCB3-kompatibel natürlich?

DerAltenburger

Hi

: Das mit dem double ist nur 'ne Angewohnheit , float geht auch (mit double sind Rundungsfehler geringer)

:Was bedeutet 'bei -Zoom wird Bild kleiner'? Es muesste kleiner angezeigtwerden.
Die Proportion zum Ausgangsbild muesste bei jedem Zoom stimmen?
:Beim Verschieben soll sich das Paste- Bild am Pixelraster des Ausgangsbildes orientieren?

->Berechnete Position (Anzeigepixel) 'hochrechnen' auf Originalmassstab, runden auf Ganzzahl (BildPixel), wieder 'runterrechnen'.(Dann muesste das beim Schieben mit z.B. 200% Zoom in 2xPixel- Schritten einrasten)

Das mit dem Flackern ist echt Mist! Ist nur bei 100% Zoom ertraeglich und bei nicht zu grossen Bildern.

->eventuell besser:

Ausgangsbild und 'gepastetes' Bild in eigenes Bitmap speichern(Offscreen)
  Bei Bewegung beide in weiteres Bitmap 'mischen'
  Gemischtes Bitmap in Anzeige zeichnen
  : etwas aufwaendig!
  (Ausgangsbild koennte auch aus TImage benutzt werden (unsichtbar!).
  Anzeige in anderes TImage, wie beim malen)
  :Mischen nicht in der Anzeige selbst machen(Flimmert wie 's Tier)

Hai, schon wieder aktiv? Ich konnte gar nicht Stop machen. Mußte eben noch "Hilfslinie auf einem TImage" Hilfslinie auf einem TImage checken, war irgendwie Pflicht. Der Algor von @AndreasW gefällt mir echt. Mein Dank hier, denn im Thread gibt's nichts hinzuzufügen. - Das wird dann ein Fall für's 2. Image. Das bring ich erst rein, wenn alles mal so läuft.

Beim Zoomen wird das Bild nicht kleiner, als es soll. Aber das gepastete Bild ist deutlich kleiner als die Größe von MarkBase. Bei 25% Zoom schrumpft es etwa auf 1/4. Das sind also nicht die Bildinfos, wie ich erst dachte. Das Paste-Bild wird deutlich beschnitten.

Kann mir das jetzt nicht erklären. Der Effekt war ursprünglich nicht. Ich korrigier allerdings jetzt die Position von MarkBase, dann übertrag ich das DRect ohne Umrechnung. Nach meiner Logik solte das der simpelste und zuverlässigste Weg sein. Möglicherweise ist das der Fehler. Komisch ist nur, das müßte sich genauso auf Vergrößerungen auswirken, tut es aber nicht. Hier bin ich also noch am Rätseln.

Ungefähr versteh ich, wie du das mit dem Hochrechnen beim Rasterverschieben meinst. Bei 200% verschieb ich um 2^n, bei 500% um 5^n. Aber wie drück ich das im Code aus? Vielleicht so?:

if (fmod(MarkBase->Left,VFac) != 0)
        MarkBase->Left += (VFac-fmod(MarkBase->Left,VFac)); 
    if (fmod(MarkBase->Top,VFac) != 0)
        MarkBase->Top += (VFac-fmod(MarkBase->Top,VFac));

*Treffer... versenkt* - Komisch, erst durch deine Anregung kam ich drauf, obwohl ich die gar nicht so doll verstanden hatte. Der Effekt ist aber nicht neu.

Jetzt noch das Mischen. Uff... ist weder Wodka noch Martini drin. Aber einfach mal drangeh'n...

Für das AutoScrollen, wenn MarkBase über Width/Height der scrollBox hinausverschoben wird, such ich immer noch eine gute Idee. Mit X, ScrollBox->Width, Position gelang nichts - sollte aber eigentlich (IMHO). Steh wohl auf der Leitung.

DerAltenburger

Du willst doch das 'Paste- Image' komplett einfuegen, oder nicht?

Das muesste ohne Rect's gehen. Mit Draw(...) nur linke obere Ecke angeben;was nicht in Ausgangsbild passt, wird abgeschnitten.

Oder soll Einfuegen mit anderem Faktor erfolgen (dann geht's so nicht)

Mit:
DRect.Right = MarkBase->Left+MarkBase->Width;
DRect.Bottom = MarkBase->Top+MarkBase->Height;
wird doch 'Zielrechteck' berechnet?

??? sollten Hoehe und Breite nicht in Original- Pixelgroesse vorliegen???
???MarkBase->Width ist aber doch die Abmessung des 'gezoomten' TImage ???

Ich denk, das muss skaliert sein (VFac)

[ Dieser Beitrag wurde am 10.03.2003 um 13:24 Uhr von DerAltenburger editiert. ]

Jau, Canvas->Draw ist die Lösung! Incl 1 TRect gespart. - Man soll ruhig probieren. Hatte geglaubt, sowas verändert die Picture->Graphic.

Via int fmodX,fmodY hab ich das Rasterverschieben jetzt eleganter geschrieben - je Achse nur eine fmod-Berechnung.

-Jetzt werd ich mich mal am umgekehrten Weg versuchen. Die Mark-Auswahl im Image sofort verschiebbar nach MarkBase Kopieren/Ausschneiden. - Daher hat das Teilchen den Name. -- Die Klasse wird umfangreich. :p <><> Baust du eigentlich auch weiter? Für vieles war ja nur der Ansatz vorhanden.

DerAltenburger

Ich bau nicht wirklich weiter!

Probier bloss gelegentlich 'n paar Grafikeffekte aus!

Interessant waer Nachladen von Bild mit Ueberblendeffekt??? (Hab' noch kein genauen Plan - wird nur mit Offscreen- Bitmap gehen)

PS: Bei weiteren Themenanfragen zu Deinem Projekt waer's guenstig, gleich genauen Zustand Deiner Grafik zu beschreiben! (Objekt = TImage, wo - in Scrollbox, Zustand ASutosize / Stretch), sonst weis niemand, was Du machst und kriegst nur Rueckfragen?

Ah ja. Nebel, Partikel, Spiegelungen, Durchdringungen... Interessanter Bereich.

Stell mir da ein Regiepult vor.

Bestimmte Farben transparent machen, mehrere Farben gezielt zur Transparentfarbe hinzunehmen. Beide Bilder übernanderlegen und probieren, bis der Effekt gut ist, dann capturen.

Oder aus beiden Bildern nach und nach bestimmte Farben in das Ergebnisbild übernehmen.

Eine Nebelfarbe definieren. Nach und nach Farben des Bildes in Richtung Nebelfarbe verändern oder (teilweise) nur die Sättigung in Richtung Sättigung der Nebelfarbe verändern. Grad dieser Effekt ist sicher mit recht einfachem Aufwand recht gut realisierbar. Was ich manuell mach, könntest du in gezielt aufeinanderfolgenden Schleifen auch automatisieren. Das würde sogar bessere Effekte erbringen, da man die Referenzfarben gezielt übergeben kann. Beispiel mit BrushCopy:

// im OnMouseDown
    pBitmap = new Graphics::TBitmap;
    pBitmap->Width = Image->Picture->Width;
    pBitmap->Height = Image->Picture->Height;
    pBitmap->Assign(Image->Picture);
    RefColor = Image->Picture->Bitmap->Canvas->Pixels[(X)/VFac][(Y)/VFac];
    Image->Canvas->BrushCopy(Image->Canvas->ClipRect, pBitmap,
                pBitmap->Canvas->ClipRect, RefColor);

    // im OnMouseMove
    /* Hier zieh ich einfach mit der Maus über das Bild,
       da, wo ich ändern will.
       Wirksamer wäre es, ein Punktearray zu übergeben.
       Bei meiner Methode bekommt man schnell große Farbflächen.
       Dieser Effekt wär bei dir grad unerwünscht. */
    pBitmap->Width = Image->Picture->Width;
    pBitmap->Height = Image->Picture->Height;
    pBitmap->Assign(Image->Picture);
    RefColor = Image->Picture->Bitmap->Canvas->Pixels[(X)/VFac][(Y)/VFac];
    Image->Canvas->BrushCopy(Image->Canvas->ClipRect, pBitmap,
                pBitmap->Canvas->ClipRect, RefColor);

    // im OnMouseUp
    delete pBitmap;
    pBitmap = NULL;

Ggf. auch mit verschiedenen Pen->Mode expirimentieren. Solche Sachen wie mpXor und pmNotXor nacheinander anwenden, dazwischen ggf. auch Pen oder/und Brush wechseln.

Ist sicher expirimental ohne Ende, zumal sich verschiedene Verfahren kombinieren lassen. Vielleicht läßt sich ein System erkennen, dann werden die Operationen gezielter. Das ganze würde erst mal an der hohen Farbzahl scheitern. Hier könnten Algors helfen, die ganze Farbbereiche durcharbeiten. Oder eben die Farbenzahl reduzieren.

Mehr fällt mir erst mal nicht ein. Im Offscreen-Bereich hat man sicher noch weitere Möglichkeiten. Filter für spezielle Offscreenformate wie .dib wären sicher interessant. Wenn jemand sowas entdeckt, das würde mich auch interessieren. Auf jeden Fall läßt sich der Feind einkreisen. - Grafik ist vielseitig und interessant, ähnlich wie Sound. :p

DerAltenburger

Ja, ja in der Art ..... (ohne Ende zu tun).

Viele Effekte moeglich. Aber wie?

Recht einfach:
Neues Bild d'rueberschieben
- Altes dabei ev. vornewegschieben
- Richtung waehlbar
Schon besser:
Bild von Zentrum aus langsam aufblenden / aufzoomen
Bild seitlich darueberblenden (ohne Schieben)
Sehr interessant:
Bild langsam hineindrehen (???)
- altes ev. vorneweg 'rausdrehen (???)
Bild langsam darueberkruemeln.
.
.
.
usw.

Da gehn die einfachen Tricks mit TImages nicht mehr gut!

In die Richtung will ich mal probieren. Denk aber im Moment nicht allzutoll darueber nach. Da sollte man 'n gutes Konzept machen, sonnst verzettelt man sich schnell.

PS: am besten in 'ner abgeleiteten Klasse. Nach totalem Verheddern hat man immer noch seine Alte.

[ Dieser Beitrag wurde am 10.03.2003 um 21:20 Uhr von DerAltenburger editiert. ]