comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Ongoing Object Graphics Quest
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Ongoing Object Graphics Quest [message #28117 is a reply to message #28026] Mon, 19 November 2001 06:48 Go to previous messageGo to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Martin Downing (martin.downing@ntlworld.com) writes:

> Oh I see - its actually the other way round. The drawn rubber band, defined
> as "theBox", does not draw round the top-right corner of the top right
> pixel.
> You could round this up like for instance:
>
> box_x0 = min([info.xs, info.xd])
> box_x1 = max([info.xs, info.xd])+1
> box_y0 = min([info.ys, info.yd])
> box_y1 = max([info.ys, info.yd])+1
>
> box[0,*] = [box_x0,box_x1,box_x1,box_x0,box_x0]
> box[1,*] = [box_y0,box_y0,box_y1,box_y1,box_y0]
>
> info.theBox->SetProperty, Data=box

Actually, I think it is a little more pernicious
than this. :-)

The problem is that I get a location in the window,
but what I want is an image subscript. If I have two
locations in the window (e.g. a line), those endpoints
are one pixel longer than the subscripts that I need.

But here is the dilemma: which end of the line should
I subtract one from (or add one to)? It depends on
how you have drawn the line (e.g. right to left, or
left to right) and whether one end of the line is
on the image boundary. I think there must be at
least eight possibilities you have to check to be
able to get your box boundaries correct.

Rather than doing this, I elected to take the FLOOR
of all points, since this always keeps me inside the
image. The downside is that I often get one more
row and one more column of the image in the zoom
than I really wanted. For the images I work with,
this is really not a concern, since one extra row
or column in a 512x512 image is almost invisible.

But when you work with images with really big pixels
(e.g., image = Findgen(5, 6)), then the problem
becomes obvious. I'll probably have to fix it, but
it may have to wait a couple of days. I really have
to get some real work done today.

> 2) The extent of contrast and brightness stretching
> appears to be restricted when the left image has been zoomed

I don't think so, since there is no connection at all
between what is happening in the zoom window and the
contrast/brightness algorithm.

I appreciate the help.

Best Regards,

David

--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: 24-bit color contour
Next Topic: old problem--the limitation on largest array in IDL, new

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 15:27:56 PDT 2025

Total time taken to generate the page: 0.00477 seconds