Bon là pour le coup, je suis un peu dégouté parce que le rédacteur chargé de l'article était sensé être un vrai photographe et non seulement l'article est relativement creux (malgré la mise à dispo d'un press book) mais en plus il me porte préjudice à tord...
Contacté sur le sujet, le rédacteur, qui n'a même pas daigné me faire relire son article avant publication alors qu'il m'avait contacté pour disposer d'une licence gracieuse, est bien sûr incapable de me fournir les photos incriminées.
Le souci c'est que je connais le problème et il ne vient pas de moi mais de softs de correction optique comme DxO qui modifient la taille des fichiers de l'appareil en post prod. Pour une raison que j'ignore un même lots d'images identiques peut se retrouver avec des tailles divergentes de plusieurs pixels en largeur ou hauteur en sortie de post-traitement. Elles sont alors rejetées par mon logiciel car l'empilement impose naturellement de traiter des photos identiques. Et quand j'en fais éco au journaliste copies d'écran à l'appui, plus de nouvelles... comme c'est étrange... Il ne s'est même pas donné la peine de faire un simple cmd+i avec Aperçu pour vérifier ses propos avant de rédiger son article.
J'espérais que la presse écrite avait encore un minimum de sérieux. J'ai de plus en plus le sentiment que les articles de test sont surtout là pour faire du remplissage aujourd'hui. C'est bien dommage.
Avec ton message d'erreur, est-ce que tu indique dans le détail la liste des résolutions des images en entrée ? Montrer l'information fautive aide à régler ce genre de réaction.
Effectivement, iCreate FR a traduit l'article tel que. C'est balo.
yoann, non pas encore. Je m'étais contenté d'un message d'erreur simpliste tellement c'était improbable mais j'en ai pris de la graine pour la prochaine mise à jour.
A noter que ce n'est pas de l'OpenGL mais de la projection matricielle côté CPU. Rotation, translation, distorsion, zoom, seuils min/max, exposition, contraste, saturation et tonalité sélective (clairs, moyens, ombres et noirs) sont calculés à la volée en une seule passe à partir du bitmap brute pleine résolution (aucune tricherie avec une image réduite en amont pour donner le change).
OpenCL est aussi en cours d'investigation mais résultats mitigés dans l'immédiat. Voir ce post.
La démo est réalisée sur un Mac Pro Xéon 8 coeurs de 2008. Les i7 actuels sont maintenant bien plus véloces.
Mais ce qui est intéressant, c'est de pousser un peu le moteur de rendu. Ici un essai avec un HDR extrapolé à plus de 88 millions de pixels (11 520x7 680)...
Une prochaine étape sera sans doute le morphing temps réel pour les corrections optiques complexes et autres. En attendant, ces optimisations devraient plaire aux amateurs de HDRs panoramiques tout en préparant le terrain pour les petits frères à venir.
Le fait de pouvoir travailler directement au niveau pixel est un gros avantage notamment pour l'édition au pinceau.
Mais on touche là ce que j'appelle le " syndrome objet ": à trop vouloir compartimenter les algorithmes et/ou utiliser des API pré-fabriquées, on en arrive à des aberrations de performances catastrophiques. Je ne rentrerais pas trop dans les optimisations internes de MarScaper sur un forum à accès public mais je vais prendre un exemple générique très concret et assez révélateur: un histogramme...
Un autre petit exemple d'optimisation simple. Core Graphics, contrairement à ce qu'on peut souvent lire, est une API relativement lente. Dans le logiciel, on peut voir que le HDR est affiché avec un petit bord blanc.
Voici ce que donne Instrument avec NSBezierPath en surimpression...
Un autre petit exemple d'optimisation simple. Core Graphics, contrairement à ce qu'on peut souvent lire, est une API relativement lente.
On se doute que ça va être moins rapide que d'aller changer les octets en mémoire. Mais que donne l'utilisation de CGRectFill(), par exemple ? Les courbes de Bézier sont lentes, par principe.
Et comme Core Graphics n'est pas thread safe, tout doit être fait dans le thread principal ce qui constitue un gros goulet d'étranglement pour une application multi-thread.
J'ai toujours pensé que Core Graphics était thread safe. J'ignore dans quelle mesure c'est vrai. Par exemple, il me semble possible de dessiner dans des CGBitmapContext dans un thread secondaire. Je ne trouve rien dans la doc d'Apple à ce sujet... il faut croire que ça ne les intéresse pas.
NSBezierPath est une surcouche générique mais un bezierPathWithRect reste un path de 4 points (sans bézier) et le passage direct par l'API C de Core Graphics n'y change donc rien...
C'est pour ça qu'on ne peut pas faire de mise à jour de l'UI en multithread
Il semble que j'ai réussi à me faire mentir. C'est tordu à souhait mais c'est réalisable. Sur un simple Mac Book Air 11" de 2011, le display du HDR passe alors de 20fps à 60fps (au taquet de la synchro verticale écran -Beam Sync-)...
Merci à vous deux. La prochaine étape ce sera une refonte de la retouche aux pinceaux pour l'adapter au nouveau moteur graphique et l'enrichir. Mais dans l'immédiat, je bosse sur un petit frère.
Non Pyroh, c'est juste que grace à Apple je suis le cul entre deux chaises sur ma machine de dev qui me sert aux tutos avec ma licence de ScreenFlow. La marche forcée imposée par Apple au niveau d'Xcode se fait malheureusement au complet détriment de la compatibilité descendante. Je suis donc bloqué à Xcode 6.2 et Mac OS X 10.9 pour l'instant. Car contrairement à Apple, j'assure la compatibilité descendante jusqu'à 10.7 par respect de mes clients (dont bcp de pro qui ne font pas évoluer leur parc au bon grès du calendrier d'Apple). Ceci dit, je prends note de ta remarque pour les prochaines vidéos. J'essaierai à minima de mettre un fond d'écran non lié à la version d'os histoire que ce soit moins flagrant.
Réponses
T'as vu, Apple largue Aperture... Un nouveau créneau pour Mars ?
Avec ton message d'erreur, est-ce que tu indique dans le détail la liste des résolutions des images en entrée ? Montrer l'information fautive aide à régler ce genre de réaction.
Il me semble qu'il y a un article dans le iCreate FR 104 actuellement en kiosque.
Regarde sur : http://www.icreate.fr/magazine/le-magazine/item/338-au-sommaire-d-icreate-n-104 (vignette 27)
Me revoilà après cure d'iode prolongée.
Effectivement, iCreate FR a traduit l'article tel que. C'est balo.
yoann, non pas encore. Je m'étais contenté d'un message d'erreur simpliste tellement c'était improbable mais j'en ai pris de la graine pour la prochaine mise à jour.
Oui j'ai vu ça. C'est à méditer.
Un premier aperçu du nouveau moteur graphique temps réel de MarScaper sur un HDR de 22,1MP...
http://www.marscaper.com/videos/marscaper_engine.mp4
A noter que ce n'est pas de l'OpenGL mais de la projection matricielle côté CPU. Rotation, translation, distorsion, zoom, seuils min/max, exposition, contraste, saturation et tonalité sélective (clairs, moyens, ombres et noirs) sont calculés à la volée en une seule passe à partir du bitmap brute pleine résolution (aucune tricherie avec une image réduite en amont pour donner le change).
OpenCL est aussi en cours d'investigation mais résultats mitigés dans l'immédiat. Voir ce post.
Quel CPU ? C'est fluide en effet.
La démo est réalisée sur un Mac Pro Xéon 8 coeurs de 2008. Les i7 actuels sont maintenant bien plus véloces.
Mais ce qui est intéressant, c'est de pousser un peu le moteur de rendu. Ici un essai avec un HDR extrapolé à plus de 88 millions de pixels (11 520x7 680)...
http://www.marscaper.com/videos/marscaper_engine_88mp.mp4
Une prochaine étape sera sans doute le morphing temps réel pour les corrections optiques complexes et autres. En attendant, ces optimisations devraient plaire aux amateurs de HDRs panoramiques tout en préparant le terrain pour les petits frères à venir.
Etonné de voir que tu manipules l'image en grosse def alors d'autres softs bien plus connus semblent utiliser de la basse def pour les manipulation ?
Le fait de pouvoir travailler directement au niveau pixel est un gros avantage notamment pour l'édition au pinceau.
Mais on touche là ce que j'appelle le " syndrome objet ": à trop vouloir compartimenter les algorithmes et/ou utiliser des API pré-fabriquées, on en arrive à des aberrations de performances catastrophiques. Je ne rentrerais pas trop dans les optimisations internes de MarScaper sur un forum à accès public mais je vais prendre un exemple générique très concret et assez révélateur: un histogramme...
Tu es mon Lumia 640 bleu
>:(
Les pions se mettent en place. La manipulation à la souris est quasi achevée. Cela me plait bien côté intéractivité...
real-time-transformation-tools.mp4
Et voici un aperçu d'intégration dans MarScaper HDR lorsqu'on souhaite éditer l'alignement de ses images à la main...
Un autre petit exemple d'optimisation simple. Core Graphics, contrairement à ce qu'on peut souvent lire, est une API relativement lente. Dans le logiciel, on peut voir que le HDR est affiché avec un petit bord blanc.
Voici ce que donne Instrument avec NSBezierPath en surimpression...
J'ai toujours pensé que Core Graphics était thread safe. J'ignore dans quelle mesure c'est vrai. Par exemple, il me semble possible de dessiner dans des CGBitmapContext dans un thread secondaire. Je ne trouve rien dans la doc d'Apple à ce sujet... il faut croire que ça ne les intéresse pas.
NSBezierPath est une surcouche générique mais un bezierPathWithRect reste un path de 4 points (sans bézier) et le passage direct par l'API C de Core Graphics n'y change donc rien...
BRAVO ! et merci pour ces intéressants commentaires.
Petit fil de discussion très sympa où l'on apprend des chose
Sinon belle appli. On voit la passion que tu y mets.
Il semble que j'ai réussi à me faire mentir. C'est tordu à souhait mais c'est réalisable. Sur un simple Mac Book Air 11" de 2011, le display du HDR passe alors de 20fps à 60fps (au taquet de la synchro verticale écran -Beam Sync-)...
ça c'est une nouvelle qui est bonne !
Tu nous dirais comment tu fais ?
Yep mais ce sera en off via MP pour le coup car se faire spolier par des produits concurrents j'ai donné.
MarScaper HDR continue son petit bonhomme de chemin. Histoire de faire vivre un peu ce thread voici la liste des goodies pour la version 1.3.x:
- Amélioration de l'alignement automatique et manuel avec prise en charge de la correction de perspective et de rotation.
DeÌjaÌ€ beau, beau, beau boulot pour ce qui est des nouvelles fonctionnaliteÌs !
C'est aussi sympa ce petit tuto du creÌateur !
Par contre OSX 10.9 ??? Tu veux faire peur aux gens ?
Merci à vous deux. La prochaine étape ce sera une refonte de la retouche aux pinceaux pour l'adapter au nouveau moteur graphique et l'enrichir. Mais dans l'immédiat, je bosse sur un petit frère.
Non Pyroh, c'est juste que grace à Apple je suis le cul entre deux chaises sur ma machine de dev qui me sert aux tutos avec ma licence de ScreenFlow. La marche forcée imposée par Apple au niveau d'Xcode se fait malheureusement au complet détriment de la compatibilité descendante. Je suis donc bloqué à Xcode 6.2 et Mac OS X 10.9 pour l'instant. Car contrairement à Apple, j'assure la compatibilité descendante jusqu'à 10.7 par respect de mes clients (dont bcp de pro qui ne font pas évoluer leur parc au bon grès du calendrier d'Apple). Ceci dit, je prends note de ta remarque pour les prochaines vidéos. J'essaierai à minima de mettre un fond d'écran non lié à la version d'os histoire que ce soit moins flagrant.
La petite nouveauté de la version 1.3.1 sortie cette semaine: possibilité de mettre en évidence les masques de fusion du système de calques...
Pense à faire tes vidéos démos en anglais aussi.
DXO ne t'a pas encore contacté ?
Je viens de regarder tes vidéos. Félicitation. On sent la passion, c'est rare dans une démonstration technologique.