When graphics are larger than the drawing region...

I am working with images that are, for instance, 11000 x 1100 pixels. In the program I import the image using something like

call set_rgb_colours_default@(1)
call get_dib_size@(file,hres,vres,nb_colours,ier)
call create_graphics_region@(2,hres,vres)
call use_rgb_colours@(2,1)
call select_graphics_object@(2)
ihfile = import_bmp@(file,ierr)
call dib_paint@(0l,0l,ihfile,0l,0l)
   call select_graphics_object@(1l)
   call copy_graphics_region@(1,0,0,600,600,2,0,0,hres,vres,srccopy)
   call perform_graphics_update@

and then with

    call get_rgb_value@(i,j,colour1)

I follow the border line of the object by searching black and white pixels. The problem that I have found is that, as the image is larger than the graphics region, the subroutine seemingly checks only the pixels in the 600x600 region and leaves the rest outside the analysis. I would like to know how (if it is at all possible) can I analyse the whole image in memory instead of the image in the drawing region (which will always be smaller). Thanks a lot for any help on the matter!

Agustin

Agustin,

Why can't you select the virtual graphics region 2 then enquire of the colour values in the range 0:11,000 by 0:1,100 ( Is 11,000 correct ?) by using call get_rgb_value@(i,j,colour1) .

I'm have set up virtual screens of 4,000 x 3,000 and done the same thing in the past. ( there may be a limit of around 5,000 ?? I'm not sure if this is a problem )

I've done this by setting up my own memory arrays, but there are also recent posts in Clearwin+ on 'Scaling JPEG images' where the memory is directly accessible via routines get_dib_size@, get_dib_block@ and display_dib_block@ etc.

It is a simple matter to select a sub-region of the virtual screen and copy it to the visable screen of 600x400 or 1200 x 1000 or what ever your actual screen dimension is.

John

(Excuse the terminology, as I think virtual screen is a bit old)

Dear John,

thanks for your fast reply and sorry for my delayed response. If I did not understand your post wrong, you were asking me why I called graphics_region(1l) before get pixel colour. Well, this is a mistake in the subroutine! I did not notice it until you pointed me that! I guess I did that typo during the writting of the program and never looked back! The right region is obviously 2! Now it works (well, I am crossing my fingers!) although I am still debugging the program. Oh! and yes, the image is 11000 pixels wide because it is composed by several images as it was not possible to include the whole subject in only one image without loosing resolution. Best regards,

Agustin

Agustin,

I'd be interested to hear if you were able to process images that are 11,000 pixels wide. I tried to find an earlier post which suggested that the limit was about 5,000 pixels, but could not find it. The limit may be a combination of horizontal x vertical x colour bits per pixel. If any one remembers/knows the basis for the limit let us know. If I get the time, I may try to change the size of my virtual screen to more than 4000 x 3000, to see if this limit does exist.

John

John,

Yes, the image is a bmp 11575 x 1063 but...black and white. Maybe if the image is in colour it couldn't be possible. Actually I didn't know that there was a limit, I just imported the image as it was, transformed to black and white to make easier the determination of the contour, and run the program!. I have also tried to use jpg files as they are quite smaller, but I didn't get how to manage the graphics subroutines (but I have read that importing jpg files would imply longer times of processing as they should be decompresed in some way, so bmp seems to be the route). My bmp was processed successfuly although the do loops required some time to verify the whole image, but I am not so anxious....Some people told me that Matlab works faster for image processing but price is prohibitive for me.

Best regards,

Agustin