Prev: Renderer: Painters. export_fig
Next: how to solve *out of memory* error
From: Rohit Bhat on 24 May 2010 16:16
Hi all,

I was trying to grab blocks of data from a large image. I am grabbing blocks of 510 x 1000 and trying to extract information from each block. The block is grabbed by taking a snapshot using an .OCX functionality. ( this is for a specific project, so I cannot provide the vendor names and stuff ).

In the automatic mode,
When I try to save each block image as a .jpg/ .tif file, I succeed in doing so but in each run, the image saved ends up as the image from the previous block.
Eg : If I run block 2, the data should be collected ( like some image processing ), and the image of block 2 saved. But, it sometimes saves the image of block 1. This happens for numerous blocks. It might so happen that all the images for different blocks from 1 to 100 might be same, then a few others where block "x" corresponds to image "x" , then again image "x1, x2,..." corresponds to block "x1".

Also, because of this, the data collected gets wrong (like the same data collected for many blocks, data of block 1 is saved as data for the next couple of blocks, like that )

In the debug mode, when I run it, the image saved for the blocks has the same problem, but the data collected for each block is different (i.e. each block has its own data saved, which is correct)

Why does this happen? I mean, why does it run properly in the debug mode, and not properly in the automatic mode? Is this some time/memory allocation problem while executing functions?

Please do let me know a solution. I sincerely appreciate any help in this regard.
From: Walter Roberson on 24 May 2010 18:17
Rohit Bhat wrote:

> In the automatic mode,
> When I try to save each block image as a .jpg/ .tif file, I succeed in
> doing so but in each run, the image saved ends up as the image from the
> previous block. Eg : If I run block 2, the data should be collected (
> like some image processing ), and the image of block 2 saved. But, it
> sometimes saves the image of block 1.

What that sounds like to me is that you do not have a drawnow() or
pause() statement to give the image time to render.

> Why does this happen? I mean, why does it run properly in the debug
> mode, and not properly in the automatic mode? Is this some time/memory
> allocation problem while executing functions?

Matlab flushes the graphics queue every time it reaches the command
line, including when it reaches it in debug mode.
From: Rohit Bhat on 26 May 2010 11:27
Thanks Walter.
I tried including the pause function at different stages of the program, but still the same error. Again, when I debug and run the code manually for all blocks, I get perfect results, but in the automatic mode, it fails everytime.
Some runs it captures a few blocks, some other runs it skips the ones it captured previously and so on.
This is an error with the processing time, right? Will a faster computer help? Is it related to any stack, heap issue?

Walter Roberson <roberson(a)hushmail.com> wrote in message <VVCKn.30579$wV2.13465(a)newsfe23.iad>...
> Rohit Bhat wrote:
>
> > In the automatic mode,
> > When I try to save each block image as a .jpg/ .tif file, I succeed in
> > doing so but in each run, the image saved ends up as the image from the
> > previous block. Eg : If I run block 2, the data should be collected (
> > like some image processing ), and the image of block 2 saved. But, it
> > sometimes saves the image of block 1.
>
> What that sounds like to me is that you do not have a drawnow() or
> pause() statement to give the image time to render.
>
> > Why does this happen? I mean, why does it run properly in the debug
> > mode, and not properly in the automatic mode? Is this some time/memory
> > allocation problem while executing functions?
>
> Matlab flushes the graphics queue every time it reaches the command
> line, including when it reaches it in debug mode.
 | 
Pages: 1
Prev: Renderer: Painters. export_fig
Next: how to solve *out of memory* error