Bug: GrabImage mit 1Bit BMP's

[Kukulkan]

Hallo,

Testcode:

Code: Alles auswählen

#Source = 1
#Dest = 2

#FileSource = "c:\testbild.bmp"
#FileDest = "c:\testbild_neu.bmp"

LoadImage(#Source, #FileSource)

StartDrawing(ImageOutput(#Source))
Debug "Farbe oben links 1: " + Str(Point(1,1))
StopDrawing()

GrabImage(#Source, #Dest, 0, 0, ImageWidth(1), ImageHeight(1))

StartDrawing(ImageOutput(#Dest))
Debug "Farbe oben links 2: " + Str(Point(1,1))
StopDrawing()

SaveImage(#Dest, #FileDest, #PB_ImagePlugin_BMP)

End

Problem:
Ist c:\testbild.bmp ein truecolor BMP Bild, dann ist alles ok.
Ist c:\testbild.bmp ein 1 Bit Schwarz/Weiss BMP Bild, dann ist weiss nicht mehr weiss!

Manchmal ist Weiss zu einem Grün geworden, manchmal auch zu Cyan.

Die fehlerhafte Routine ist die GrabImage() Routine (wie die Point() Ergebnisse zeigen)!

Benötige dringend einen Workaround!!!!!

Volker

[Kaeru Gaman]

probiersmal mit drawimage, vielleicht geht das besser

Code: Alles auswählen

CreateImage(2,...
StartDrawing(ImageOutput(2))
  DrawImage(1,...
StopDrawing

[Kukulkan]

Hi Kaeru,

Geht leider nicht, weil ich in meiner originalen Anwendung nur einen Ausschnitt aus der Originalgrafik benötige. Desshalb muss ich GrabImage() verwenden.

Im Original ist mein #Dest also nur ein Ausschnitt aus #Source. Hab das zur Nachvollziehbarkeit vereinfacht. Mit Drawing-Befehlen kann ich keinen Ausschnitt aus einem anderen Bild holen. Mit BitBlt_() hat es irgendwie nicht geklappt

Volker

[Kaeru Gaman]

> Mit Drawing-Befehlen kann ich keinen Ausschnitt aus einem anderen Bild holen.

doch.

mach das ziel so groß, wie es sein soll.
draw das source-image an die koordinaten -AuschnittX,-AusschnittY
dargestellt wird nur was du brauchst.
was du nicht brauchst, läßt du einfach überlappen.

[Kukulkan]

Hi Kaeru,

mach das ziel so groß, wie es sein soll.
draw das source-image an die koordinaten -AuschnittX,-AusschnittY

Das hat geklappt. Vielen Dank!

Aber ist das nicht Performance-Verschwendung? Oder ist DrawImage() so intelligent, dass es die Pixel nur für den Zielausschnitt kopiert (also vorher das Clipping berechnet)?

Ach ja - ein Bug ist es trotzdem...

Volker

[Kaeru Gaman]

> also vorher das Clipping berechnet
ja natürlich, sonst würde es ja zu einem IMA kommen,
wenn die routine versuchen wollte außerhalb des drawing-buffers zu zeichnen.

> Ach ja - ein Bug ist es trotzdem...

klar. @PB-Team bitte zur kenntnis nehmen.

aber cool, dass das "workaround" funzt.

[Kukulkan]

> also vorher das Clipping berechnet
ja natürlich, sonst würde es ja zu einem IMA kommen,
wenn die routine versuchen wollte außerhalb des drawing-buffers zu zeichnen.

Nicht so ganz selbstverständlich. Es gibt ja zwei Wege:

- Cliping berechnen und den zu kopierenden Ausschnitt vorab definieren um dann nur die betroffenen Pixel zu bearbeiten
- Jeden einzelnen Pixel durchgehen und jedesmal prüfen, ob er im Bereich liegt.

Zugegeben, das zweite wäre peinlich...

Volker

[Kaeru Gaman]

hm.. es handelt sich dabei um DirectDraw routinen...
wie gut die wirklich sind, weiß ich nicht, aber letzteres wäre eben wirklich peinlich...

wie performant brauchst du's denn?
wenn's jedesmal von einer user-eingabe abhängt, ist es völlig unerheblich,
ob der vorgang 5 oder 500 millisekunden braucht, weil der user bestimmt länger braucht.

wenn du das natürlich zwei dutzend mal pro sekunde ausführen willst,
ist es schon interessant, auf die performance zu schielen.

[Kukulkan]

Hallo,

wenn du das natürlich zwei dutzend mal pro sekunde ausführen willst,
ist es schon interessant, auf die performance zu schielen.

Das ist für meine Barcode-Erkennung (http://www.inspirant.de/index.php?ref=p ... eocr&lg=de). Je schneller je besser, weil das oft als Batchvorgang läuft...

Volker

[Kaeru Gaman]

hm.. dann frage ich mich allerdings, warum du es überhaupt in eine höhere bit-tiefe umwandelst...
ich würde eher die herangehensweise ändern, und mir den geringen
speicherverbrauch durch die monochromen bitmaps zunutze machen...