bugGNU Octave - Bugs: bug #45447, image package: strel decomposition...

 
 

bug #45447: image package: strel decomposition does not speed things up

Submitter:  Hartmut <hardy>
Submitted:  Tue 30 Jun 2015 07:52:36 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 02 Jul 2015 10:54:52 AM UTC, comment #4: 

Done http://hg.code.sf.net/p/octave/image/rev/e977104b2492

I don't want to explain too much on the documentation what may or may not work, because this is dependent on the implementation which I may change (maybe we decide later that we should not be guessing if it's a rectangle, or maybe we manage to guess circles in the future).

So documentation should just recommend avoiding arbitrary, unless the shape really is arbitrary.

Carnë Draug <carandraug>
Group Member
Wed 01 Jul 2015 12:13:35 PM UTC, comment #3: 

Hmmm.... could we correct the misleading documentation then?

It would be helpful to see one example in the doc where strel decomposition (or using a strel objecct instead of just a matrix) does something useful at all :) If there is no such example (yet), then we should probably just delete this code example.

Hartmut <hardy>
Tue 30 Jun 2015 08:32:16 PM UTC, comment #2: 

Hmm... maybe this could be a documentation bug.

Carnë Draug <carandraug>
Group Member
Tue 30 Jun 2015 08:31:55 PM UTC, comment #1: 

The reason why you don't see a speedup is because imdilate and imerode will automatically perform SE decomposition for rectangular strels. You would see a speed up for decomposition of other shapes (but at the moment, I have only implemented decomposition of rectangular SE).

Carnë Draug <carandraug>
Group Member
Tue 30 Jun 2015 07:52:36 PM UTC, original submission:  

Here is a little script to show the behavior. It is mostly taken from the example code for "strel decomposition" that you can find in the help text of strel.m :


clear
pkg load image

im = randp (5, 2000) > 15;
n=20;
se = strel ("square", n);

% test the speed with imdilate:
t = cputime ();
imdilate (im, se);
cputime () - t

se = strel (ones (n));
t = cputime ();
imdilate (im, se);
cputime () - t

% make sure that the se can be decomposed at all:
se
seq = getsequence(se);
number_of_decomps = max(size((seq))) % returns 2*1 = YES


The help text of strel.m states that there should be a significant difference in executioin time (0.77 s versus 2.9 s is written there). But if I do this with Octave-4.0.0 and image-2.4.0. then I see hardyl any differenc in execution time (mostly around 1.13s versus 1.12s on my elderly laptop).

The last lines of the script tell me, that this se can be decomposed, getsequence returns 2 parts. But I am not sure that imdilate uses this decomposition at all.

Note: I had to use "size(se)" in the script, because "length(se)" did not work, it returned the value 1 instead of 2. Is this a bug on its own, or intenional?

Hartmut <hardy>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hardy (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-06-30 carandraug StatusNone Invalid / Not an Octave Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code