Si, ça m'a effaré quand j'ai lu par exemple ceci :
Béhé: Le recul il est là : la concurrence est telle que les auteurs réussissent à foutre en l’air le seul outil qui leur permettait de faire respecter quelques droits.
Boulet: Et on se tue aussi à vous le répéter, Béhé et moi: on ne reproche strictement RIEN à cet auteur, juste à Glénat qui ne fait que plumer un pigeon.
Je serais à la place de David Revoy, je n'apprécierais pas trop d'être traité de la sorte (ni de naïf, ou autre, comme c'est fait dans d'autres commentaires plus loin).
David Revoy a fait un choix de licence libre assumé dès le départ (il y a plusieurs années maintenant), il savait très bien ce qu'il faisait, et ce que ces licences impliquaient. La licence autorise Glénat à publier sans reverser de royalties, point barre. C'est pas comme si David pensait que ça ne pouvait pas arriver un jour. Soit on respecte le choix de l'auteur (et dans ce cas, on respecte aussi le fait que Glénat se conforme à cette licence, et fait même un peu plus dans ce cas). Ou alors on ne respecte pas le choix de l'auteur, et on assume aussi (ce qu'ils ne font pas dans leurs commentaires), mais alors ça me fait penser un peu aux anti "mariage pour tous" qui veulent se mêler de la vie des autres, alors qu'en réalité ça n'a aucune conséquence dans leur vie à eux.
Au contraire, il faudrait juste saluer le courage de son "expérimentation" et le succès qui va avec !
Le logiciel libre n'a pas tué le logiciel propriétaire, la musique libre n'a pas tué la vente de CDs, et la BD libre ne va surement pas détruire les auteurs de BDs qui passent par le circuit plus classique des éditeurs. La réaction de peur qu'ils montrent ici est à mon sens grotesque.
C'est effarant de lire les réactions de Béhé et Boulet sur les autres liens. A croire qu'ils ne se sont jamais renseignés sur la façon dont le libre fonctionne aussi dans les autres domaines de la création (logiciels, musique,…).
Tiens oui, en passant je peux signaluer qu'il y aussi le filtre Artistic / Engrave qu'est pas mal pour convertir une image en style plus ou moins cartoon. Par exemple :
Je vois plutôt G'MIC comme un "compagnon" à ImageMagick.
Je ne suis pas spécialiste de ImageMagick du tout, mais j'ai l'impression que G'MIC est moins à l'aise que ImageMagick pour tout ce qui est conversion entre différents formats d'images, mais plus flexible pour tout ce qui est filtrage et création d'effets personnalisés. C'est aussi les retours que j'ai eu d'utilisateurs des deux logiciels. Je serais super intéressé par une comparaison exhaustive des fonctionnalités en fait.
Oui, comme je le dis dans la dépêche, ça peut être un problème super difficile à résoudre, suivant la complexité de la texture d'entrée. Si la texture ne présente pas beaucoup d'auto-similarité, y a peu de chances que ça fonctionne de manière satisfaisante. Dans les dépêches, j'essaye toujours de mettre des exemples qui marchent bien pour illustrer l'algo, mais il est bien entendu que tous les algos présentés ne marchent pas toujours aussi bien avec toutes les images. On est bien loin de l'efficacité des Experts : Miami :)
Pour le code de simulation du daltonisme, je te l'ai mis là : http://pastebin.com/UTN2vxvC
Attention, c'est écrit en langage G'MIC (le langage de script avec lequel la majorité des filtres est écrit). Tu peux voir les coefs des différentes matrices de transformation colorimétriques utilisées qui apparaissent clairement dans le code.
Bon, j'ai eu un peu de temps hier soir, j'ai fait un premier essai de filtre (disponible dans le plug-in ce matin) pour rendre une texture "répétitive".
Voilà ce que ça donne : https://plus.google.com/+GMIC_software/posts/T5NpTigcVco
Ca se base aussi sur l'algo Patchmatch bien entendu. Surement encore à améliorer, mais déjà pas si mal !
Vois la chose du bon côté : c'est en testant des trucs avec mémé Julia, qu'on peut au final utiliser ces trucs pour faire de l'inpainting, de la re-synthèse de texture et pleins de bonnes choses à venir.
Bon, tu extrapoles un peu… J'ai jamais dit que je trouvais finalement que GEGL était bien foutu hein :)
J'ai jamais été un grand fan de GEGL, mais puisqu'il faut l'utiliser pour s'interfacer avec GIMP, alors on le fait sans discuter. Mais honnêtement, je suis pas sûr que vouloir l'imposer comme norme pour les autres logiciels de graphisme ou de rendu soit une très bonne idée. Ce n'est pas une bibliothèque encore assez générique à mon goût.
C'est un peu Mitch qui m'a rassuré, et qui m'a aiguillé sur comment faire pour utiliser les buffers GEGL à partir du plug-in (mais par contre non, on a pas encore un noeud GEGL :) ).
Ca se fera peut-être un jour cela dit.
Je pense avoir toujours cherché mes images (autres que Lena et Scarlett) avec des moteurs de recherche donnant un choix dans la licence de réutilisation, en l'occurence "Flickr Creative Commons Search" et "Google Image", avec choix d'une licence permissive. Mais il est possible que ces moteurs m'aient renvoyé des images non autorisées à un moment donnée.
Si une photo en particulier pose problème, je peux probablement re-générer un exemple avec d'autres photos "autorisées" si besoin est.
On a pas dit que CImg était une bibliothèque juste "bas-niveau", mais plus "bas-niveau" que la libgmic ce qui est quand même assez différent. Mais bon, passons…
CImg est une bibliothèque très customisable, et peut effectivement utliser tout pleins de bibliothèques externes additionnelles comme libjpeg, libtiff, etc.. pour gérer ses entrées-sorties (possibilité qui est utilisée dans G'MIC). Aucune bibliothèque sérieuse de traitement d'image existante ne ré-implemente ce genre d'opérations de toute façon (je parle bien de bibliothèques de "traitement", pas juste de gestion d'un format d'image). Mais de toute façon, CImg peut aussi se compiler avec un minimum de dépendances si besoin est (avec juste libm et libc, c'est assez "bas-niveau" ça va ? :) ) pour permettre de travailler juste avec des buffers de données en entrées-sorties comme tu le suggères. D'ailleurs c'est ce qui est fait dans la configuration par défaut de CImg, aucune dépendance autre n'est nécessaire, il faut au contraire les activer de manière explicite pour en profiter. Donc je ne sais pas d'ou tu tiens ton affirmation. Va voir le Makefile des exemples de CImg, tu verras qu'on peut activer/désactiver chaque dépendance de manière très fine.
Oui, en fait générer une texture tuilable peut être vu comme un problème d'inpainting des bords, avec des conditions aux bords périodiques. Ca peut se faire dans G'MIC effectivement, c'est une bonne idée pour faire un filtre "Make Seamless Texture". Je vais essayer de bidouiller ça quand j'aurais un moment.
Le gros problème des images de type "HDR" qu'on voit un peu partout, ce n'est pas vraiment le HDR en soi, c'est plutôt que les gens ont tendance à forcer un peu sur les paramètres de l'étape de Tone Mapping, qui est l'étape permettant de générer une image à dynamique normale à partir d'une image à haute dynamique.
Et c'est ça qui donne des images avec un look très artificiel. Mais on peut tout à faire faire du HDR "normal" en effectuant un Tone Mapping plus subtil, même de manière automatisé
(et ça donne le genre d'images que tu décris).
Ca reste du HDR quand même (on construit une image haute dynamique à partir de plusieurs images à des temps de pose différents), mais l'image tone-mappée parait plus "normale" avec simplement des détails visibles à la fois dans les zones sombres et les zones claires.
Mais c'est clair qu'il y a un peu d'abus sur le Tone Mapping en général :)
Ce que tu décris est, il me semble, le principe du HDR.
Il existe effectivement des algos qui fusionnent ce genre d'images tout seul, mais c'est encore un sujet actif en recherche (car quand ça bouge entre deux poses comme tu le dis, ça peut devenir très compliqué à gérer de manière automatique).
Oui, ce problème de détection de manipulation d'image est un problème assez classique.
Je ne crois pas que quelqu'un de chez nous travaille là dessus en particulier. Mais dans le cadre des algorithmes d'inpainting, les reconstruction ne sont pas très compliquées à détecter (de manière algorithmique): Comme l'algorithme d'inpainting fonctionne en faisant des copier-coller de bouts d'images à l'intérieur de la zone à reconstruire, il suffit de regarder pour chaque patch de l'image (voisinage centré) s'il n'apparait pas déjà ailleurs dans l'image (même en version légèrement différente).
En général c'est suffisant pour détecter un traficotage d'image par inpainting.
Oui, le filtre d'inpainting utilise les améliorations portées à l'évaluateur d'expressions introduites dans la dernière version 1.6.8. La preview du filtre donne normalement un message spécifiant que la version 1.6.8 est nécessaire pour faire fonctionner ce filtre.
Merci pour ton commentaire Pierre. Je suis convaincu que les artistes peuvent avoir des besoins considérés comme "non-triviaux" en traitement d'image, qui mériteraient qu'on s'y attarde un peu plus. J'avoue que c'est le genre de thématique ouverte qui m'intéresse particulièrement. Après il faut avoir des contacts intéressants (ça j'en ai) mais surtout des moyens de financement de tels travaux de recherche (ça c'est plus dur). Le financement de la recherche publique se fait aujourd'hui essentiellement via des réponses à des appels à projets (ANR ou autres), et les thématiques des projets financés sont rarement dans ce domaine, qui n'est pas vraiment prioritaire pour nos différentes institutions (et on peut le comprendre aussi).
# Raclette
Posté par David Tschumperlé (site web personnel) . En réponse au sondage Mon plat plat préféré. Évalué à 4.
Je vois vraiment pas ce qui pourrait détrôner une bonne raclette, plat fin et équilibré par excellence (et potentiellement très varié).
[^] # Re: Réaction (saine) de Bruno Bellamy
Posté par David Tschumperlé (site web personnel) . En réponse au journal Pepper et Carrot. Évalué à 5.
Si, ça m'a effaré quand j'ai lu par exemple ceci :
Je serais à la place de David Revoy, je n'apprécierais pas trop d'être traité de la sorte (ni de naïf, ou autre, comme c'est fait dans d'autres commentaires plus loin).
David Revoy a fait un choix de licence libre assumé dès le départ (il y a plusieurs années maintenant), il savait très bien ce qu'il faisait, et ce que ces licences impliquaient. La licence autorise Glénat à publier sans reverser de royalties, point barre. C'est pas comme si David pensait que ça ne pouvait pas arriver un jour. Soit on respecte le choix de l'auteur (et dans ce cas, on respecte aussi le fait que Glénat se conforme à cette licence, et fait même un peu plus dans ce cas). Ou alors on ne respecte pas le choix de l'auteur, et on assume aussi (ce qu'ils ne font pas dans leurs commentaires), mais alors ça me fait penser un peu aux anti "mariage pour tous" qui veulent se mêler de la vie des autres, alors qu'en réalité ça n'a aucune conséquence dans leur vie à eux.
Au contraire, il faudrait juste saluer le courage de son "expérimentation" et le succès qui va avec !
Le logiciel libre n'a pas tué le logiciel propriétaire, la musique libre n'a pas tué la vente de CDs, et la BD libre ne va surement pas détruire les auteurs de BDs qui passent par le circuit plus classique des éditeurs. La réaction de peur qu'ils montrent ici est à mon sens grotesque.
# Réaction (saine) de Bruno Bellamy
Posté par David Tschumperlé (site web personnel) . En réponse au journal Pepper et Carrot. Évalué à 6.
Enfin un autre auteur de BD qui me parait sain d'esprit, et qui comprend la démarche de David Revoy :
http://bellaminettes.com/blog/?p=6050
C'est effarant de lire les réactions de Béhé et Boulet sur les autres liens. A croire qu'ils ne se sont jamais renseignés sur la façon dont le libre fonctionne aussi dans les autres domaines de la création (logiciels, musique,…).
La route est encore vraiment longue…
[^] # Re: photo surdessinée ?
Posté par David Tschumperlé (site web personnel) . En réponse au journal Quand 01net nous explique ce qu’est un hacker. Évalué à 10.
Tiens oui, en passant je peux signaluer qu'il y aussi le filtre Artistic / Engrave qu'est pas mal pour convertir une image en style plus ou moins cartoon. Par exemple :
Et la vidéo tutoriel : https://www.youtube.com/watch?v=YUWqTRS9_zk
[^] # Re: Les problémes recontré par imageMagick sont un bonne occassion pour G'Mic
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC 1.7.1 : quand les fleurs bourgeonnent, les filtres d'images foisonnent.. Évalué à 10.
Je vois plutôt G'MIC comme un "compagnon" à ImageMagick.
Je ne suis pas spécialiste de ImageMagick du tout, mais j'ai l'impression que G'MIC est moins à l'aise que ImageMagick pour tout ce qui est conversion entre différents formats d'images, mais plus flexible pour tout ce qui est filtrage et création d'effets personnalisés. C'est aussi les retours que j'ai eu d'utilisateurs des deux logiciels. Je serais super intéressé par une comparaison exhaustive des fonctionnalités en fait.
[^] # Re: Make seamless
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC 1.7.1 : quand les fleurs bourgeonnent, les filtres d'images foisonnent.. Évalué à 8.
Oui, comme je le dis dans la dépêche, ça peut être un problème super difficile à résoudre, suivant la complexité de la texture d'entrée. Si la texture ne présente pas beaucoup d'auto-similarité, y a peu de chances que ça fonctionne de manière satisfaisante. Dans les dépêches, j'essaye toujours de mettre des exemples qui marchent bien pour illustrer l'algo, mais il est bien entendu que tous les algos présentés ne marchent pas toujours aussi bien avec toutes les images. On est bien loin de l'efficacité des Experts : Miami :)
[^] # Re: Make seamless
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC 1.7.1 : quand les fleurs bourgeonnent, les filtres d'images foisonnent.. Évalué à 6.
Oui là ça devient un peu compliqué effectivement. Je vais réfléchir à la question :)
[^] # Re: Super !
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC 1.7.1 : quand les fleurs bourgeonnent, les filtres d'images foisonnent.. Évalué à 5.
Pour le code de simulation du daltonisme, je te l'ai mis là : http://pastebin.com/UTN2vxvC
Attention, c'est écrit en langage G'MIC (le langage de script avec lequel la majorité des filtres est écrit). Tu peux voir les coefs des différentes matrices de transformation colorimétriques utilisées qui apparaissent clairement dans le code.
[^] # Re: Transfert de style
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC 1.7.1 : quand les fleurs bourgeonnent, les filtres d'images foisonnent.. Évalué à 4.
C'est le genre d'applications qui m'intéresse fortement effectivement. Je vais regarder le papier en détails.
[^] # Re: G'MIC dans Blender
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC 1.7.1 : quand les fleurs bourgeonnent, les filtres d'images foisonnent.. Évalué à 4.
Oui c'est le but. J'avoue que je n'ai pas encore essayé, je ne maitrise pas du tout Blender.
[^] # Re: Lien ?
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 7.
Effectivement, bonne suggestion. Je vais rajouter ce lien sur la page du plug-in.
[^] # Re: Invocation réussie !
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 4.
Du coup j'en parlerai dans la prochaine dépêche :)
[^] # Re: Invocation réussie !
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 7.
Bon, j'ai eu un peu de temps hier soir, j'ai fait un premier essai de filtre (disponible dans le plug-in ce matin) pour rendre une texture "répétitive".
Voilà ce que ça donne : https://plus.google.com/+GMIC_software/posts/T5NpTigcVco
Ca se base aussi sur l'algo Patchmatch bien entendu. Surement encore à améliorer, mais déjà pas si mal !
[^] # Re: j'ai adoré...
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 7.
Vois la chose du bon côté : c'est en testant des trucs avec mémé Julia, qu'on peut au final utiliser ces trucs pour faire de l'inpainting, de la re-synthèse de texture et pleins de bonnes choses à venir.
[^] # Re: Prêt pour GIMP 2.10
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 5.
Bon, tu extrapoles un peu… J'ai jamais dit que je trouvais finalement que GEGL était bien foutu hein :)
J'ai jamais été un grand fan de GEGL, mais puisqu'il faut l'utiliser pour s'interfacer avec GIMP, alors on le fait sans discuter. Mais honnêtement, je suis pas sûr que vouloir l'imposer comme norme pour les autres logiciels de graphisme ou de rendu soit une très bonne idée. Ce n'est pas une bibliothèque encore assez générique à mon goût.
[^] # Re: Prêt pour GIMP 2.10
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 4.
C'est un peu Mitch qui m'a rassuré, et qui m'a aiguillé sur comment faire pour utiliser les buffers GEGL à partir du plug-in (mais par contre non, on a pas encore un noeud GEGL :) ).
Ca se fera peut-être un jour cela dit.
[^] # Re: Œuvres d'art ?
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 3.
Si on trouve un moyen de financer le déplacement, oui c'est tout à fait possible effectivement.
[^] # Re: Copyright
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 10.
De quelles images parlent tu ?
Je pense avoir toujours cherché mes images (autres que Lena et Scarlett) avec des moteurs de recherche donnant un choix dans la licence de réutilisation, en l'occurence "Flickr Creative Commons Search" et "Google Image", avec choix d'une licence permissive. Mais il est possible que ces moteurs m'aient renvoyé des images non autorisées à un moment donnée.
Si une photo en particulier pose problème, je peux probablement re-générer un exemple avec d'autres photos "autorisées" si besoin est.
[^] # Re: Lib pas vraiment utilisable
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 10.
Ce que tu affirmes est complètement faux :
On a pas dit que CImg était une bibliothèque juste "bas-niveau", mais plus "bas-niveau" que la libgmic ce qui est quand même assez différent. Mais bon, passons…
CImg est une bibliothèque très customisable, et peut effectivement utliser tout pleins de bibliothèques externes additionnelles comme libjpeg, libtiff, etc.. pour gérer ses entrées-sorties (possibilité qui est utilisée dans G'MIC). Aucune bibliothèque sérieuse de traitement d'image existante ne ré-implemente ce genre d'opérations de toute façon (je parle bien de bibliothèques de "traitement", pas juste de gestion d'un format d'image). Mais de toute façon, CImg peut aussi se compiler avec un minimum de dépendances si besoin est (avec juste libm et libc, c'est assez "bas-niveau" ça va ? :) ) pour permettre de travailler juste avec des buffers de données en entrées-sorties comme tu le suggères. D'ailleurs c'est ce qui est fait dans la configuration par défaut de CImg, aucune dépendance autre n'est nécessaire, il faut au contraire les activer de manière explicite pour en profiter. Donc je ne sais pas d'ou tu tiens ton affirmation. Va voir le
Makefile
des exemples de CImg, tu verras qu'on peut activer/désactiver chaque dépendance de manière très fine.[^] # Re: Invocation réussie !
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 7.
Oui, en fait générer une texture tuilable peut être vu comme un problème d'inpainting des bords, avec des conditions aux bords périodiques. Ca peut se faire dans G'MIC effectivement, c'est une bonne idée pour faire un filtre "Make Seamless Texture". Je vais essayer de bidouiller ça quand j'aurais un moment.
[^] # Re: filtre
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 6.
Le gros problème des images de type "HDR" qu'on voit un peu partout, ce n'est pas vraiment le HDR en soi, c'est plutôt que les gens ont tendance à forcer un peu sur les paramètres de l'étape de Tone Mapping, qui est l'étape permettant de générer une image à dynamique normale à partir d'une image à haute dynamique.
Et c'est ça qui donne des images avec un look très artificiel. Mais on peut tout à faire faire du HDR "normal" en effectuant un Tone Mapping plus subtil, même de manière automatisé
(et ça donne le genre d'images que tu décris).
Ca reste du HDR quand même (on construit une image haute dynamique à partir de plusieurs images à des temps de pose différents), mais l'image tone-mappée parait plus "normale" avec simplement des détails visibles à la fois dans les zones sombres et les zones claires.
Mais c'est clair qu'il y a un peu d'abus sur le Tone Mapping en général :)
[^] # Re: filtre
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 5. Dernière modification le 11 décembre 2015 à 16:14.
Ce que tu décris est, il me semble, le principe du HDR.
Il existe effectivement des algos qui fusionnent ce genre d'images tout seul, mais c'est encore un sujet actif en recherche (car quand ça bouge entre deux poses comme tu le dis, ça peut devenir très compliqué à gérer de manière automatique).
[^] # Re: Détecter l’inpainting
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 10.
Oui, ce problème de détection de manipulation d'image est un problème assez classique.
Je ne crois pas que quelqu'un de chez nous travaille là dessus en particulier. Mais dans le cadre des algorithmes d'inpainting, les reconstruction ne sont pas très compliquées à détecter (de manière algorithmique): Comme l'algorithme d'inpainting fonctionne en faisant des copier-coller de bouts d'images à l'intérieur de la zone à reconstruire, il suffit de regarder pour chaque patch de l'image (voisinage centré) s'il n'apparait pas déjà ailleurs dans l'image (même en version légèrement différente).
En général c'est suffisant pour détecter un traficotage d'image par inpainting.
[^] # Re: Filtre d'inpainting
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 3.
Oui, le filtre d'inpainting utilise les améliorations portées à l'évaluateur d'expressions introduites dans la dernière version 1.6.8. La preview du filtre donne normalement un message spécifiant que la version 1.6.8 est nécessaire pour faire fonctionner ce filtre.
[^] # Re: Œuvres d'art ?
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 5.
Merci pour ton commentaire Pierre. Je suis convaincu que les artistes peuvent avoir des besoins considérés comme "non-triviaux" en traitement d'image, qui mériteraient qu'on s'y attarde un peu plus. J'avoue que c'est le genre de thématique ouverte qui m'intéresse particulièrement. Après il faut avoir des contacts intéressants (ça j'en ai) mais surtout des moyens de financement de tels travaux de recherche (ça c'est plus dur). Le financement de la recherche publique se fait aujourd'hui essentiellement via des réponses à des appels à projets (ANR ou autres), et les thématiques des projets financés sont rarement dans ce domaine, qui n'est pas vraiment prioritaire pour nos différentes institutions (et on peut le comprendre aussi).