forums.silverfrost.com

[PaulLaidler]

Norm.Campbell

I need to take another look at this. I am now able to reproduce the failure.

The failure does not appear to be in RGB@ nor DRAW_LINE@. Maybe it is in one of the "DIB block" routines when used in a 64 bit application.

I had assumed that you were reporting a regression but this does not now appear to be the case.

In the meantime there is nothing lost by only using the 32 bit version.

[Norm.Campbell]

Hi Paul

I was about to send you a response, noting that I'd done some more checking, and found that my computer was reporting a memory error when it rebooted, and that perhaps the difference in memory accessed between the 32-bit and 64-bit versions was the problem. Then I noticed that the posts had gone over to a second page, and saw your latest comments.

It's good to know that the problem is real. As you note, I can work around it using the 32 bit version, and I've got to quite like the yellow background for some of my plots.

Merry Christmas

Norm

[PaulLaidler]

The fault is in the 64 bit version of RECOVER_DIB_BLOCK@. This has now been fixed for the next release of clearwin64.dll.

[Norm.Campbell]

Hi Paul

Just to let others (and you) know that replacing

PUT_DIB_BLOCK@ ( flno, ... )

with

nFUNC = Export_Image@ ( flno )

fixes the problem.

I also replaced DRAW_LINE@ with DRAW_LINE_BETWEEN@, and removed

INCLUDE < DBOS.IN >.

Thank you for fixing this for me.

Happy New Year

Norm

[Norm.Campbell]

To take your comment seriously, I quite like the 64-bit version.

I spend a fair bit of time writing code to process remotely sensed images. I can usually just fit my images in in 32-bit mode, but when there is a bug in my code (and that still seems to happen all too frequently) then it is a pain having to cut down my array sizes so that I can find the bug.

So far, the 64-bit version has alleviated that problem.