forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

New sugestion(s) for %PL - (first - an initial question)
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
Martin_K



Joined: 09 Apr 2020
Posts: 227

PostPosted: Sun Mar 28, 2021 6:19 pm    Post subject: Reply with quote

Thanks Ken!

I will do it as you suggested.

After your explaining what are the graph´s dimensions (I mixed it with window dimensions) I made some additional steps and the graph/map looks like this:



Now, the graph/map above contain all essential (from geodetical point of view) information to properly interpret the data which it contains (scale, info about horizontal and vertical coordinate system, north arrow, number of objects).
It is intuitive that the text in red in the statistic relates to the red objects in the graph (red lines), the text in blue relates to the blue objects (blue points).
Nevertheless, I will improve it as you suggested (text in black and numbers in red/blue), since sometimes too many colors can be extravagant.

Regarding the importing of JPG raster image to the graph - have a look
please to my code below:

Code:

...
iw = CREATE_GRAPHICS_REGION@( 1001, WIDTH_RASTER, HEIGHT_RASTER)
          i = IMPORT_FILE_IMAGE@( 'orthophoto_and_geo_surveying.jpg' , -10, -15 )
i = COPY_GRAPHICS_REGION@(handle_pl_OK, mleft, mtop, gw-mleft-mright, gh-mtop-mbottom,  &
                             1001,  0, 0, WIDTH_RASTER, HEIGHT_RASTER, 8913094) !! 13369376)!! 8913094)


Note that in the COPY_GRAPHICS_REGION@ I use ZERO offset, but in the
IMPORT_FILE_IMAGE@ I use the offsets -10 and -15.

Using the code above, JPG is correctly pasted between X,Y axes (no overlapping of axis and tick mark values). When I used them as ZERO
values for IMPORT_FILE_IMAGE@ and -10,-15 for COPY_GRAPHICS_REGION@, the image overlaps BOTH the axes AND
the tick mark values below axes exactly to their bottom (the same when I use ZERO values for both commands).

I am confused from it and don´t know how to interpret it (I already said earlier in one of my previous post that it seems to me that IMPORT_FILE_IMAGE@ command may interpret where to paste it also the tick mark numbers as whole graphics region and therefore it stretches the image also over them).

So, the question remains - how could be determined the right offset for
the IMPORT_FILE_IMAGE@ in advance BEFORE pasting it to the graph
(not by experimenting by trying to manually input some estimated values).

The above mentioned variants of offsets and their impact on the graph are demonstrated here:

https://www.dropbox.com/s/kptg0wxd432g4qn/offsets.pdf?dl=0
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Sun Mar 28, 2021 11:31 pm    Post subject: Reply with quote

Add the following immediately after you call to COPY_GRAPHICS_REGION@
Code:
call set_line_width@(2)
call draw_rectangle@(mleft, mtop, gw-mright, gh-mbottom, rgb@(255,0,0))
call set_line_width@(1)

If this rectangle aligns with the %pl frame, then you eliminate the destination graphics region as the source of the problem. However I think you may well find that the lower right hand corner is offset by 10 pixels to the right and 15 down.
Back to top
View user's profile Send private message Visit poster's website
Martin_K



Joined: 09 Apr 2020
Posts: 227

PostPosted: Mon Mar 29, 2021 6:34 pm    Post subject: Reply with quote

Here is how the graph looksafter implementing your test code with rectangle:



It seems to me that my assumption was correct and it was that the destination graphics
region (its dimensions) also includes the number below tick marks (its bottom or base of the numbers) - not only axes as such
as can be seen in the picture above.
Probably this is also the reason why JPG raster image is stretched in such way that it also overlaps axes and the numbers below tick marks and ends
exactly at the base of the numbers.

So, the question is how to automatically compute these values to eliminate it.

Important note:
I moved the following code from a call-back, which loads in the JPG raster image to the beginning of my plot function which uses %PL:

Code:

CALL GET_DIB_SIZE@( 'orthophoto_and_geo_surveying.jpg', WIDTH_RASTER, HEIGHT_RASTER, NBBP,ERCODE )
iw = CREATE_GRAPHICS_REGION@( 1001, WIDTH_RASTER, HEIGHT_RASTER)
i = IMPORT_FILE_IMAGE@( 'orthophoto_and_geo_surveying.jpg' , 0, 0 )
iw = CREATE_GRAPHICS_REGION@(handle_internal_gr,gw,gh)



Earlier, the code above was part of the call-back assigned to the button
for loading in JPG ratsre image:

Code:

INTEGER FUNCTION pridaj_raster ()
IMPLICIT NONE

   
 !!  CALL GET_DIB_SIZE@( 'orthophoto_and_geo_surveying.jpg', WIDTH_RASTER, HEIGHT_RASTER, NBBP,ERCODE ) 
 !!  i = NEW_GRAPHICS_REGION@( 1001, WIDTH_RASTER, HEIGHT_RASTER, rgb@(0,0,0))
 !!  i = IMPORT_FILE_IMAGE@( 'orthophoto_and_geo_surveying.jpg' , -10, -15 )
 i = COPY_GRAPHICS_REGION@(handle_pl_OK, mleft, mtop, gw-mleft-mright, gh-mtop-mbottom,  &
                             1001, 0, 0, WIDTH_RASTER, HEIGHT_RASTER, 8913094) !! 13369376)!! 8913094)
   pridaj_raster = 2
END FUNCTION pridaj_raster


Now, even when I use the offset values -10,-15 in the IMPORT_FILE_IMAGE@, although it does align with axes, but a vertical and horizontal black strip remains in the graph exactly in the space which
overlaps the axes and tick mark numbers. So, I use 0,0 values.


Last edited by Martin_K on Mon Mar 29, 2021 8:30 pm; edited 1 time in total
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Mar 29, 2021 8:28 pm    Post subject: Reply with quote

Martin,
I didn't quite understand what you mean, can you post an image of your result please. Ta.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
Martin_K



Joined: 09 Apr 2020
Posts: 227

PostPosted: Mon Mar 29, 2021 8:39 pm    Post subject: Reply with quote

John,

After moving the code as described above and using offsets -10, -15 the result is:



I meant the black strip in vertical and horizontal direction as can be seen in the picture above. So, I have to use 0,0 offset (then no black strip appears,
but overlapping remains with raster image exactly in the area, where black strips are.

The reason for black strip is clear - COPY_MODE 8913094 since it copies as follows:
The colors of the source and destination areas are combined using the Boolean AND operator.
And when they NOT EXACTLY FIT (are NOT exactly aligned) then the result is as in my picture.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Mar 29, 2021 8:45 pm    Post subject: Reply with quote

Martin wrote:
Quote:
So, the question is how to automatically compute these values to eliminate it.


I seem to remember(from memory) that it isn't (at the moment) possible to acurately output the dimensions of the zones containing the axes, tick marks and numberings, although it would be very useful.
I seem to remember I made a post asking a similar question relating to the top left corner of the graph and needing to know exactly where the LH side of the axes numbering was so as to be able to accurately place the LH axes title, but never got a satisfactory answer.

I can probably dig that post out if needed. Let me know.

It should be possible to modify the program to output ALL dimensions within a graphics region otherwise one is always 'guessing'.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Mon Mar 29, 2021 8:51 pm    Post subject: Reply with quote

Code:
WINAPP
module pl_pv_test
USE clrwin
INTEGER, parameter :: N=11
integer i
integer gw,gh
integer, parameter :: mtop = 10, mbottom=20, mleft=100, mright=30
REAL*8 x1(N),y1(N)     
contains
     
integer function gen_data()
  DO i=1,N
   x1(i)=0.025d0*(i-1) ; y1(i)=1.d0-x1(i)*x1(i)
  ENDDO
  gen_data = 1
end function gen_data

integer function draw_pl()
character(len=126) pl_str
  gw=600
  gh=300
  i=winio@('%`bg[white]%tc[black]&')
  CALL winop@("%pl[x_array,link=curves,symbol=9,colour=blue,frame,y_axis=@,x_axis=@,gridlines,width=2]")
  write(pl_str,'("%pl[margin=(",I3,",",I3,",",I3,",",I3,")]")') mleft, mtop, mright, mbottom
  print*, 'Values used to set up %pl'
  print*, mleft, mtop, mright, mbottom
  call winop@(pl_str)
  i=winio@('%^pl&',gw,gh,N,x1,y1,pl_cb)
  print*, gw, gh
  i=winio@('%sf%ff%nl%cn%tt[OK]')
  draw_pl = 1
end function draw_pl

integer function pl_cb()
  if (clearwin_string@('CALLBACK_REASON') .eq. 'PLOT_ADJUST') then
    call draw_frame(rgb@(255,0,0),3)
    print*
    print*, 'Values used in call back'
    print*, mleft, mtop, mright, mbottom
    print*, gw, gh
  end if
  pl_cb = 2
end function pl_cb


subroutine draw_frame(colour,width)
integer, intent(in):: colour, width
call set_line_width@(width)
call draw_rectangle@(mleft, mtop, gw-mright, gh-mbottom, colour)
call set_line_width@(width)
end subroutine draw_frame
     
end module pl_pv_test

program main
use pl_pv_test
i = gen_data()
i = draw_pl()
end program main
Back to top
View user's profile Send private message Visit poster's website
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Mar 29, 2021 9:01 pm    Post subject: Reply with quote

It shouldn't be a question of anything within the axes (the black ) area should it since only the part of the image which lies within the hatched graphic area should be copied, not the entire image.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Mar 29, 2021 9:21 pm    Post subject: Reply with quote

Martin,
in an earlier post you wrote some code:
Quote:
i = COPY_GRAPHICS_REGION@(handle_pl_OK, mleft, mtop, gw-mleft-mright, gh-mtop-mbottom, &
1001, 0, 0, WIDTH_RASTER, HEIGHT_RASTER, 8913094) !! 13369376)!! 8913094)

but the gw-mleft-mright, gh-mtop-mbottom part ofthe codeonly removes the margins, not the axes and numbers.

In the code in the link to which you postd a link, the one that workd (out of the x4 tries) what code did you use to get the image to be exactly the size of the interoior of the graphics area, - because that's what you want as it doesn't overlap the axes at all.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
Martin_K



Joined: 09 Apr 2020
Posts: 227

PostPosted: Mon Mar 29, 2021 10:14 pm    Post subject: Reply with quote

John,

the exact pasting between X,Y axes (with no overlapping) was achieved when:

1. The callback assigned to the button which loads in the JPG onto the graph contained the following code:

Code:

INTEGER FUNCTION pridaj_raster ()
IMPLICIT NONE

 CALL GET_DIB_SIZE@( 'orthophoto_and_geo_surveying.jpg', WIDTH_RASTER, HEIGHT_RASTER, NBBP,ERCODE ) 
  i = NEW_GRAPHICS_REGION@( 1001, WIDTH_RASTER, HEIGHT_RASTER, rgb@(0,0,0))
  i = IMPORT_FILE_IMAGE@( 'orthophoto_and_geo_surveying.jpg' , -10, -15 )             
  i = COPY_GRAPHICS_REGION@(handle_pl_OK, mleft, mtop, gw-mleft-mright, gh-mtop-mbottom,  &
1001, 0, 0, WIDTH_RASTER, HEIGHT_RASTER, 8913094) !! 13369376)!! 8913094)

       i = DELETE_GRAPHICS_REGION@(1001)

   pridaj_raster = 2
END FUNCTION pridaj_raster


I found out the offset values (-10,-15 for IMPORT_FILE_IMAGE@) by experimenting (by estimating/guessing).

2. However, since the IMPORT_FILE_IMAGE@ was repeatedly loaded in and also due to other minor problems with graph (when JPG image was on the graph and I zoomed it in/out/to extents), based on Ken´s advise I moved
the code:

Code:

CALL GET_DIB_SIZE@( 'orthophoto_and_geo_surveying.jpg', WIDTH_RASTER, HEIGHT_RASTER, NBBP,ERCODE ) 
  i = NEW_GRAPHICS_REGION@( 1001, WIDTH_RASTER, HEIGHT_RASTER, rgb@(0,0,0))
  i = IMPORT_FILE_IMAGE@( 'orthophoto_and_geo_surveying.jpg' , -10, -15 )             


from this callback above to the very beginning of the plot function, where %PL is used as follows:

Code:

INTEGER FUNCTION plot_OK_MM ()
IMPLICIT NONE
CALL GET_DIB_SIZE@( 'logo_sever_SK_male.jpg', WIDTH_LOGO, HEIGHT_LOGO, NBBP1, ERCODE1 )
CALL GET_DIB_SIZE@( 'orthophoto_and_geo_surveying.jpg', WIDTH_RASTER, HEIGHT_RASTER, NBBP,ERCODE )
iw = CREATE_GRAPHICS_REGION@( 1001, WIDTH_RASTER, HEIGHT_RASTER)
      i = IMPORT_FILE_IMAGE@( 'orthophoto_and_geo_surveying.jpg' , -10, -15
iw = CREATE_GRAPHICS_REGION@(handle_internal_gr,gw,gh)
....
.... ! now follows quite long code
....

 iw=DELETE_GRAPHICS_REGION@(handle_internal_gr)
 iw=DELETE_GRAPHICS_REGION@(1001)
 plot_OK_MM = 1

END FUNCTION plot_OK_MM


The callback function responsible for loading in the JPG image now looks like follows:


Code:

INTEGER FUNCTION pridaj_raster ()
IMPLICIT NONE

 IF (L_TEST) THEN

         i = COPY_GRAPHICS_REGION@(handle_pl_OK, mleft, mtop, gw-mleft-mright, gh-mtop-mbottom,  &
                             1001, 0, 0, WIDTH_RASTER, HEIGHT_RASTER, 8913094) !! 13369376)!! 8913094)

          L_TEST=.FALSE.

       ELSE

          L_TEST = .TRUE.
         
       END IF

   pridaj_raster = 2
END FUNCTION pridaj_raster



So, I added some new logic to the callback and now (thanks Ken´s advise) the loading of the JPG image is no more repeatedly called (the image is loaded just once during lifetime of plot function) everything works VERY WELL (except black strips, but I will review latest
Ken´s post/code and will try to implement the logic to remove unwanted black strips.

However, what is the most interesting is the fact that now, when I use
the offsets -10, -15 for the IMPORT_FILE_IMAGE@ moved to the beginning of plot function from the callback - the offsets do NOT work!
The common transposition caused the effect. To be honest - I do not know to explain it
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Mon Mar 29, 2021 11:36 pm    Post subject: Reply with quote

Print out the values of:
gw, gh, mleft, mtop, mright, mbottom
a) in the part of the program where the %pl is created, and
b) in the part of the program where you paste the image.

Everything you are saying points to these values being different at different parts of the code - especially since you now say offsets don't "work" (questionable anyway) when you moved import_image_file@

Offsets with import_image_file@ should not be necessary. You are introducing an apparently good but erroneous "fix" for another problem. Both of which will undoubtable cause more problems at a later date.
Back to top
View user's profile Send private message Visit poster's website
Martin_K



Joined: 09 Apr 2020
Posts: 227

PostPosted: Tue Mar 30, 2021 8:08 pm    Post subject: Reply with quote

Here are the printed dimensions (all within plot function):

First raw - immediately after loading the JPG image.
Code:

 CALL GET_DIB_SIZE@( 'orthophoto_and_geo_surveying.jpg', WIDTH_RASTER, HEIGHT_RASTER, NBBP,ERCODE )
      iw = CREATE_GRAPHICS_REGION@( 1001, WIDTH_RASTER, HEIGHT_RASTER)
      i = IMPORT_FILE_IMAGE@( 'orthophoto_and_geo_surveying.jpg' , 0, 0 )                                ! naimportovanie JPG rastra

      print*,'Pasting JPG image:',' gw= ',gw,' gh= ',gh, ' mleft´= ', mleft,' mtop= ',mtop,' mright=',mright,' mbottom= ',mbottom


Second raw - immediately after creating graph with %PL:
Code:

 iw=winio@('%`^pl[vscroll,hscroll,full_mouse_input]&',gw,gh,n_pl,Y_OK_U,X_OK_U,handle_pl_ok,pl_cb)

print*,'Created by %PL: ',' gw= ',gw,' gh= ',gh, ' mleft´= ', mleft,' mtop= ',mtop,' mright=',mright,' mbottom= ',mbottom



All dimensions are the same ...



[/code]
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Tue Mar 30, 2021 8:25 pm    Post subject: Reply with quote

Ok. Can we see the code where you use the margin data in the winop call before the main call to %pl. Need to check that the margins are being correctly specified there.
Back to top
View user's profile Send private message Visit poster's website
Martin_K



Joined: 09 Apr 2020
Posts: 227

PostPosted: Tue Mar 30, 2021 9:06 pm    Post subject: Reply with quote

The full (and fully functional) code for the plot function called plot_OK_MM
and its callback called PL_CB.

Both contain extensive commenting (to have it clear what I did when I return back to the code after some time - ignore it).

https://www.dropbox.com/s/is3rmhik5ee321j/PL_function%2Bits_call-back.f95?dl=0

P.S. If necessary, I can publish everything
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Tue Mar 30, 2021 10:48 pm    Post subject: Reply with quote

Thanks Martin,

I looked through your code, and checked the areas where I thought there might be a problem to find nothing I am afraid.

Looking back at the images you have posted showing the unwanted "overlapping" of 10 and 15 pixels, have you noticed that these widths appear to be the same as the width of the scroll bars? I wonder if this has something to do with your issue? You might want to try removing these, as they are the only major difference between your code and the simple examples I have posted. I am clutching at straws now!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 5 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group