[DelphiI7 / Win32] -Soms- witte bitmaps na copyrect.

[RobLemmens]

Vanuit een grote collectie tiffs doe ik allerlij blokken pixels kopieren naar een strip tbv uitlijning voordat ik er ocr op los laat. Dit werkt op zich perfect alleen soms krijg ik voor een blok enkel een witte bitmap terug.. Als ik dezelfde data nogmaals der doorheen haal gaat het wel goed. Er is ook totaal geen regelmaat in. Dan gaat het 10 runs goed, dan is er elke run wel een keer dat er een of meerdere witte blokken tussen zitten.

Ik gebruik de standaard TBitmap component van delphi maar ook als ik de windows api functies (BitBlt of StretchDIBits) gebruik dan gaat het soms fout en krijg ik een witte bitmap als resultaat.

De rectangles zijn alle correct en vallen binnen de source bitmaps.

Alle bitmaps zijn 1 bit diep, ongeveer 5000x5000 pixels en de blokken liggen zo rond de 50-100.

Iemand die een idee heeft van wat hier fout gaat?

Op internet kan ik wel wat vinden over TBitmap bugs in delphi maar deze stammen uit 97 en zouden opgelost moeten zijn vanaf Delphi4. Verder is er nog iets te vinden over allocatie bugs van 1 bit bitmaps maar hier houd ik al rekening mee.

[farlane]

Kan het zij dat je een timing probleem hebt, bv doordat je de bitmaps laadt van schijf en gaat blitten voordat de bitmap geladen is?

[LordLarry]

Ik zou gewoon eens ouderwets gaan debuggen. Dat lijkt me beter werken dan dat wij nu de oorzaak probleem moeten gokken.

[ Voor 46% gewijzigd door LordLarry op 06-03-2008 18:44 ]

[Vincenz0]

heb je al gedacht aan eerst de bitmap in een memory stream te gooien?:

Delphi: bitmap.pas

function TForm1.GetBitmap(Plaatje: TBitmap);
var
  lvMem : TMemoryStream
begin
  try
    lvMem := TMemoryStream.Create;
    lvMem.LoadFromStream(Plaatje);
    // Je kunt beter meteen lvMem.LoadFromFile(); doen!
    lvMem.Position := 0;
    // Doe iets met de stream via je huidige code met eventueel aanpassingen.
  finally
    lvMem.Free;
  end;
end;

Op deze manier word het bitmapje eerst in het geheugen geplaatst, dat zou timing problemen zeker moeten oplossen. probeer eens zou ik zeggen.

[ Voor 9% gewijzigd door Vincenz0 op 07-03-2008 09:36 ]

[RobLemmens]

Het inladen doe ik met libtiff, deze data stream ik naar de bitmap scanlines maar dit gaat allemaal gewoon perfect. Timing lijkt me het probleem niet, het inladen is allemaal mooi gesynchroniseerd.
Met de debugger zie ik niets fout gaan tot na de blit, het resultaat is wit, alle scanlines/pixels zijn leeg (dus niet enkel een probleem met tonen).
Ik doe nu maar gewoon effe de scanlines kopieeren maar ik vraag me af waarom dit soms gebeurd.

[jvdmeer]

Ik heb dat ook af-en-toe gehad, en dat kwam bij mij door incompatible pixelformats. Door deze alvorens eerst goed te zetten heb ik het opgelost.

Maar ik weet niet in hoeverre jij hier last van hebt. Al jouw bronbestanden zijn hetzelfde formaat. Ik had vele verschillende bronformaten.

[MicroWhale]

tip: kijk eens op wat borland fora. Dit is een bekend probleem. Het zit hem in de BitBlt. Deze laat soms (om onbekende redenen) een steekje vallen. Hiervoor zijn workarounds te vinden die hier geen gebruik van maken.

[RobLemmens]

1 van de redenen lijkt te zijn dat de bitmaps groter zijn dan de schermresolutie. In een test progsel kreeg ik af en toe witte bitmaps na een copy uit iets dat groter dan men resolutie is, eens in de 1000 keer of zo, totaal random. Als ik de source kleiner maakte dan ging het zonder fouten.

Wat ik vooral vaag vind is dat dat nu blijkbaar nog steeds zo is, zelfs onder vista, je zou toch verwachten dat dit ontertussen opgelost zou zijn door Microsoft.

[pedorus]

Maak je gebruik van meerdere threads?