Hello,
I need to get the vertical positions of the pixels of a line (one pixel thick) drawn on an image (image object, not graphic object)
Namely:
I have an object image
Within this picture, I draw, from left to right, a line with peaks and valleys
I need to get the distances of each pixel of that line from the base of the image.
I think the method is to cover the pixels of the image and detect the color of the line, but:
I have made a script using screenmouseloc and mouseColor but it is very, very slow.
I'm studying imageData instruction but I can not fully understand how it works. Can someone help me please?
P.S. It could also draw the line in Illustrator, Photoshop etc,. and then import the image into LiveCode,
Thank you very much in advance
---
my 'slow' script:
---
on mouseUp
lock screen
--
put the left of this stack into StackIzq ; put the top of this stack into StackArr
put the top of image "papel" into arriba ; put the left of image "papel" into izquierda
put the width of image "papel" into largo ; put the height of image "papel" into alto -- 500 x 200 pixels
put empty into fld "sal23" --
repeat with a = 1 to largo -- runs length
repeat with b = 1 to alto -- runs height
put a+izquierda+StackIzq into xx
put b+arriba+StackArr into yy
set the screenmouseloc to xx,yy --
if the mousecolor = "255,34,189" then -- "255,34,189" is the color of the line
put a & tab & b & tab & the mouseColor &cr after fld Sal23
end if
if the mouse is down then exit to top -- zzzz
end repeat
end repeat
end mouseUp
Detecting the color of pixels
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Re: Detecting the color of pixels
The fastest way is presumably to get the pixels where your line intersects with the image (compute or use intersect()).
Then you can have the colour of the image pixels directly from the imagedata (the colour is byte 2-4 of each 32-bit pixel, use byteToNum to get the r,g,b colour).
Advantage:
The mouseColor is not always "correct", depends also on screen gamma and and your colour calibration.
[There are good tutorials to colours and images].
Then you can have the colour of the image pixels directly from the imagedata (the colour is byte 2-4 of each 32-bit pixel, use byteToNum to get the r,g,b colour).
Advantage:
The mouseColor is not always "correct", depends also on screen gamma and and your colour calibration.
[There are good tutorials to colours and images].
shiftLock happens
Re: Detecting the color of pixels
Hi.
Hermann has an answer. But is the relationship between the line you draw and the image pertinent? That line, maybe a freehand graphic, has its "points" property. You can scale from that list to the baseline.
In other words, where does the imageData come into play, if it is the line you draw that you are interested in?
Craig Newman
Hermann has an answer. But is the relationship between the line you draw and the image pertinent? That line, maybe a freehand graphic, has its "points" property. You can scale from that list to the baseline.
In other words, where does the imageData come into play, if it is the line you draw that you are interested in?
Craig Newman
Re: Detecting the color of pixels
Thanks to both.
The final purpose is to manually design the varying heights of successive nodes in Google Earth paths and I think Craig pointed in the right direction.
I've never worked with that kind of tools in LiveCode (frehand graphic) but I will try. I understand that the "points" property provides the coordinates (vertical, mainly) I need. Let's see if I can.
Thank you very much again
...
And -hh, you're right. Color detection (mouseColor) seems a bit confusing. Among other things, I think that detects intermediate colors at the edges of the line.
The final purpose is to manually design the varying heights of successive nodes in Google Earth paths and I think Craig pointed in the right direction.
I've never worked with that kind of tools in LiveCode (frehand graphic) but I will try. I understand that the "points" property provides the coordinates (vertical, mainly) I need. Let's see if I can.
Thank you very much again
...
And -hh, you're right. Color detection (mouseColor) seems a bit confusing. Among other things, I think that detects intermediate colors at the edges of the line.
Re: Detecting the color of pixels
I don't understand why you need the "line".
Do you intend to trace contour lines (heights) depending on colour?
Then you can evaluate the image pixel colours directly and use treshold values for that.
Do you intend to trace contour lines (heights) depending on colour?
Then you can evaluate the image pixel colours directly and use treshold values for that.
shiftLock happens
Re: Detecting the color of pixels
I think Hermann is saying that if you had, say a green jagged mountain profile in a white background, you could derive the "line" or"edge" by color juxtaposition.
But you had mentioned you were going to draw a line. So keep at it, and let us know how it all works out. There are many ways to do things, after all...
Craig
But you had mentioned you were going to draw a line. So keep at it, and let us know how it all works out. There are many ways to do things, after all...
Craig
Re: Detecting the color of pixels
Sorry for the delay. Besides the question it is hard to explain, do it in a language I did not know well, takes me a long time, but I'll try...
I want to prepare a virtual flight over a city with Google Earth.
Well, Google Earth allows me to draw a path on the ground via points (nodes, vertex): I start by marking the node 1 (by clicking on a place on the map), then I walk down a street and mark the node 2, then turn, for example, to the right and mark the node 3, then 4, 5, 6, 7 and so on ... I can make as many moves and mark as many nodes as i need, for example 150 ... but all of them just on the same plane; two-dimensional (remember Flatland?).
Then... what about heights? here comes the trouble. Google Earth only allows to assign THE SAME HEIGHT for the entire route. OK. I choose 50 meters. That's a good height for overflying a park, but when tall buildings appear I must to climb to avoid colliding with them. And some are higher than others, and I want to fly over at different heights. That's when I need the help of LiveCode.
I leave Google Earth, and open LiveCode
What I need now is something like the reverse process to create a graph, ie:
Draw a broken line from left to right. Manipulate (*) the vertical position of each of the 150 nodes (vertex) I need, and get their distances from the base.
After that, I pick up the values of these heights > I save them in a kml file > Open Google Earth > load the kml file and and apply those values. The system works perfect. Any error in the heights?... LC again and retouch graphics.
(*) The essential question: A method of designing (and subsequently obtain) the sequence of the heights of 150 nodes. Hence my first question about an alternative method:
"I need to get the vertical positions of the pixels of a line (one pixel thick) drawn on an image (image object, not graphic object)"
Thank you
I want to prepare a virtual flight over a city with Google Earth.
Well, Google Earth allows me to draw a path on the ground via points (nodes, vertex): I start by marking the node 1 (by clicking on a place on the map), then I walk down a street and mark the node 2, then turn, for example, to the right and mark the node 3, then 4, 5, 6, 7 and so on ... I can make as many moves and mark as many nodes as i need, for example 150 ... but all of them just on the same plane; two-dimensional (remember Flatland?).
Then... what about heights? here comes the trouble. Google Earth only allows to assign THE SAME HEIGHT for the entire route. OK. I choose 50 meters. That's a good height for overflying a park, but when tall buildings appear I must to climb to avoid colliding with them. And some are higher than others, and I want to fly over at different heights. That's when I need the help of LiveCode.
I leave Google Earth, and open LiveCode
What I need now is something like the reverse process to create a graph, ie:
Draw a broken line from left to right. Manipulate (*) the vertical position of each of the 150 nodes (vertex) I need, and get their distances from the base.
After that, I pick up the values of these heights > I save them in a kml file > Open Google Earth > load the kml file and and apply those values. The system works perfect. Any error in the heights?... LC again and retouch graphics.
(*) The essential question: A method of designing (and subsequently obtain) the sequence of the heights of 150 nodes. Hence my first question about an alternative method:
"I need to get the vertical positions of the pixels of a line (one pixel thick) drawn on an image (image object, not graphic object)"
Thank you
Re: Detecting the color of pixels
Hi Fermin,
one more question, to see if I understand your problem.
The basic problem is to get "heights" of nodes.
In which form do you have the nodes?
In 2D, that is (x1,y1)? And now you wish to add a third coordinate z1, called "height", that you derive from the pixel's colour of the node?
A pixel is for me a 2D-point on the screen (that could be part of an image).
(Important to clarify, because some documents (pdf/postscript) that have 'inline'-pictures, use coordinates of printer-points for the display, not screen points/pixels).
[1] Then all you need is the colour of certain pixels (x,y), x=distance to left side, y= distance to top of screen. Is that correct?
How you *get the location* of these pixels (you draw a line) then doesn't matter at this basic step.
[2] The next question is how to evaluate the colour information. You certainly have a concept for that 'distance of colours' (I would use euclidean distance in 3D).
[3] From the new height, derived in step [2] you update the third coord of you 3D-nodes.
Very interesting.
Now, what is your status? Tell us for which step you need help.
And, if you success with your project, show us a demo (or point us to that).
Hermann
p.s. For step [2] it is important to compare colours of the same "quality". Means: If you compare a screenshot to the rawData of a highRes image, then your physical screen setting has influence on the result. This may be wanted or not, but good to know.]
one more question, to see if I understand your problem.
The basic problem is to get "heights" of nodes.
In which form do you have the nodes?
In 2D, that is (x1,y1)? And now you wish to add a third coordinate z1, called "height", that you derive from the pixel's colour of the node?
A pixel is for me a 2D-point on the screen (that could be part of an image).
(Important to clarify, because some documents (pdf/postscript) that have 'inline'-pictures, use coordinates of printer-points for the display, not screen points/pixels).
[1] Then all you need is the colour of certain pixels (x,y), x=distance to left side, y= distance to top of screen. Is that correct?
How you *get the location* of these pixels (you draw a line) then doesn't matter at this basic step.
[2] The next question is how to evaluate the colour information. You certainly have a concept for that 'distance of colours' (I would use euclidean distance in 3D).
[3] From the new height, derived in step [2] you update the third coord of you 3D-nodes.
Very interesting.
Now, what is your status? Tell us for which step you need help.
And, if you success with your project, show us a demo (or point us to that).
Hermann
p.s. For step [2] it is important to compare colours of the same "quality". Means: If you compare a screenshot to the rawData of a highRes image, then your physical screen setting has influence on the result. This may be wanted or not, but good to know.]
shiftLock happens
Re: Detecting the color of pixels
I looked again at your first script and understand now what you want with the line.
This is interesting, so I wrote a proposal how to do that (tested one time only, please come back if it doesn't work). Craig could give an interpretation if it's unclear (he was my teacher too when I started).
Make a button with the following script. This makes a polygon (2 points=line) that we need in next step. The "TestLine" has linesize 3, so that you can better drag it. The middle row of pixels of it is used.
This "TestLine" will be used instead of your "line" graphic.
Now set the script of this graphic to the following.
This reports the pixelColour of the image pixels that are underneath your line.
[Edit. Sorry the first version of the function had a wrong line]
Now you can drag around the line in your picture, resize its width.
Used is always the vertical of the left edge of the line and the horizontal of the left edge and the right edge. Such, as if it were horizontal (if it's not).
On mouseUp, after the drag, you get in your field the internetdate (to see you are done, because it's fast) and
lines of the form 157,171=67,86,54
at left of "=" is the point/pixel (relative to topleft of the image)
at right of "=" is the (r,g,b)-colour of the pixel.
[Important: The colour is read from the image, what is not the same as a read from the screen, we know.]
Of course you can also make a button to read the colours without dragging the polygon-line, for example
Have fun. Hermann
This is interesting, so I wrote a proposal how to do that (tested one time only, please come back if it doesn't work). Craig could give an interpretation if it's unclear (he was my teacher too when I started).
Make a button with the following script. This makes a polygon (2 points=line) that we need in next step. The "TestLine" has linesize 3, so that you can better drag it. The middle row of pixels of it is used.
This "TestLine" will be used instead of your "line" graphic.
Code: Select all
on mouseUp
lock screen; lock messages
put the top of image "papel" into arriba
put the left of image "papel" into izquierda
if there is no grc "TestLine" then
create grc "TestLine"; set style of grc "TestLine" to "polygon"
end if
set lineSize of grc "TestLine" to 3
set foreColor of grc "TestLine" to "255,34,189"
-- vertical distance of line from image top
put arriba+100 into vv
-- horizontal distance of left end of line from image left
put izquierda+150 into hh1
-- horizontal distance of right end of line from image left
put izquierda+350 into hh2
set points of grc "TestLine" to (hh1,vv) &cr& (hh2,vv)
unlock screen; unlock messages
end mouseUp
This reports the pixelColour of the image pixels that are underneath your line.
Code: Select all
--> j0 is the row, i1 the start column, i2 the end column
function getPixels j0,i1,i2
put the imageData of img "papel" into iData
put the width of img "papel" into w
put (j0-1)*w into j2 -- base row
repeat with i = i1 to i2 -- columns
put 4*(j2 + i) into j1
put cr & (i,j0) after myList -- the pixel as 'point'
put "=" & byteToNum(byte j1-2 of iData) after myList -- red channel
put comma & byteToNum(byte j1-1 of iData) after myList -- green channel
put comma & byteToNum(byte j1 of iData) after myList -- blue channel
end repeat
return myList
end getPixels
on writePixels
lock screen; lock messages
put the top of image "papel" into arriba
put the left of image "papel" into izquierda
put the points of grc "TestLine" into p
put item 2 of line 1 of p into vv
put item 1 of line 1 of p into hh1
put item 1 of line 2 of p into hh2
put vv-arriba into v --> vertical distance to topOfImage
put hh1-izquierda into h1 --> horizontal left distance to leftOfImage
put hh2-izquierda into h2 --> horizontal right distance to leftOfImage
put the internet date & getPixels (v,h1,h2) into fld "sal23"
unlock screen; unlock messages
end writePixels
on mouseDown
grab me
end mouseDown
on mouseUp
writePixels
end mouseUpNow you can drag around the line in your picture, resize its width.
Used is always the vertical of the left edge of the line and the horizontal of the left edge and the right edge. Such, as if it were horizontal (if it's not).
On mouseUp, after the drag, you get in your field the internetdate (to see you are done, because it's fast) and
lines of the form 157,171=67,86,54
at left of "=" is the point/pixel (relative to topleft of the image)
at right of "=" is the (r,g,b)-colour of the pixel.
[Important: The colour is read from the image, what is not the same as a read from the screen, we know.]
Of course you can also make a button to read the colours without dragging the polygon-line, for example
Code: Select all
on mouseUp
send "writePixels" to grc "TestLine"
end mouseUp
shiftLock happens
Re: Detecting the color of pixels
Hi, Hermann, I just saw your reply. I will examine. It's very kind of you all that effort and attention to me.
I do not know if I can put a link on this forum. I'll try. These are some videos of the work I do with Google Earth and I want to improve with your help.
Thank you very much and see you soon
https://www.youtube.com/watch?v=iZ8ACeL ... e=youtu.be
https://www.youtube.com/watch?v=iZR8c2z ... e=youtu.be
I do not know if I can put a link on this forum. I'll try. These are some videos of the work I do with Google Earth and I want to improve with your help.
Thank you very much and see you soon
https://www.youtube.com/watch?v=iZ8ACeL ... e=youtu.be
https://www.youtube.com/watch?v=iZR8c2z ... e=youtu.be
Re: Detecting the color of pixels
Herman, you have helped me understand one thing that was very simple but I was very, very confusing: The way the graphic object is positioned on the screen. I can not explain very well but your code helped me a lot. And that, in just one part of your code. I still have it. Thank you... 