Re: Binary descriptors for OpenCV

Re: Binary descriptors for OpenCV

[Nathan Dehnel]

>No idea whether this is FSF's official stand but in a talk[0] Richard
Stallman said that the training data is not relevant as long as the
network can be tweaked by retraining, i.e. the weights are licesenced so
that modifications are allowed.

Is this even practically possible? How do you re-train a blob you know
nothing about? To me this sounds similar to saying a compiled binary
is free software if the license allows you to decompile it and
deobfuscate it.

Re: Binary descriptors for OpenCV

[Saku Laesvuori]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

> Is this even practically possible? How do you re-train a blob you know
> nothing about? To me this sounds similar to saying a compiled binary
> is free software if the license allows you to decompile it and
> deobfuscate it.

If you know how to convert the blob to weights in the neural network
(something the program has to do to make any use of the blob) and know
the error function, you can continue the training with new data.

This is not any different from training the model from scratch. In both
cases we begin with some set of initial weights for a huge polynomial,
take a sample of our training data, compute the polynomial for it and
tweak the weights a bit if the result was not what we wanted. The only
difference is that when training from scratch we begin with very bad
guesses for all the weights. When we are tuning the blob we begin with
much better guesses that are closer to the values we would actually
want.

The difference to a compiled binary program is that you would want to
edit it in the source code form. You really would not want to edit the
neural network by editing the original training data and retraining the
entire network from scratch. The data set probably contains thousands,
tens of thousands or even more random pictures that you would have to go
through and see if they represent the data and results you want. It
would be much easier to test whether the network gives the correct
results and train it with new data that you know describes your problem
better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Binary descriptors for OpenCV

[Nathan Dehnel]

>If you know how to convert the blob to weights in the neural network
(something the program has to do to make any use of the blob) and know
the error function, you can continue the training with new data.

Yeah, I get that, but you don't necessarily know what the weights
mean. Let's charitably assume you know the blob works on image data
(instead of audio data or whatever). Do you know if it needs to be
trained on images of a particular size, or color depth, or encoding,
or color format, etc.? And what about models for more complex data
than images like genetic data? How do you know you're not going to end
up with a network that spews out invalid garbage if you re-train it
with things that are incompatible with the original training dataset?
And how do you know that, beyond trial and error, unless you have the
original dataset?

On Tue, Aug 1, 2023 at 3:37 PM Saku Laesvuori <saku@laesvuori.fi> wrote:
>
> > Is this even practically possible? How do you re-train a blob you know
> > nothing about? To me this sounds similar to saying a compiled binary
> > is free software if the license allows you to decompile it and
> > deobfuscate it.
>
> If you know how to convert the blob to weights in the neural network
> (something the program has to do to make any use of the blob) and know
> the error function, you can continue the training with new data.
>
> This is not any different from training the model from scratch. In both
> cases we begin with some set of initial weights for a huge polynomial,
> take a sample of our training data, compute the polynomial for it and
> tweak the weights a bit if the result was not what we wanted. The only
> difference is that when training from scratch we begin with very bad
> guesses for all the weights. When we are tuning the blob we begin with
> much better guesses that are closer to the values we would actually
> want.
>
> The difference to a compiled binary program is that you would want to
> edit it in the source code form. You really would not want to edit the
> neural network by editing the original training data and retraining the
> entire network from scratch. The data set probably contains thousands,
> tens of thousands or even more random pictures that you would have to go
> through and see if they represent the data and results you want. It
> would be much easier to test whether the network gives the correct
> results and train it with new data that you know describes your problem
> better.

Re: Binary descriptors for OpenCV

[Saku Laesvuori]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

> >If you know how to convert the blob to weights in the neural network
> >(something the program has to do to make any use of the blob) and know
> >the error function, you can continue the training with new data.
> 
> Yeah, I get that, but you don't necessarily know what the weights
> mean. Let's charitably assume you know the blob works on image data
> (instead of audio data or whatever). Do you know if it needs to be
> trained on images of a particular size, or color depth, or encoding,
> or color format, etc.? And what about models for more complex data
> than images like genetic data?

You can always check what kind of data the program gives to the neural
network as the program is free software. If the data is valid runtime
input it is also valid training data. 

> How do you know you're not going to end up with a network that spews
> out invalid garbage if you re-train it with things that are
> incompatible with the original training dataset? And how do you know
> that, beyond trial and error, unless you have the original dataset?

You can't exactly *know* that any extra training doesn't break the model
but the same holds for editing the original training data. It is only
very likely that training with new data improves the model, but you
can't know it before you try.

In this specific case we also do have access to the training data. We
just don't want to spend the computing resources on training the model
from scratch.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Binary descriptors for OpenCV

[Nathan Dehnel]

>You can always check what kind of data the program gives to the neural
network as the program is free software. If the data is valid runtime
input it is also valid training data.

That's not necessarily true. Like an image generating program will be
trained on image + caption pairs, but running it involves giving it
just the captions. Thus, running the model doesn't inherently show you
how to retrain the model.

>You can't exactly *know* that any extra training doesn't break the model
but the same holds for editing the original training data.

You can know with more certainty that it doesn't break the model.

On Tue, Aug 1, 2023 at 11:46 PM Saku Laesvuori <saku@laesvuori.fi> wrote:
>
> > >If you know how to convert the blob to weights in the neural network
> > >(something the program has to do to make any use of the blob) and know
> > >the error function, you can continue the training with new data.
> >
> > Yeah, I get that, but you don't necessarily know what the weights
> > mean. Let's charitably assume you know the blob works on image data
> > (instead of audio data or whatever). Do you know if it needs to be
> > trained on images of a particular size, or color depth, or encoding,
> > or color format, etc.? And what about models for more complex data
> > than images like genetic data?
>
> You can always check what kind of data the program gives to the neural
> network as the program is free software. If the data is valid runtime
> input it is also valid training data.
>
> > How do you know you're not going to end up with a network that spews
> > out invalid garbage if you re-train it with things that are
> > incompatible with the original training dataset? And how do you know
> > that, beyond trial and error, unless you have the original dataset?
>
> You can't exactly *know* that any extra training doesn't break the model
> but the same holds for editing the original training data. It is only
> very likely that training with new data improves the model, but you
> can't know it before you try.
>
> In this specific case we also do have access to the training data. We
> just don't want to spend the computing resources on training the model
> from scratch.

Re: Binary descriptors for OpenCV

[Saku Laesvuori]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

> >You can always check what kind of data the program gives to the
> >neural network as the program is free software. If the data is valid
> >runtime input it is also valid training data.
> 
> That's not necessarily true. Like an image generating program will be
> trained on image + caption pairs, but running it involves giving it
> just the captions. Thus, running the model doesn't inherently show you
> how to retrain the model.

In that case aren't the captions the input to the model and the images
the output? The training process tries to minimize the error between the
correct output from the data set and the generated output. From using
the model you do know what formats are expected as input and output, so
you do have the information required for retraining.

> >You can't exactly *know* that any extra training doesn't break the
> >model but the same holds for editing the original training data.
> 
> You can know with more certainty that it doesn't break the model.

Well, that depends on what kind of data editing and extra training we
are comparing. If we remove a tiny bit from the original data set, it
obviously is less likely to break the model than retraining it with bad
data. But if you had a new training data set, it would not be any
different to retrain the pretrained model on it instead of adding the
new data set into the original training data and training from scratch.

I should probably mention that I have never tried retraining models in
practice and I'm basing all my arguments on my theoretical understading
of how machine learning models work.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Binary descriptors for OpenCV

[Nathan Dehnel]

Perhaps such greyzone objects that can't be fully regenerated should
be put in their own channel so users know where they are and it
doesn't become a mystery how many they have installed on their
systems.

Re: Binary descriptors for OpenCV

[Ricardo Wurmus]

Nathan Dehnel <ncdehnel@gmail.com> writes:

> Perhaps such greyzone objects that can't be fully regenerated should
> be put in their own channel so users know where they are and it
> doesn't become a mystery how many they have installed on their
> systems.

I would want put a variant of the opencv package in the guix-science
channel if we decide not to include them, because xfeatures2d is useful
for feature detection in scientific applications (that’s the only reason
why I’m looking into this).

However, it would be good to come up with a policy anyway.

And of course it would be nicer if we could avoid further fragmentation,
as we’d need to push all packages that depend on this variant of opencv
to that separate channel, too.

-- 
Ricardo

Re: Binary descriptors for OpenCV

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Nathan Dehnel <ncdehnel@gmail.com> writes:
>
>> Perhaps such greyzone objects that can't be fully regenerated should
>> be put in their own channel so users know where they are and it
>> doesn't become a mystery how many they have installed on their
>> systems.
>
> I would want put a variant of the opencv package in the guix-science
> channel if we decide not to include them, because xfeatures2d is useful
> for feature detection in scientific applications (that’s the only reason
> why I’m looking into this).
>
> However, it would be good to come up with a policy anyway.

Yes, the problem is machine-learning output comes up more and more
frequently.

I agree we need to come up with a policy (I’m a bit torn on this and not
too sure what I’d put in there.)  Maybe we should set up a working group
with interested parties to draft something; who’s in?

Ludo’.

Re: Binary descriptors for OpenCV

[Nathan Dehnel]

Yeah, sure, I could offer my input.

On Wed, Aug 16, 2023 at 11:55 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hi,
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
> > Nathan Dehnel <ncdehnel@gmail.com> writes:
> >
> >> Perhaps such greyzone objects that can't be fully regenerated should
> >> be put in their own channel so users know where they are and it
> >> doesn't become a mystery how many they have installed on their
> >> systems.
> >
> > I would want put a variant of the opencv package in the guix-science
> > channel if we decide not to include them, because xfeatures2d is useful
> > for feature detection in scientific applications (that’s the only reason
> > why I’m looking into this).
> >
> > However, it would be good to come up with a policy anyway.
>
> Yes, the problem is machine-learning output comes up more and more
> frequently.
>
> I agree we need to come up with a policy (I’m a bit torn on this and not
> too sure what I’d put in there.)  Maybe we should set up a working group
> with interested parties to draft something; who’s in?
>
> Ludo’.

Re: Binary descriptors for OpenCV

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Nathan Dehnel <ncdehnel@gmail.com> writes:
>>
>>> Perhaps such greyzone objects that can't be fully regenerated should
>>> be put in their own channel so users know where they are and it
>>> doesn't become a mystery how many they have installed on their
>>> systems.
>>
>> I would want put a variant of the opencv package in the guix-science
>> channel if we decide not to include them, because xfeatures2d is useful
>> for feature detection in scientific applications (that’s the only reason
>> why I’m looking into this).
>>
>> However, it would be good to come up with a policy anyway.
>
> Yes, the problem is machine-learning output comes up more and more
> frequently.
>
> I agree we need to come up with a policy (I’m a bit torn on this and not
> too sure what I’d put in there.)  Maybe we should set up a working group
> with interested parties to draft something; who’s in?

I don't feel specially qualified to discuss this issue; perhaps it'd
best be left to the people the FSF to draft new guidelines / expound the
GNU FSDG with these new realities?

-- 
Thanks,
Maxim

Re: Binary descriptors for OpenCV

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> Yes, the problem is machine-learning output comes up more and more
>> frequently.
>>
>> I agree we need to come up with a policy (I’m a bit torn on this and not
>> too sure what I’d put in there.)  Maybe we should set up a working group
>> with interested parties to draft something; who’s in?
>
> I don't feel specially qualified to discuss this issue; perhaps it'd
> best be left to the people the FSF to draft new guidelines / expound the
> GNU FSDG with these new realities?

I agree we should take input from free software activists both within
and outside the project.  My experience is that the FSF may not be as
active as we’d like, as evidenced by the gnu-linux-libre mailing list
discussions, but there are certainly other projects looking into this in
very concrete terms, such as Debian.

Ludo’.

Binary descriptors for OpenCV

[Ricardo Wurmus]

Hi Guix,

I’d like to draw your attention to https://issues.guix.gnu.org/64945.
It’s a patch that adds binary descriptors to OpenCV.

These descriptors are the result of a very expensive computation, which
could be performed with lots of memory and GPUs.  The result is a small
number of very small descriptors in binary format, which OpenCV can use
as an input to a feature detection algorithm.

This is probably one of the simplest cases of machine learning output;
the output is small and compared to other machine learning models
require only a small amount of computation.  But it’s above the
threshold for our build farm and not something we can have users
recompute on install.

The software used to generate these descriptors is freely licensed, and
the descriptors are living in the twilight zone of assets that are not
quite software but clearly not just decorative either.  They are large
arguments to image feature detection algorithms, much like an image mask
would be.

What shall we do with this patch?  Can we accept it or does it cross a
line we don’t want to cross?

-- 
Ricardo

Re: Binary descriptors for OpenCV

[Maxim Cournoyer]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Guix,
>
> I’d like to draw your attention to https://issues.guix.gnu.org/64945.
> It’s a patch that adds binary descriptors to OpenCV.
>
> These descriptors are the result of a very expensive computation, which
> could be performed with lots of memory and GPUs.  The result is a small
> number of very small descriptors in binary format, which OpenCV can use
> as an input to a feature detection algorithm.
>
> This is probably one of the simplest cases of machine learning output;
> the output is small and compared to other machine learning models
> require only a small amount of computation.  But it’s above the
> threshold for our build farm and not something we can have users
> recompute on install.
>
> The software used to generate these descriptors is freely licensed, and
> the descriptors are living in the twilight zone of assets that are not
> quite software but clearly not just decorative either.  They are large
> arguments to image feature detection algorithms, much like an image mask
> would be.
>
> What shall we do with this patch?  Can we accept it or does it cross a
> line we don’t want to cross?

We should ask what is the FSF's opinion about it, if they have one.  I
personally see trained data models as data more than code; so when their
licensing allows them to be redistributed I see no objection to package
them in Guix.

One example is the 'tesseract-ocr-tessdata-fast' package, which contains
the data of the trained models.  Debian also packages the models of the
different languages as 'tesseract-ocr-eng, 'tesseract-ocr-fra',
etc. [0]; even Parabola offers with its 'tesseract-data-*' packages [1].

[0]  https://packages.debian.org/search?suite=stable&section=all&arch=any&searchon=names&keywords=tesseract
[1]  https://www.parabola.nu/groups/x86_64/tesseract-data/

-- 
Thanks,
Maxim

Re: Binary descriptors for OpenCV

[Saku Laesvuori]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

> We should ask what is the FSF's opinion about it, if they have one.
> personally see trained data models as data more than code; so when their
> licensing allows them to be redistributed I see no objection to package
> them in Guix.

No idea whether this is FSF's official stand but in a talk[0] Richard
Stallman said that the training data is not relevant as long as the
network can be tweaked by retraining, i.e. the weights are licesenced so
that modifications are allowed.

I personally see that as a good way to look at them from a software
freedom standpoint. From a bootstrappability standpoint it's more
problematic but I think that in that perspective network weights are
much more like data than software. I'd assume it's much easier to audit
the model by looking at how it behaves than by inspecting the source
data. It's also easier to edit the weights by training the model with
new data than by retraining the model from scratch with a modified
data set.

[0]: https://audio-video.gnu.org/video/richard-stallman-university-of-pisa-2023-06-07.webm (around 58:40–1:04:00)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Binary descriptors for OpenCV

[Simon Tournier]

Hi,

On Mon, 31 Jul 2023 at 15:12, Ricardo Wurmus <rekado@elephly.net> wrote:

> What shall we do with this patch?  Can we accept it or does it cross a
> line we don’t want to cross?

I concur with Maxim’s message.  If the license is compliant for
redistributing, then I do not see any blocker for inclusion.

Somehow, I do not any difference with the package ’gnubg’ for example;
well my opinion is expressed in this thread [1]:

        The only question for inclusion or not is about the license, IMHO.  For
        sure, it is far better if we are able to recompute the weights.
        However, similarly as debootstrapping is a strong recommendation, the
        ability to recompute the pre-trained neural network weights must just be
        a recommendation.

where “neural network weights” reads in this case “binary descriptors”.

We need to do our best for reducing at most the “opacity” but the
criteria for inclusion is about the license and not about our resource
for bootstrapping all from bare-metal.  To be precise, we are accepting
to “cheat” for some compilers as GHC or Chicken.  From my point of view,
the case of Chicken is very similar to these “descriptors”, no?

Similarly, many packages use Autotools files generated by upstream and
we do not regenerate all of them.  Because that’s not the criteria for
inclusion.  The criteria is about the license, whatever if we speak
about human-readable source code, non human-readable source code, or any
other data.

1: https://yhetil.org/guix/87wn0qrmdx.fsf@gmail.com/#r
2: https://issues.guix.gnu.org/issue/22366

Cheers,
simon

Re: Binary descriptors for OpenCV

[Ludovic Courtès]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> Somehow, I do not any difference with the package ’gnubg’ for example;
> well my opinion is expressed in this thread [1]:

Would you like to (co-)lead a working group (maybe with Nathan, maybe
with help from free software folks outside the project too) on this
subject?

Discussions on “where to draw the line” could help us make progress
towards concrete guidelines.

Ludo’.