Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Contributor: bibifric05Réglages de base ?
#31
Et voilà tu recommences...

Il ne nous reste plus qu'à attendre la nouvelle version de DarkBibi 1.0 ?
"Donne un poisson à un homme, tu le nourris pour un jour. Apprends-lui à pêcher, tu le nourris pour toujours."
Pop Os! 64 Bits Gnome 3.32 Sony A7 et quelques vieux cailloux...
#32
Effectivement tu as raison c'est probablement pas difficile... C'est impossible. Répète après moi : impossible. Pourquoi ? Parceque tous les modules sont 100% indépendant et en plus ils ne travaille pas nécessairement depuis je même espace de couleur. Ce que tu propose serait d'avoir un module unique avec tous les devs intégrés donc casser toute l'architecture.

Je n'espère même plus te convaincre et je pense que je perds mon temps.

IMPOSSIBLE ok?

Désolé mais ça devient vraiment pénible.

Ce que tu veux n'est pas darktable trouve toi un autre logiciel et arrête de nous faire perdre notre temps.
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
#33
(31-12-17, 18:42)bibifric05 a écrit :
(30-12-17, 22:33)aurelienpierre a écrit : S'il y a bien un truc que j'ai appris en faisant du développement, c'est qu'on ne peut pas satisfaire tous les usages avec un seul outil, et que la conception, c'est des choix et des compromis à faire.

Dans DT, chaque pixel passe dans un « tuyau » où différents filtres sont installés dans un ordre immuable, dicté par la physique ou les maths du filtrage réalisé. Chaque filtre est piloté depuis un module. Du coup, restreindre le module à une zone est plus naturel (et probablement plus propre côté codage) que de « charger » une zone avec des modules et de les dupliquer dans l'interface. L'approche Une fonction = Un module est parfaitement rationnelle.

Mais comme Pascal l'a expliqué, tu peux centraliser la gestion des masques dans le module adéquat. La plupart des freins que te mentionnes n'en seraient pas si tu avais lu la doc et assouplis un peu tes paradigmes.

Admettons... Comment se fait-il alors que les autres logiciels fonctionnent tous sur le principe inverse (un calque ou une zone sur laquelle on applique une ou des corrections) ? Ceux que j'ai testés dernièrement : Lightroom, CaptureOne, Luminar, On1, DXO PhotoLab, AfterShot Pro, LightZone, PhotoFlow sont tous sur ce modèle. J'en oublie sûrement...

Parmi ceux-ci, j'ai d'ailleurs été impressionné par les U-point de DXO PhotoLab (issus des plug-in Nik Collection), que je trouve vraiment intuitifs, puissants et bien adaptés à la photo.

Quant à Darktable, cela fait plusieurs années que je m'y intéresse car il est puissant, libre et natif sous Linux. Non seulement je me suis fadé le manuel, mais pas mal des tutos de Carafife, et j'ai travaillé l'an dernier sur le code source pour modifier le pinceau, même si en fin de compte mes modifs ne m'ont pas satisfait.

J'ai fait plusieurs plugins pour Bibble il y a quelques années (USM, corrections LAB), donc oui je pense que je connais un peu le sujet...

En ce qui concerne le pinceau, le choix de Cairo est mal adapté car c'est du vectoriel et de base il n'y a pas de gestion du flou (on peut le rajouter, mais c'est une verrue, ça n'a pas été conçu pour ça). Le développeur a utilisé la même mise en oeuvre que pour les splines (sélection de type contour) et je le comprends car c'était plus simple. Mais il faudrait faire autrement, peut-être avec libmypaint, à voir... Il faut que l'on puisse voir l'étendue de la zone floue lorsque l'on dessine au pinceau et pas seulement après-coup en affichant le masque. Il ne faut pas que l'on voie tous les points de contrôle du tracé, idéalement il faudrait seulement que l'on puisse voir ceux de l'enveloppe concave, sauf que c'est compliqué quand il y a des "trous" dans le tracé au pinceau (ex : un tracé en 8).

J'aimerais bien travailler là-dessus, mais d'une part je n'ai pas le temps et puis je préfèrerais qu'un vrai développeur s'y mette...

Mon idée de réorganiser les modules en mettant dans un seul module les cinq ou six outils les plus courants ne me paraît pas contrevenir à la philo de Darktable et permettrait de gagner en efficacité lorsqu'on équilibre une image... Ça ne semble vraiment pas compliqué à mettre en oeuvre d'un point de vue codage.

En même temps, un pinceau en vectoriel, ça donne ça. Si tu veux gérer des flous de canal alpha, il faut passer en bitmap, comme ce que fait Photoshop avec ses masques et plein de raffinements cools comme le flux de la brosse, la détection de contours etc. Mais le bitmap ne se stocke pas dans une base de données, alors tu créées d'autres problèmes.

L'étendue de la zone floue est visible pendant le tracé au pinceau avec le contour en tirets. Dans ma pratique, c'est amplement suffisant, les sélections précises étant mieux gérées par l'outil chemin.

« Parmi ceux-ci, j'ai d'ailleurs été impressionné par les U-point de DXO PhotoLab (issus des plug-in Nik Collection), que je trouve vraiment intuitifs, puissants et bien adaptés à la photo. »

Je ne suis pas d'accord. La seule fois que j'ai utilisé des points de contrôle, c'était dans le module flou d'objectif de Photoshop, et je trouve que c'est la façon la moins intuitive de définir un masque vectoriel. Beaucoup trop approximatif, tu perds des heures à l'ajuster pour finir avec rien de satisfaisant à la fin. L'humain voit des contours, pas des champs de gradients.

« Mon idée de réorganiser les modules en mettant dans un seul module les cinq ou six outils les plus courants ne me paraît pas contrevenir à la philo de Darktable et permettrait de gagner en efficacité lorsqu'on équilibre une image... »

Je ne suis pas d'accord. Une retouche efficace suit des étapes balisées, idéalement le même ordre que celui d'application des modules. Si tu commences à répliquer les modules dans un ordre aléatoire, déjà qu'ils ne sont pas nécessairement dans l'ordre d'application, tu ouvres la portes de l'Enfer. Les modules de base sont déjà dans l'onglet du même nom (le premier), je ne vois pas ce qu'on peut faire de plus.


« J'aimerais bien travailler là-dessus, mais d'une part je n'ai pas le temps et puis je préfèrerais qu'un vrai développeur s'y mette... »

On est tous logés à la même enseigne. Dans mes cartons, j'ai un module de déconvolution aveugle par apprentissage machine, un module de débruitage, et un algo de dématriçage qui débruite en même temps… Et moi aussi, j'aimerais bien me contenter de pondre l'algo mathématique et de laisser l'intégration en C à des gens qui le maîtrisent, mais ça n'arrivera pas, alors il faut que j'apprenne le C et le fonctionnement interne de DT sur mon temps libre de sommeil.
Aurélien, photographe portraitiste, spécialiste calcul.
Développeur de filmique, égaliseur de tons, balance couleur, etc.
darktable est mon métier, pensez à m'aider :
[Image: 2FAd4rc]
#34
Citation :Ce que tu veux n'est pas darktable trouve toi un autre logiciel et arrête de nous faire perdre notre temps.

Pas mieux ! :/
"Donne un poisson à un homme, tu le nourris pour un jour. Apprends-lui à pêcher, tu le nourris pour toujours."
Pop Os! 64 Bits Gnome 3.32 Sony A7 et quelques vieux cailloux...
#35
(31-12-17, 19:22)aurelienpierre a écrit : En même temps...

<En même temps, un pinceau en vectoriel, ça donne ça. Si tu veux gérer des flous de canal alpha, il faut passer en bitmap, comme ce que fait Photoshop avec ses masques et plein de raffinements cools comme le flux de la brosse, la détection de contours etc. Mais le bitmap ne se stocke pas dans une base de données, alors tu créées d'autres problèmes.>

En fait, je pense qu'on peut (peut-être) faire ceci : lorsqu'on dessine au pinceau, on peut flouter le cercle du pinceau de façon à reproduire (ça sera approximatif je pense, mais sans doute suffisant) le masque qui sera appliqué... Ensuite on stocke comme d'habitude le tracé vectoriel du masque et on peut le modifier. J'ai en tout cas l'intention d'essayer ça... Il faudrait aussi simplifier le tracé du masque en éliminant les points inutiles, mais je n'ai pas trouvé de méthode satisfaisante pour le moment...

Quant au bitmap qui ne se stocke pas dans une base de données, je ne sais pas si tu as raison. Le bitmap est une section de données comme une autre, donc on peut la mettre dans la base de données, non ? En plus, un masque se compresse aisément et ne prend pas de place, donc cette option est aussi à envisager.

<L'étendue de la zone floue est visible pendant le tracé au pinceau avec le contour en tirets. Dans ma pratique, c'est amplement suffisant, les sélections précises étant mieux gérées par l'outil chemin.>

Personnellement, ça ne me satisfait pas du tout ! Il faut absolument améliorer cet outil pinceau...


<U-Point : Je ne suis pas d'accord. La seule fois que j'ai utilisé des points de contrôle, c'était dans le module flou d'objectif de Photoshop, et je trouve que c'est la façon la moins intuitive de définir un masque vectoriel. Beaucoup trop approximatif, tu perds des heures à l'ajuster pour finir avec rien de satisfaisant à la fin. L'humain voit des contours, pas des champs de gradients.>

En fait, du temps de Bibble j'avais la même opinion que toi et je trouvais que le pinceau n'avait pas grand intérêt, je n'utilisais quasiment que les contours et je dénigrais Lightroom qui n'avait pas ce type d'outil. Et puis un jour j'ai vu une video de Serge Ramelli sur Lightroom, qui expliquait très bien la puissance du pinceau avec le dégradé de flou quand on peint. En fait, le pinceau agit exactement comme on le faisait sous l'agrandisseur avec les mains et non seulement c'est amplement suffisant, mais ça permet de doser les effets par petites touches, c'est hyper pratique et intuitif ! Comme disait Serge Ramelli, "on peint avec la lumière". Une fois qu'on a compris ça, c'est difficile de revenir en arrière...

Les U-point, c'est un peu la même chose. Je les ai pratiqués avec les plugins (gratuits) de Nik Collection. C'est très puissant et très intuitif. Ça traite l'image par zones aux contours flous et ça convient parfaitement aux images de type photographies (pas au détourage ni au design, évidemment). Les gens de DXO l'on bien compris et l'on intégré dans leur outil, mais il y a aussi un pinceau. Dommage que DXO ne traite pas les capteurs Fuji (alors que Darktable le fait, un bon point pour lui) !

< Réorganiser les modules : Je ne suis pas d'accord. Une retouche efficace suit des étapes balisées, idéalement le même ordre que celui d'application des modules. Si tu commences à répliquer les modules dans un ordre aléatoire, déjà qu'ils ne sont pas nécessairement dans l'ordre d'application, tu ouvres la portes de l'Enfer. Les modules de base sont déjà dans l'onglet du même nom (le premier), je ne vois pas ce qu'on peut faire de plus.

Non, je pensais à créer un module unique comportant les principaux réglages de base (balance des blancs, exposition, points noir et blanc, ...). D'une part, dans la plupart des cas ce type de retouche est suffisant. D'autre part, cela faciliterait les corrections locales (plus besoin d'aller rappeler des masques sur plein de modules).

<Sur mon temps libre de sommeil.

Je sais bien... Tu peux rajouter "vie de famille" aussi...

(31-12-17, 18:52)Carafife a écrit : Et voilà tu recommences...

Il ne nous reste plus qu'à attendre la nouvelle version de DarkBibi 1.0 ?

Un petit fork ne me ferait pas peur... J'ai juste un problème pour le nom : Alone in the Dark (déjà pris), Dark en ciel (Vermot lu), DarkNet (attire la police), Dark Vador (trop de royalties à payer)...

Si tu as des idées, je suis preneur...
#36
Don't feed the Troll!

Je pense même qu'a ce stade le compte de bibifric05 devrait être désactivé. Il ne lit pas, n'écoute pas, et persiste à nous em....er.
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
#37
Je me permets d’intervenir sur ce fil pour la deuxième fois. darktable.fr est un forum d’utilisateurs ou l’on parle de l’utilisation de darktable et pas de sa conception. darktable a ses avantages et ses inconvénients comme tous logiciels. Pascal est un des développeurs et Aurélien a proposé des recherches et participe avec un développeur pour les adapter à darktable.
Pour ce faire bibifric05, il existe plusieurs façons de rejoindre l’équipe de développement :
https://www.darktable.org/development/
https://www.darktable.org/contact/
Il existe aussi un site ou poser des demandes de développement et/ou d’amélioration :
https://redmine.darktable.org
Bien sûr (comme je le fais avec la déconvolution proposée par Aurélien), je me ferais un plaisir de les compiler et d’essayer et d’en parler ici.
Je pense qu’il est temps d’arrêter cette discussion.
#38
[quote pid='18388' dateline='1514794741']
Si tu as des idées, je suis preneur...
[/quote]

Il me semblait bien t'en avoir déjà proposé un...


Citation :DarkBibi 1.0

Quand on te dit que tu n'écoutes pas....
"Donne un poisson à un homme, tu le nourris pour un jour. Apprends-lui à pêcher, tu le nourris pour toujours."
Pop Os! 64 Bits Gnome 3.32 Sony A7 et quelques vieux cailloux...
#39
(01-01-18, 10:45)jpg54 a écrit : Je me permets d’intervenir sur ce fil pour la deuxième fois. darktable.fr est un forum d’utilisateurs ou l’on parle de l’utilisation de darktable et pas de sa conception.

Ah bon... Vu qu'il y a des développeurs ici, je pensais que ça les intéresserait...

Bien sûr, je préfère discuter en français mais j'irai volontiers proposer mes idées sur la mailing list des développeurs...

Sinon, merci à Aurélien, qui m'a paru le plus ouvert (et le moins agressif) d'entre vous...

Merci aussi à jpverrue pour ses conseils sur les réglages de base...
#40
(01-01-18, 13:59)bibifric05 a écrit :
(01-01-18, 10:45)jpg54 a écrit : Je me permets d’intervenir sur ce fil pour la deuxième fois. darktable.fr est un forum d’utilisateurs ou l’on parle de l’utilisation de darktable et pas de sa conception.

Ah bon... Vu qu'il y a des développeurs ici, je pensais que ça les intéresserait...

Bien sûr, je préfère discuter en français mais j'irai volontiers proposer mes idées sur la mailing list des développeurs...

Sinon, merci à Aurélien, qui m'a paru le plus ouvert (et le moins agressif) d'entre vous...

Merci aussi à jpverrue pour ses conseils sur les réglages de base...

Pas de quoi ; aider tout un chacun dans sa découverte de darktable fait partie de ma contribution. Mais puisque je suis cité, je me permets d'intervenir à nouveau dans ce fil. J'ai lu attentivement toutes les interventions et j'ai été particulièrement choqué par les tiennes. Certes il n'est pas interdit de discuter sur tel ou tel point du logiciel. Mais insister comme tu le fais devient pratiquement insultant, surtout pour ceux qui mouillent leur chemise pour faire avancer ce logiciel.

Je ne veux pas discuter de la possibilité ou de l'utilité de telle ou telle fonctionnalité. Moi aussi il y a des choses que je trouve un peu mal foutues dans darktable ; rien n'est parfait. Mais, si des choses ne te conviennent pas, plutôt que de le crier ad libitum, retrousse toi les manches et code. Sois constructif, écoute ce que te disent les développeurs qui participent à ce forum. Fais des propositions concrètes. Soumets les aux concepteurs. Et, si elles sont intéressantes elles seront intégrées dans darktable.

Compte tenu du niveau de tension entre tous, pour éviter que les choses s'enveniment, je verrouille ce sujet.
Mes photos : jpverrue.fr


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)