octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: importing functions from image package to core


From: John W. Eaton
Subject: Re: importing functions from image package to core
Date: Tue, 16 Oct 2012 11:44:25 -0400

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.  I'd rather avoid adding obsolete functions
that perform ambiguous checks into core Octave.
jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]