Thread: [OctDev] image 2.0.0 released

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi everyone

a new release of the image package is out, version 2.0.0, by Carnë Draug.
Enjoy Octave responsibly.

Carnë

Hi,

I just installed octave-devel (Octave 3.6.3) from MacPorts on Mac OS X
10.6.8
If I want to use the new image package what do I need to do? Can I unload
the old one and load in the new one somehow?
Also, is there documentation of the new features etc?

Edmund

On Thu, Nov 8, 2012 at 8:38 PM, Carnë Draug <car...@gm...>wrote:

> Hi everyone
>
> a new release of the image package is out, version 2.0.0, by Carnë Draug.
> Enjoy Octave responsibly.
>
> Carnë
> _______________________________________________
> Help-octave mailing list
> Hel...@oc...
> https://mailman.cae.wisc.edu/listinfo/help-octave
>

On 11/8/12 1:51 PM, edmund ronald wrote:
> Hi,
> 
> I just installed octave-devel (Octave 3.6.3) from MacPorts on Mac OS X
> 10.6.8
> If I want to use the new image package what do I need to do? Can I
> unload the old one and load in the new one somehow? 

You can try uninstalling Macports' image package and using "pkg install
-forge image" from Octave to install the new version; that works in _my_
packaging of Octave, at least.  It's probably safest to do that as a
user rather than doing a global install.

> Also, is there documentation of the new features etc? 
> 
> Edmund
> 

Yes.  At your Octave prompt run:

news ("image")

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/

On 8 November 2012 15:51, edmund ronald <edm...@gm...> wrote:

> On Thu, Nov 8, 2012 at 8:38 PM, Carnë Draug <car...@gm...>
> wrote:
>>
>> Hi everyone
>>
>> a new release of the image package is out, version 2.0.0, by Carnë Draug.

> Also, is there documentation of the new features etc?

I would like to advertise partial support of N-dimensional binary
images (the bw* family of functions). I worked on bwlabeln and
modified a few functions where it was easy to do so to make them work
N-dimensionally. The biggest missing one here that I am planning to
work on next is bwdist and perhaps bwconncomp.

Consider this an invitation to help with that development effort too. :-)

- Jordi G. H.

A question: is there an implementation or a plan to implement bindings for
ICC color profiles in the Image library? This would be very useful
1. to work with the data in existing images whose values reference a color
space
2. to allow development of calibration/profiling algorithms

There is some reference in the link below to the well-regarded lcms
library, but as a beginner I wouldn't know how to bind this to Octave.
However, if someone here is interested in making this part of the Image
package I would be prepared to help with domain-specific knowledge.

http://mirror.fcaglp.unlp.edu.ar/pub/octave/MAILING-LISTS/octave-sources/2001/1

On Thu, Nov 8, 2012 at 11:47 PM, Jordi Gutiérrez Hermoso <jo...@oc...
> wrote:

> On 8 November 2012 15:51, edmund ronald <edm...@gm...> wrote:
>
> > On Thu, Nov 8, 2012 at 8:38 PM, Carnë Draug <car...@gm...>
> > wrote:
> >>
> >> Hi everyone
> >>
> >> a new release of the image package is out, version 2.0.0, by Carnë
> Draug.
>
> > Also, is there documentation of the new features etc?
>
> I would like to advertise partial support of N-dimensional binary
> images (the bw* family of functions). I worked on bwlabeln and
> modified a few functions where it was easy to do so to make them work
> N-dimensionally. The biggest missing one here that I am planning to
> work on next is bwdist and perhaps bwconncomp.
>
> Consider this an invitation to help with that development effort too. :-)
>
> - Jordi G. H.
>

* Carnë Draug <car...@gm...> [2012-11-08 19:38]:

> a new release of the image package is out, version 2.0.0, by Carnë 
> Draug.

Thanks for this new release, Carnë.  I am in the process of preparing 
the Debian package for it.

I noticed three issues in this tarball:

1) Although the large majority of the files are correctly encoded in 
UTF-8, there are still some of them in Latin1:

        $ file inst/* | grep ISO
        inst/bwarea.m:            ISO-8859 text
        inst/bwperim.m:           ISO-8859 text
        inst/edge.m:              ISO-8859 text
        inst/fspecial.m:          ISO-8859 text
        inst/im2double.m:         ISO-8859 text
        inst/im2int16.m:          ISO-8859 text
        inst/im2single.m:         ISO-8859 text
        inst/im2uint16.m:         ISO-8859 text
        inst/im2uint8.m:          ISO-8859 text
        inst/imperspectivewarp.m: ISO-8859 text
        inst/imremap.m:           ISO-8859 text
        inst/imresize.m:          ISO-8859 text
        inst/label2rgb.m:         ISO-8859 text

This only affects the names of authors in the copyright notices, but is a 
nuisance for generating the debian/copyright file for the Debian package.

2) The function 'bwmorph' calls 'erode' and 'dilate', which are 
deprecated by the package itself.  It would be good to change the code 
to use imerode and imdilate.

3) The function fftconv2 gives a wrong result when called like this: 
"fftconv2 (vector1, vector2, matrix)", although this usage is advertised 
in the help string.  For the Debian package, I am planning to apply the 
patch attached below, which (i) removes the advertisement from the help 
string, (ii) gives an error message when the function is called with the 
said usage and (iii) drop the tests with the said usage.

If you could address the issues below in the next release, it would be 
great.

Best,

Rafael

On 11 November 2012 09:54, Rafael Laboissiere <ra...@la...> wrote:
> * Carnë Draug <car...@gm...> [2012-11-08 19:38]:
>
>> a new release of the image package is out, version 2.0.0, by Carnë
>> Draug.
>
> Thanks for this new release, Carnë.  I am in the process of preparing
> the Debian package for it.
>
> I noticed three issues in this tarball:
>
> 1) Although the large majority of the files are correctly encoded in
> UTF-8, there are still some of them in Latin1:
>
>         $ file inst/* | grep ISO
>         inst/bwarea.m:            ISO-8859 text
>         inst/bwperim.m:           ISO-8859 text
>         inst/edge.m:              ISO-8859 text
>         inst/fspecial.m:          ISO-8859 text
>         inst/im2double.m:         ISO-8859 text
>         inst/im2int16.m:          ISO-8859 text
>         inst/im2single.m:         ISO-8859 text
>         inst/im2uint16.m:         ISO-8859 text
>         inst/im2uint8.m:          ISO-8859 text
>         inst/imperspectivewarp.m: ISO-8859 text
>         inst/imremap.m:           ISO-8859 text
>         inst/imresize.m:          ISO-8859 text
>         inst/label2rgb.m:         ISO-8859 text
>
> This only affects the names of authors in the copyright notices, but is a
> nuisance for generating the debian/copyright file for the Debian package.

Fix with r11422. Can I further help with this by creating a proper
COPYRIGHT file for the package? I already tried to follow the debian
upstream guide http://wiki.debian.org/UpstreamGuide#Licenses that asks
to list each file and its license.

> 2) The function 'bwmorph' calls 'erode' and 'dilate', which are
> deprecated by the package itself.  It would be good to change the code
> to use imerode and imdilate.

Thanks. Fixed with r11420.

> 3) The function fftconv2 gives a wrong result when called like this:
> "fftconv2 (vector1, vector2, matrix)", although this usage is advertised
> in the help string.  For the Debian package, I am planning to apply the
> patch attached below, which (i) removes the advertisement from the help
> string, (ii) gives an error message when the function is called with the
> said usage and (iii) drop the tests with the said usage.

You forgot to attach the patch.

I don't know what changed to make this usage stop working so I only
left a note on the source code and should not appear on the help
string (at least it doesn't on my system).  Do not remove the tests,
mark them with xtest instead. I think I have done that before but
apparently forgot to commit. I'd give a warning instead of an error
since the reason it fails may be due to changes in the other functions
it uses and users with different versions may actually get the correct
results. Please see r11421.

Carnë

* Carnë Draug <car...@gm...> [2012-11-11 13:34]:
>
> Fix with r11422. Can I further help with this by creating a proper 
> COPYRIGHT file for the package? I already tried to follow the debian 
> upstream guide http://wiki.debian.org/UpstreamGuide#Licenses that asks 
> to list each file and its license.

This is not really necessary, but may help.  When putting together 
Debian packages, We use a tool called licencecheck (in package 
devscripts) that parses every upstream file and automatically generate a 
copyright file according to DEP5 (http://dep.debian.net/deps/dep5/). This 
file is further edited for reducing the number of stanzas.  I am 
attaching below the current debian/copyright file of the Debian package, 
which gets installed as /usr/share/doc/octave-image/copyright.

>> On 11 November 2012 09:54, Rafael Laboissiere <ra...@la...> wrote:
>>
>> 3) The function fftconv2 gives a wrong result when called like this: 
>> "fftconv2 (vector1, vector2, matrix)", although this usage is advertised 
>> in the help string.  For the Debian package, I am planning to apply the 
>> patch attached below, which (i) removes the advertisement from the help 
>> string, (ii) gives an error message when the function is called with the 
>> said usage and (iii) drop the tests with the said usage.
>
> You forgot to attach the patch.

Sorry.  Attached now.

> I don't know what changed to make this usage stop working so I only 
> left a note on the source code and should not appear on the help 
> string (at least it doesn't on my system).  Do not remove the tests, 
> mark them with xtest instead. I think I have done that before but 
> apparently forgot to commit. I'd give a warning instead of an error 
> since the reason it fails may be due to changes in the other functions 
> it uses and users with different versions may actually get the correct 
> results. Please see r11421.

Well, IMHO it is not a good idea to allow function to give results that 
are known to be wrong.  I will see with the other members of the DOG 
(Debian Octave Group) how we should proceed while waiting for the fix 
from upstream.

Thanks,

Rafael

On 11 November 2012 16:39, Rafael Laboissiere <ra...@la...> wrote:
> * Carnė Draug <car...@gm...> [2012-11-11 13:34]:
>>
>> Fix with r11422. Can I further help with this by creating a proper
>> COPYRIGHT file for the package? I already tried to follow the debian
>> upstream guide http://wiki.debian.org/UpstreamGuide#Licenses that asks to
>> list each file and its license.
>
> This is not really necessary, but may help.  When putting together Debian
> packages, We use a tool called licencecheck (in package devscripts) that
> parses every upstream file and automatically generate a copyright file
> according to DEP5 (http://dep.debian.net/deps/dep5/). This file is further
> edited for reducing the number of stanzas.  I am attaching below the current
> debian/copyright file of the Debian package, which gets installed as
> /usr/share/doc/octave-image/copyright.

That script is actually quite useful. I've been meaning to write
something like that for us for ages. However, it won't catch certain
exceptions. For example, the function edge was not only GPL. One of
its options had a user-written license which was stated in the middle
of the file. This is no longer the case and we are rejecting such
licenses http://octave.1599824.n4.nabble.com/removal-of-non-standard-licenses-in-Octave-Forge-td4645841.html

The DEP5 format is still a bit too complicated to parse automatically
and I don't want to cause problems to other distros. But I will try to
add the list of copyright owners names to the copyright file too and
run licensecheck to see if it struggles with anything.

>>> On 11 November 2012 09:54, Rafael Laboissiere <ra...@la...>
>>> wrote:
>>>
>>> 3) The function fftconv2 gives a wrong result when called like this:
>>> "fftconv2 (vector1, vector2, matrix)", although this usage is advertised in
>>> the help string.  For the Debian package, I am planning to apply the patch
>>> attached below, which (i) removes the advertisement from the help string,
>>> (ii) gives an error message when the function is called with the said usage
>>> and (iii) drop the tests with the said usage.
>>
>> You forgot to attach the patch.
>
> Sorry.  Attached now.
>
>> I don't know what changed to make this usage stop working so I only left a
>> note on the source code and should not appear on the help string (at least
>> it doesn't on my system).  Do not remove the tests, mark them with xtest
>> instead. I think I have done that before but apparently forgot to commit.
>> I'd give a warning instead of an error since the reason it fails may be due
>> to changes in the other functions it uses and users with different versions
>> may actually get the correct results. Please see r11421.
>
>
> Well, IMHO it is not a good idea to allow function to give results that are
> known to be wrong.  I will see with the other members of the DOG (Debian
> Octave Group) how we should proceed while waiting for the fix from upstream.

Do you know when they stopped working? Do the tests also failed back
on Octave 3.2.4 in Debian stable?

Carnë

On 11 November 2012 23:20, Carnë Draug <car...@gm...> wrote:
> On 11 November 2012 16:39, Rafael Laboissiere <ra...@la...> wrote:
>> * Carnė Draug <car...@gm...> [2012-11-11 13:34]:
>>> I don't know what changed to make this usage stop working so I only left a
>>> note on the source code and should not appear on the help string (at least
>>> it doesn't on my system).  Do not remove the tests, mark them with xtest
>>> instead. I think I have done that before but apparently forgot to commit.
>>> I'd give a warning instead of an error since the reason it fails may be due
>>> to changes in the other functions it uses and users with different versions
>>> may actually get the correct results. Please see r11421.
>>
>> Well, IMHO it is not a good idea to allow function to give results that are
>> known to be wrong.  I will see with the other members of the DOG (Debian
>> Octave Group) how we should proceed while waiting for the fix from upstream.
>
> Do you know when they stopped working? Do the tests also failed back
> on Octave 3.2.4 in Debian stable?

Apparently this has always been wrong. The reason why it tests didn't
fail back in 3.2.4 was because conv2 was wrong and fftconv2 was
replicating that wrongness. Now that conv2 has been fixed, the test
that compares it with conv2 fails. Basically this has never worked and
an error is indeed more appropriate here.

Thank you,
Carnë

Thread: [OctDev] image 2.0.0 released

A collection of packages providing extra functionality for GNU Octave

octave-dev