Rice to gaussian image

[astamm]

No description provided.

[astamm]

L'usage des fonctions spéciales selon le range donnant des résultats instables parfois, j'ai fait de nouvelles modifications. En particulier, il nous faudrait discuter sérieusement une potentielle dépendance à la librairie ARB. Rien pushé pour l'instant car j'ai introduit en local cette dépendance.

[ocommowi]

Pour la dependance, faut que je regarde ce qu'elle inclut. Deux / trois criteres que j'aurais :

• license compatible -> si c'est lgpl c'est bon
• utilisation (potentielle au moins) dans plusieurs outils (si c'est juste a un endroit, pour une fonction ou deux, c'est un peu embetant) -> a verifier
• librairie standalone -> c'est pas gagné et ca c'est penible
• multiplateforme -> a verifier
• est ce que c'est une petite lib ou un machin enorme ? -> a verifier

[astamm]

• Licence compatible: oui c'est L-GPL. Extrait du site de la librairie ARB "Arb is free software distributed under the GNU Lesser General Public License (LGPL), version 2.1 or later (see License)."
• Utilisation: pour moi, toutes les fonctions spéciales devraient être calculées via ARB. C'est la seule librairie que je connaisse qui en implémente autant avec arbitrary precision (+ précis tu payes en temps de calcul, c'est juste aller plus loin dans l'évaluation de séries infinies) pour n'importe quel range d'arguments. Boost n'est pas fait pour ca. Dans la doc de certaines fonctions, comme la Kummer qui fait partie de "Boost.math" version compilée, ils disent bien qu'ils ne cherchent pas a fournir des fonctions qui vont bien pour tous les range. En revanche, Boost fait un super boulot pour random generation (mais je crois que la librairie std C++ gère ca aussi bien, avec un peu de syntaxe a prendre en main) et évaluation numérique d'intégrale par quadrature Gaussienne, qui gagne un temps FOU sur la méthode des rectangles ou trapezes. Ils l'ont ajouté dans Boost 1.66 (on en est a 1.67 au passage, je sais pas si le super build gere la recuperation de la version la + récente ou pas). Donc, pour résumer, Arb utile partout ou on fait du Bessel/Hypergeometric/error functions/gamma functions/legendre (pour ODF non?) etc... Boost utile pour le random et calcul integral (en tout cas de mon point de vue).
• Arb dépend de GMP, MPFR et FLINT mais je vois dans leur doc qu'ils parlent d'une standalone compilation "To compile, test and install Arb from source as a standalone library, first install FLINT." Mais en fait, faut quand meme installer les 3 dépendances a priori.
• J'ai fait la manip de les installer aussi bien sur macOS (mon PC de travail) que Linux (serveurs) et ca va nickel, painless. Pas tester Windows. J'ai fait un fichier détaillant la procedure (très standard) pour le faire. Ca peut se scripter dans le Superbuild sans problème je pense.

[ocommowi]

Bon je te cache pas que les dependances multiples et surtout la dependance a pthread, que j'ai passe des mois a degommer, ne me fait pas rever la... Et en plus, les sous dependances n'ont pas de cmake lists...

[astamm]

Ah oui tiens, y aussi pthread c'est vrai. D'un autre cote, la lib est présente sur tous les OS il me semble par défaut, non? Du coup, qu'est-ce qui t'embête avec ca ?

[astamm]

Sinon les auteurs sont actifs et pro-discussion quand il s'agit d'utiliser leur lib. Donc on peut discuter la possibilité de rendre pthread optionnel (et p-e d'autres dependences mais j'ai des doutes pour les autres quand meme).

[astamm]

Tu analyses toujours l’idée ? Tu veux que j’en fasse qqch? Je contacte les auteurs pour demander des trucs ?

[ocommowi]

Le probleme est profond et a mon idee les auteurs voudront pas. Le gros souci de cette lib et de toutes ses dependances c'est que la compile (surtout sous windows) va etre tres penible. Et je ne les vois honnetement pas passer leur code pour eviter les dependances et se debarasser de pthread... Je regarde encore un peu mais je suis pas trop fan

[astamm]

Ils ont une section compile avec visual studio pour ce qui est de Windows. En tout cas, à part ces problèmes techniques, j’ai poussé un coup de gueule tout seul dans mon coin l’autre jour sur Anima sur le fait qu’on essaie d’implémenter ces fonctions spéciales nous mêmes avec un succès plus que modéré et ça prend du temps et c’est pas l’objectif d’Anima selon moi. On ferait mieux de se fier à une librairie externe spécialisé là dessus avec des gens qui en on trouve fait leur core research. Ton avis éclairé ?

[ocommowi]

Ok on va se calmer. Si je passe du temps la dessus, c'est que j'y vois l'interet. Effectivement virer ces fonctions degueu avec plein de chiffres en dur, ca me dit bien. Mais c'est pas une raison pour mettre une pletore de dependances toutes plus incompatibles cmake les unes que les autres (et donc merdiques a compiler dans un superprojet) et utilisant des vieux trucs genre pthread (a moitie deprecated sans le dire sous mac et tres vieux sous windows) et autres.

On va prendre une autre approche : le fork ! Avec un peu de chance, ca peut passer. Tu utilises quoi concretement de arb (j'en vois aucune mention dans la PR) ? Quelles fonctions, quels fichiers include, etc ? (on peut passer ca par mail peut etre d'ailleurs pour pas polluer). Que j'aille voir ce qu'on peut extraire ou non. Si on peut, je tente ca.

[ocommowi]

Bien, je modifie les trucs au fur et a mesure pour simplifier. Est ce que tu pourrais me dire pour les fonctions dans ARB special functions si elles ont un equivalent dans les special functions classiques ? Merci

[astamm]

Oui elles sont toutes (en tout cas celles qu'on utilise jusqu'a present) dans boost ou std. Par contre, sur macOS, je n'arrive pas a utiliser celle de de la norme C++17.

[ocommowi]

Cette histoire de C++17 ne m'etonne pas. Je soupconne apple de pas avoir encore implementé toutes les fonctions. Peut etre en septembre avec le nouvel os... En attendant, faut utiliser boost.

Je te prepare une version refusionnée et simplifiée des fonctions, tu me diras si j'ai fait n'importe quoi

[ocommowi]

Tu as fini la conversion des methodes ? Si oui, je regarde si ca compile pour ensuite merger bientot

[astamm]

Oui. Reste a voir pour log-Bessel. Y a p-e mieux a faire en utilisant la Bessel ratio. Mais ca changera juste les temps de calcul. La precision du résultat en l'état actuel devrait être bonne. D'ailleurs ca m'a fait découvrir boost::multiprecision qui est un header qui définit des types MPFR et autres pour avoir des precisions bien meilleures. P-e qu'une bonne maitrise de ca peut suffire pour les special functions. Mais la tout de suite j'ai pas le temps de regarder en profondeur. A se garder sous le coude. Ca pourrait permettre de s'affranchir de Arb. Si tu penses a répondre au gars d'ailleurs, ce serait cool. Sinon avant de merger, j'ai simplifié l'outil Rician to Gaussian noise en le faisant marcher pour image 3D plus simplement. Donc pas de bval bvec en input. C'est plus générique, je me demande si je pusherais pas cette version. Un avis sur le sujet ?

[astamm]

Voila. Apres 24 heures d'experimentation pour tenter vainement d'implementer la confluent hypergeometric qui n'est pas dans Boost.Math version header-only, j'en arrive a une pseudo-implementation qui semble fonctionner pour un range limité de valeurs. En l'occurence, c'est inutilisable pour cet outil de transfo de bruit. D'ou mon ajout de IF USE_ARB dans le CMake de cet outil pour ne meme pas le compiler si Arb n'est pas linkée avec Anima. Sinon j'ai rendu l'outil générique pour fonctionner avec tout ComponentType et un nombre de dimensions quelconque. Jusqu'a 3, il traite l'image telle quelle. Pour image 4D, elle est splittée sur la 4eme dimension en N images 3D qui subissent chacune le filtre avant d'être re-concatenées dans une image 4D. Au jour d'aujourd'hui et tant que Boost n'aura pas migré son implémentation de la hypergeom dans la partie header-only de Boost.Math, on ne peut pas décemment se passer de Arb. Et meme en fait, je relisai aujourd'hui que meme si on peut augmenter la precision des special functions de Boost via boost::multiprecision, il n'en reste pas moins que tous les ranges ne sont pas couverts car Boost n'a pas vocation de spécialiste en fonctions spéciales. Donc je pense qu'on va se trainer Arb ;-) Dis-moi ce que tu penses de tout ca. Pour moi, on peut merger dans le master. Pense stp a répondre au développeur de Arb a l'occasion.

[astamm]

Seems that Boost now includes a header-only implementation of Kummer function: www.boost.org/doc/libs/1_76_0/libs/math/doc/html/math_toolkit/hypergeometric/hypergeometric_1f1.html.
Also, it might be doable to add Arb dependency via MPIR/MPFR/Flint/Arb given recent availability of CMakeLists.