Re: importing functions from image package to core

[Carnë Draug]

On 16 October 2012 17:44, John W. Eaton <address@hidden> wrote:
> On 15-Oct-2012, Carnë Draug wrote:
>
> | On 15 October 2012 21:01, John W. Eaton <address@hidden> wrote:
> | > On 15-Oct-2012, Carnë Draug wrote:
> | >
> | > | Hi
> | > |
> | > | there's a bunch of simple functions on the image package that I think
> | > | could be moved to octave core (even though they used to belong to the
> | > | matlab image processing toolbox). These are the isbw, isgray, isind
> | > | and isrgb.
> | > |
> | > | The reason I propose the move is that some functions in core already
> | > | perform this checks but have their own code.
> | >
> | > Which functions do that?
> |
> | cmpermute, gray2ind, ind2rgb, rgb2hsv, rgb2ind and rgb2ntsc. Their
> | checks are not exactly the same but does this come from design or
> | because they were written by different people at different times? They
> | are usually split into separate parts so the error message says
> | exactly why it's not a RGB or indexed image instead of just saying
> | that it's not one.
> |
> | > | This functions are very
> | > | simple and would cause very little maintenance issues while reducing
> | > | repeated code.
> | > |
> | > | If no one objects, I can prepare a changeset with them.
> | > |
> | > | By the way, matlab removed this functions because of
> | > | 
> http://blogs.mathworks.com/steve/2007/03/09/what-happened-to-isgray-isind-isbw-and-isrgb/
> | > | Not sure about the best approach there.
> | >
> | > It seems like these functions are not really very useful.  So why
> | > should we have them?  I'd vote for deprecating them instead of moving
> | > them to core Octave.
> |
> | Because pretty much every function on the image packages uses them for
> | input check.
>
> Yes, but as Steve's blog post explains, the isbw, isgray, isind, and
> isrgb functions don't perform unique checks.  So maybe there are
> better ways to do this now that we have uint8 and other data types for
> images instead of just double precision values. If the functions like
> gray2ind have to do input checking on double precision values, then
> I'm not sure what is best.

This functions already perform different tests depending on the input class.

> I'd rather avoid adding obsolete functions
> that perform ambiguous checks into core Octave.

Indeed I never use this functions in my own scripts, I'm just thinking
as developer of the image package where I am constantly using them to
check the user input. I agree that they will of little use for the
typical user but for someone writing functions for the package will
save trouble. I could make them private for the image package but
though that core functions could also use them and have also been
thinking about a microscopy package (which would also use them)...

Carnë