Skip to content
This repository has been archived by the owner on Nov 19, 2020. It is now read-only.

Accord.NET v4.0 - Roadmap #2123

Open
10 tasks
cesarsouza opened this issue May 28, 2020 · 19 comments
Open
10 tasks

Accord.NET v4.0 - Roadmap #2123

cesarsouza opened this issue May 28, 2020 · 19 comments
Milestone

Comments

@cesarsouza
Copy link
Member

cesarsouza commented May 28, 2020

Hello all,

As you may know, project development has been in a hiatus for quite some time now.

However, I see that the project is still considered useful for many, and I do not think it would be in the interest of anyone to let the project die. I initially considered that the project would be superseeded by ML.NET, but this does not have to be the case. We can transform the framework to work alongside it instead.

I am therefore creating a roadmap for changes that would be nice to be done in order to improve maintainability of the project and bring it to life again.

  • Create a new branch for the project to focus exclusively on .NET Core 3.1 / .NET Standard 2.1 (Migrate to .NET Core #2120).
  • Drop all platform-specific compatibility fillers (i.e. for Mono, Unity).
  • Drop all methods and classes marked as [Obsolete].
  • Drop all classes and methods that can not be licensed under MIT (all files that have only my name in the copyright header can; for the others we may need to e-mail the other authors and ask if they allow their contributions to be shared under the MIT).
  • Drop the scripts for creating InnoSetup installers, .zip archivers, and other things that are not relevant anymore in the current .NET world.
  • Drop Sandcastle and all related Sandcastle scripts.
  • Start by keeping only namespaces that users have found it useful and that continue to be useful. Those could be only:
    • Core
    • Statistics
    • Math
    • MachineLearning
  • Note: Some of the above namespaces could be merged into a single project, so users would not need to reference so many libraries in their projects, but I haven't thought deeply about this yet... Comments are welcome.
  • Port relevant unit tests to xUnit
  • Port relevant documentation parts to work with DocFx.

Note: if anything proves too difficult to port, feel free to drop it too. The goal is to have an usable first version that targets only .NET Standard and that can be built easily using the current version of VS and .NET Core tools. We can do like MS did with core and gradually re-incorporate dropped functionalities in future versions.

If anyone would like to share what they think about it, please feel free to comment on it!

@cesarsouza cesarsouza changed the title Accord.NET v3.0 - Roadmap Accord.NET v4.0 - Roadmap May 28, 2020
@cesarsouza cesarsouza added this to the 4.0 milestone May 28, 2020
@cesarsouza
Copy link
Member Author

cesarsouza commented May 28, 2020

If this first step is done, then future releases can focus on bringing back support for other platforms like Unity (as I have used the framework myself for it in the past and it was indeed useful).

@cesarsouza cesarsouza pinned this issue May 28, 2020
@cesarsouza
Copy link
Member Author

Another thing, I think I would move the FFMPEG project to another library/project entirely. It is just too complicated to maintain it while keeping it within the framework, and the fact that the framework is complex to build makes it hard for other users to debug/contribute fixes to it.

@justingruenberg
Copy link
Contributor

justingruenberg commented May 28, 2020

I'd add the Imaging and VisionVideo namespaces, too. That's a good chunk of what I use. No problem with moving implementations of IVideoSource to new projects.

@AvenSun
Copy link

AvenSun commented May 28, 2020

@cesarsouza

It's such an excited news to all fans of Accord.Net.
It was many years ago, I began to learn image preocssing && ML at school.
I like c# and found Aforge && Accord after gooled a lot.
untill now Aforge&&Accord is also my one favorite.
It's light weight and effective.
thanks for your great effort for OSS !

@cesarsouza
Copy link
Member Author

I'd add the Imaging and Vision namespaces, too. That's a good chunk of what I use. No problem with moving implementations of IVideoSource to new projects.

Thanks for the feedback @justingruenberg. I initially left those out because in my opinion they would be the hardest and most boring to port. Not that difficult though, but I believe it would involve making small changes in lots of files. They could be added later.

I am not sure when I would have the time to work on any of those issues in the map though, if anyone would like to help just join in. I think I just need to first setup the initial branch for this new version, then we are good to start.

@justingruenberg
Copy link
Contributor

I ran those through Microsoft's Portability Analyzer, and it actually looks Imaging and Video should be mostly good to go for netcore3.1.

ApiPortAnalysis(1).xlsx

@AvenSun
Copy link

AvenSun commented May 28, 2020

what I often used is Core/Math/Imaging/Statistics/ML.
It can be compiled into .NET Standard 2/2.1 easily after some modification,
actually I've run it on some IoT devices smoothly. e.g. Nvidia Jetson Nano && TX2

@cesarsouza
Copy link
Member Author

cesarsouza commented May 28, 2020

Cool! That's really nice to hear. Last time I worked on this, I think core/standard 2.0 was still in preview or had just barely been released. Also, they had just introduced the .csproj project format for .NET core. At the moment the framework keeps two versions of the solution, one for core and one for .NET. In this new branch, this should definitely be removed...

@justingruenberg
Copy link
Contributor

Probably should add migrating to the new SDK-style projects to the list. I think there might be some issues with T4 files, though.

@fdncred
Copy link
Collaborator

fdncred commented May 28, 2020

I'm an advocate of the Aforge/Accord Imaging components. That's what I used most. The latest Visual Studio and dotnet core supports WinForms Gui controls as well. There are cross platform imaging libraries these days but I'm still fond of Accord.

@cesarsouza
Copy link
Member Author

Hi all,

Just to give an update; I still haven't created the new branch as I wrote to some of the previous developers regarding the license change and I am waiting answers. I wanted to start already the branch already completely under the MIT license.

Regards,
Cesar

@AvenSun
Copy link

AvenSun commented Jun 3, 2020

be a fan so long time and ready to make a little contribution .
looking forward to the new branch .

@hzawary
Copy link
Contributor

hzawary commented Jun 9, 2020

Hi Cesar,

Welcome back to your Accord.NET :) I'm glade to hear sounds of you. I was grow up with the great framework and still now work with it (specially blob processing :) after Aforge.NET.
I wish you good luck and healthy in injustice world every where you left to go.

Yours sincerely,
__HZ

@barrybriggs
Copy link

This is great news. Selection of namespaces is fine (these four are the ones I use). No need to consolidate namespaces into one; might be more trouble than it's worth. Great to make it MIT and to be able to compile under VS2019 w/o downloading additional packages. Looking forward to running under .NET Core!

@davidrapan
Copy link

Awesome! We had to migrate Accord to Core some time ago, alongside with fixing some issues (System.Drawing.Common, etc.) so rly wonderful news that project will comes to life again :) And that MIT is nice too ;)
I wish GL to all.

Regards,
Dave.

@cesarsouza
Copy link
Member Author

Hello all,

To give an update: Unfortunately (and really unfortunately) - I could not get the permission to re-release the core of the framework under the MIT license yet. I still really believe this would be really important to guarantee the project could have a definite future.

Regards,
Cesar

@justingruenberg
Copy link
Contributor

Is that a “they said no” or “no response received”?

@davidrapan
Copy link

As much as i know its about not responding at all.

@cesarsouza
Copy link
Member Author

Hello all,

I finally received some of the responses. I will not be able to re-release the core parts I wanted under the MIT. However, any files in the project that have only my name on the headers are now available under the MIT license.

Given this, I will soon be deciding to archive the project, after adding some updates to the README before that happens. Anyone else will be able to fork the project. And as stated, any files written by me are 100% available under the MIT. Any other files that include other authors have been properly identified with their contact information on their respective headers, and as such, it should always become possible to directly ask any of those other developers for a MIT-compatible license if you choose to base any of your next programs based on source code from this project.

I have to say, it has been an amazing 12 years since I first started this project.

I just can't thank everyone enough, for having taken the time to try and use things I have written, and to have liked it so much they would provide the feedback and contributions that would have kept all of this growing into the project it became for so long.

Cesar

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants