Do the =, < and > replacement keys work in imedit?
Jason Quinn wrote on Jan 14, 2009
Unless I'm completely using them wrong or interpreting their function incorrectly, it seems like the replacement keys (=, <, >) of imedit do nothing. By the documentation, it seems like pressing "<" over a pixel should replace all the pixels in the image less than the pixel's value with the constant value in the task's parameter "value". Am I missing something? Similarly for ">". For "=", it should substitute all pixels with exactly the same value, which is frequently just the current pixel unless working with a mask.
If I use the logfile, I don't see any record of these keys haven been used after an editing session.
Jason
EDIT: I normally remove "fill=yes" from the display command that is used by imedit every time I unlearn it. My experience is that this option dramatically slows down an already slow command and nearly always causes the picture to display at a scale you didn't want. These two issues make imedit almost unbearable to use. There's several variables at work here: the user's imt-size, each image size, the stretched size of the image server, etc. I am trying to think of cases where you would want it to use image fill=yes and failing. It seems to me that it's better just to let the user use the magnification buttons of an image server to choose their own viewport and zoom. Maybe having fill=no by default is better than having it turned on?
EDIT: Also while it's up... ximtool 2.0beta (my dec 10 copy) acts quirky occasionally when fill was yes. It was displaying pixels at bizzare magnifications or chopped pixels around the edge of the image, etc. If memory serves, ximtool has always gotten a little confused when using imedit with fill+... so this might not be just 2.0 stuff.
If I use the logfile, I don't see any record of these keys haven been used after an editing session.
Jason
EDIT: I normally remove "fill=yes" from the display command that is used by imedit every time I unlearn it. My experience is that this option dramatically slows down an already slow command and nearly always causes the picture to display at a scale you didn't want. These two issues make imedit almost unbearable to use. There's several variables at work here: the user's imt-size, each image size, the stretched size of the image server, etc. I am trying to think of cases where you would want it to use image fill=yes and failing. It seems to me that it's better just to let the user use the magnification buttons of an image server to choose their own viewport and zoom. Maybe having fill=no by default is better than having it turned on?
EDIT: Also while it's up... ximtool 2.0beta (my dec 10 copy) acts quirky occasionally when fill was yes. It was displaying pixels at bizzare magnifications or chopped pixels around the edge of the image, etc. If memory serves, ximtool has always gotten a little confused when using imedit with fill+... so this might not be just 2.0 stuff.
Jason Quinn wrote on Jan 14, 2009
Bump.
Definitely something broken with these commands (=, <, >) in imedit but probably easy to fix. According to the revision history, this functionality was only added in v2.13. The help description beginning with "The all pixels with" should also mention the > and < commands.
Jason
Definitely something broken with these commands (=, <, >) in imedit but probably easy to fix. According to the revision history, this functionality was only added in v2.13. The help description beginning with "The all pixels with" should also mention the > and < commands.
Jason
Jason Quinn wrote on Jan 14, 2009
Thread bump.
Could somebody try the replacement keys in imedit to see if you can duplicate this error? If this is a bug, it would probably be very quink-n-easy to fix and the functionality is very useful for making bad pixel masks.
Jason
Could somebody try the replacement keys in imedit to see if you can duplicate this error? If this is a bug, it would probably be very quink-n-easy to fix and the functionality is very useful for making bad pixel masks.
Jason
Mike Fitzpatrick wrote on Jan 14, 2009
Hi Jason,
Frank is on vacation this week, but I agree these commands either don't work or aren't intuitive. They were originally implemented for use on image masks so there may be some trick to using them, I'll poke Frank to reply when he returns.
-Mike
Frank is on vacation this week, but I agree these commands either don't work or aren't intuitive. They were originally implemented for use on image masks so there may be some trick to using them, I'll poke Frank to reply when he returns.
-Mike
Last post on Jan 14, 2009