Point() direkt auf Images?

Anfängerfragen zum Programmieren mit PureBasic.
Benutzeravatar
TomS
Beiträge: 1508
Registriert: 23.12.2005 12:41
Wohnort: München

Beitrag von TomS »

DarkDragon hat geschrieben:Zum verkleinerten/vergrößerten Zeichnen gibt es doch DrawImage(ImageID, x, y [, NeueBreite, NeueHöhe]).
Bringt nichts, denn:
spider84 hat geschrieben:Es gibt 2 Images: Ein Source mit dem geladenen Bild und ein Target, dass um 1 Pixel in der Breite schmaler ist (es ist ja ein verkleinerungs-algo). In einer zusätzlichen LinkedList steht für jede Zeile, welches Pixel im Target-Image weggelassen wird. Alle anderen Pixel sollen kopiert werden.
http://www.purebasic.fr/german/viewtopi ... 212#250212
spider84
Beiträge: 76
Registriert: 05.03.2008 03:06

Beitrag von spider84 »

glaube ich habe eine Möglichkeit gefunden. ich kämpfe praktisch "nurnoch" mit null-pointern bzw. schwarzen bildern...

http://www.purebasic.fr/english/viewtop ... point+plot
Benutzeravatar
cxAlex
Beiträge: 2111
Registriert: 26.06.2008 10:42

Beitrag von cxAlex »

DarkDragon hat geschrieben:Zum verkleinerten/vergrößerten Zeichnen gibt es doch DrawImage(ImageID, x, y [, NeueBreite, NeueHöhe]).
Die Befehle skalieren das Bild einfach, er will das so machen:

http://www.youtube.com/watch?v=qadw0BRKeMk
Projekte: IO.pbi, vcpu
Pausierte Projekte: Easy Network Manager, µC Emulator
Aufgegebene Projekte: ECluster

Bild

PB 5.1 x64/x86; OS: Win7 x64/Ubuntu 10.x x86
DarkDragon
Beiträge: 6291
Registriert: 29.08.2004 08:37
Computerausstattung: Hoffentlich bald keine mehr
Kontaktdaten:

Beitrag von DarkDragon »

cxAlex hat geschrieben:
DarkDragon hat geschrieben:Zum verkleinerten/vergrößerten Zeichnen gibt es doch DrawImage(ImageID, x, y [, NeueBreite, NeueHöhe]).
Die Befehle skalieren das Bild einfach, er will das so machen:

http://www.youtube.com/watch?v=qadw0BRKeMk
Und woraus aus dem Topic erkennst du das? Er hat das mit keinem Wort vor meinem Posting erwähnt.
Angenommen es gäbe einen Algorithmus mit imaginärer Laufzeit O(i * n), dann gilt O((i * n)^2) = O(-1 * n^2) d.h. wenn man diesen Algorithmus verschachtelt ist er fertig, bevor er angefangen hat.
spider84
Beiträge: 76
Registriert: 05.03.2008 03:06

Beitrag von spider84 »

ok, mein fehler!
aber man kann es indirekt erschließen, da ich beim standard-resize nicht wählen kann, welche pixel entfernt werden. deshalb schreibe ich ja einen eigenen resize-algo
DarkDragon
Beiträge: 6291
Registriert: 29.08.2004 08:37
Computerausstattung: Hoffentlich bald keine mehr
Kontaktdaten:

Beitrag von DarkDragon »

spider84 hat geschrieben:ok, mein fehler!
aber man kann es indirekt erschließen, da ich beim standard-resize nicht wählen kann, welche pixel entfernt werden. deshalb schreibe ich ja einen eigenen resize-algo
Naja, es gibt leute die fangen erstmal klein an, weißt du :freak: . Dann schreiben die sowas wie "Wie hole ich jeden Pixel aus dem Bild?".

Egal, du könntest ja alles mit Arrays lösen (Bild punkt für punkt zuerst in ein 2DArray legen bevor man mit dem Array arbeitet und danach wieder punkt für punkt in das Bild rein plotten), dann hast du schonmal keine doppelten Point()/Plot() calls bei mehrfachverwendung.
Angenommen es gäbe einen Algorithmus mit imaginärer Laufzeit O(i * n), dann gilt O((i * n)^2) = O(-1 * n^2) d.h. wenn man diesen Algorithmus verschachtelt ist er fertig, bevor er angefangen hat.
spider84
Beiträge: 76
Registriert: 05.03.2008 03:06

Beitrag von spider84 »

Naja, es gibt leute die fangen erstmal klein an, weißt du Freak . Dann schreiben die sowas wie "Wie hole ich jeden Pixel aus dem Bild?"
Hmm, ja - grundlegende Dinge frage ich auch gerne. Mir schien trotzdem das Anfängerforum für die Frage geeignet. Ich dachte nach einem schnelleren Point/Plot fragen sicherlich viele da es wirklich langsam zu sein scheint - und das ist mir auch früher schon bei andern Projekten aufgefallen. Dort konnte ich aber damit leben...
Egal, du könntest ja alles mit Arrays lösen (Bild punkt für punkt zuerst in ein 2DArray legen bevor man mit dem Array arbeitet und danach wieder punkt für punkt in das Bild rein plotten), dann hast du schonmal keine doppelten Point()/Plot() calls bei mehrfachverwendung.
Joa, auf den Trichter kam ich mittlerweile auch - obwohl ich nicht verstehe warum sowas schneller ist. Eigentlich müsste ja PB für Images auch intern 2d-matrizen bereitstellen und Point im Fall des Lesens aus einem Image (nicht aus einem Gadget oder so) die Speicheradresse schnell berechnen können.
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag von Kaeru Gaman »

das Problem ist nicht der Speicher oder sonstwas - es ist der Zugriff über den DeviceContext.
das ist nunmal schnarchelangsam, egal von welcher Sprache aus du diese Art Zugriff anwendest.

du kanst selbstverständlich den Header der Images interpretieren,
und mit diesen Informationen auf die eigentliche Bildmatrix zugreifen,
dann wirst du einen wesentlich (!) größeren Datendurchsatz erreichen.
und latürnich über API, ob das jetzt BitBlt war oder wie auch immer...
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
spider84
Beiträge: 76
Registriert: 05.03.2008 03:06

Beitrag von spider84 »

axo, das heißt das Image wird genau wie ein Gadget als "Device" angesprochen - und dafür wird in einer riesigen Liste des OS nach der Adresse geguckt. kann man das so auffassen?
schade, dass PB nicht erkennt dass es sich um Images handelt und direkt darauf zugreift
Benutzeravatar
Fluid Byte
Beiträge: 3110
Registriert: 27.09.2006 22:06
Wohnort: Berlin, Mitte

Beitrag von Fluid Byte »

spider84 hat geschrieben:schade, dass PB nicht erkennt dass es sich um Images handelt und direkt darauf zugreift
:roll:
Windows 10 Pro, 64-Bit / Outtakes | Derek
Antworten