Sur les rails

La macro avec l'objectif MP-E 65 de Canon est à la fois un régal et un cauchemar!
Un régal car quand les résultats sont là ils sont incroyables.
Un cauchemar car pour obtenir ces résultats tout est compliqué (et cher).

Si on veut garder toute la définition du MP-E 65 if faut l'exploiter entre f/4 et f/8. Bien sûr dans la course à la profondeur de champs on prendra f/8. Mais voila ce que dit la table des profondeurs de champs (valeurs en mm)

	1x	3x	5x
f/4	0.56	0.124	0.067
f/8	1.12	0.249	0.134
f/11	1.58	0.352	0.19

(valeurs pour un cercle de confusion de 0.035mm)

Pour faire du focus stacking à 1x et f/8 il faut être capable de déplacer l’appareil de 1mm à chaque photo. C’est jouable. Mais à 5x et toujours à f/8 il faut le déplacer de 0.1mm. Là c’est beaucoup plus difficile.

Quels rails macro permettent de déplacer l’appareil de 1mm, de 1/4 de mm, de 1/10 mm ?

Notons que, indépendamment de la précision du rail, il faut être certain que le réglage du rail ne  dérègle rien d’autre. Par exemple, si tourner une molette pour avancer le plateau du rail de 1/10 de mm dérègle le trépied de 2/10 mm on aura tout faux ! Il faut non seulement un rail macro précis mais aussi un support très stable, aussi bien pour l’appareil que pour le sujet.

• Prenons le rail Castel-L de Novoflex (à 190 €).  A chaque tour de molette le chariot avance de 15mm.  Donc 1/8 de tour avance de 1.8mm c’est énorme. Suffisant pour faire la mise au point mais très insuffisant pour faire du stacking même à 1x et f/11
  
  
• Passons au rail B150-B de Really Right Stuff (à 350$). La doc nous dit qu’un tour de vis avance le chariot de 1.25mm. Il faut faire 1/10 de tour pour avancer de 0.125 mm, ce qui nous permettrait de faire du 5x à f/8. Malheureusement, pour ce prix, la molette n’est pas graduée. En faisant une marque sur la molette on peut juger le 1/4 de tout et même le 1/8 de tour mais pas le 1/10.
   
• Finissons avec le rail motorisé StackShot de cognisys (à 525$ + 45$ de câble). Moteur pas à pas avec une précision de 0.001mm (1µm) commande à distance, programmation de l’avance et du déclenchement. Certes c’est plus cher mais c’est le meilleur et à mon avis la seule solution pour faire du focus stacking avec le MP-E 65.

A vous de voir...

Systeme macro utilisant un MP-E 65 et un double rail motorisé.

Canon MP-E 65mm f/2.8 1-5x Macro

Voici quelques 'trucs' bons à savoir avant d'acheter l'objectif macro MP-E 65mm de Canon....

1. 

   photo: source wikipedia

   L’objectif Canon MP-E 65mm f/2.8 1-5x Macro est un objectif totalement dédié à la macro photographie. Son domaine commence là où les autres objectifs macro s’arrêtent, et contrairement à ces autres objectifs macro il ne peut pas servir à faire des photos classiques. L’objet à photographier doit se situer entre 10 cm et 4 cm de la lentille frontale de l’objectif.
   
   
2. Il est écrit que c’est un objectif à mise au point manuelle : C’est faux ! Il n’y a ni bague ni système de mise au point, ni automatique ni manuel. La mise au point se fait en déplaçant l’objet ou l’appareil. Une des conséquences est que la mise au point n’est pas pilotable à distance par le logiciel « EOS utilities » comme on peut le faire avec les autres objectifs même en mode mise au point manuelle. Ce qui complique les choses pour le « focus stacking ».
   
   
3. La profondeur de champ varie de 2.2 mm à 0.05mm suivant la combinaison entre le rapport d’agrandissement (1x à 5x) et l’ouverture (f/2.8 à f/16).  Autrement dit c’est un objectif inutilisable sans pied ET sans rail de mise au point. De plus, la télécommande (ou le retardateur ou le logiciel de pilotage à distance) s’impose même si on utilise un pied et que l’on déclenche miroir déjà levé.
   
   
4. L’ouverture affichée par l’appareil correspond à l’ouverture ‘géométrique’ du diaphragme. Du point de vue lumière le diaphragme semble d’autant plus fermé que le grandissement est important. La formule suivante donne la relation : 
   f-réel = f-affiché x (grandissement + 1)
   Exemple : Si l’appareil indique f/8 avec un grandissement de 3 cela correspond d’un point de vu lumière à f/32.  On peut atteindre ainsi f/96. 
   Ce phénomène a deux conséquences :
   * Un flash dédié macro est rapidement une obligation
   * Pendant la visée on est en théorie à  f/2.8 mais à 1x on est en fait à f/5.6 et à 5x on est à f/16.8. La visée n’est donc pas très lumineuse. Il est inutile d’utiliser le bouton de test de la profondeur de champs : on n’y voit plus rien !

 En résumé :

-         Pas de mise au point,

-         Très faible profondeur de champs

-         Très grande proximité avec le sujet

-         Pied + Rail + télécommande + miroir levé

-         Visée peu lumineuse

-         Flash macro presque obligatoire

C’est donc un objectif de studio ou même de labo.

Une fois que l’on sait cela, c’est un super objectif ! Pour en tirer le meilleur il faut rester entre f/4 et f/8.

Voici quelques exemples:

• Le groupe dédié au MP-E 65 sur Flickr
• Galerie du biologiste Alexander Wild
• Le blog No Cropping Zone de John Kimbler  (aka Dalantech)

Accessoires pour de Macro :
Ne pas oublier qu'un 5D MK2 + MP-E 65 + Flash MT-24EX approche les 3kg.

• StackShot : la macro pour les pros.
• Really Right Stuff
• Le Supper Mag Slider de Velbon
• Les rails de Novoflex
• Plateau micrométrique de Manfrotto

La doc de l'objectif.

Un mémo des propriétés de l'objectif.

optWare sur QNAP

J’utilise un QNAP TS259 comme serveur de fichiers dans mon réseau perso. La force et la faiblesse du système de QNAP c’est que beaucoup de choses sont restaurées dans leur état de base à chaque reboot à partir d'une mémoire flash. Ceci protège contre de fausses manips mais rend difficile toute configuration personnelle. Il existe des méthodes pour que ces modifs persistent d’un reboot à l’autre. Mais aucune n'est totalement efficace en cas de mise à jour du firmware.

optWare est un system de gestion de packages adapté aux systèmes Linux embarqués. Il peut être installé par l’intermédiaire d'un package standard (QPKG) de Qnap.Une fois le package optWare installé, on peut utiliser en ligne de commande ipkg pour accéder à plus d’un millier de logiciels compilés pour Intel ou ARM (suivant le type de QNAP) et qui fonctionnent entièrement dans /opt (binaire, config, librairies ect). Tout l’intérêt c’est que le contenu de /opt n’est modifié n’y au reboot n’y à l’occasion d’une mise à jour du firmware.

Le seul problème à résoudre est comment lancer à chaque boot du QNAP les daemons installés via ipkg de optWare (bind, openssh, ect) ? Heureusement QNAP propose un ‘hook’ nommé autorun.sh Dans sa procedure de boot le Qnap appelle ce script. A vous d'y faire ce qui vous arrange.

Voici la procédure pour le mettre en place de la manière la plus simple et la plus efficace possible.

1) A faire une seule fois

ATTENTION

1. suivant la configuration disque et le modèle de votre QNAP, ce qui chez moi s'appelle MD0_DATA peut, par exemple, s’appeler HDA_DATA chez vous. A vous de trouver l'équivalent et d’adapter ce qui suit. 
2. De même ce qui chez moi s’appelle /dev/sdx6 sur mon Qnap peut s’appeler /dev/mtdblock5 sur le votre.

Créer un répertoire

mkdir /share/MD0_DATA/.qpkg/autorun

Entrer dans ce répertoire

cd /share/MD0_DATA/.qpkg/autorun

Créer les 3 scripts shell : autorun.sh run.sh et restore_autorun.sh

Le script autorun.sh

#!/bin/sh 
RUN=/share/MD0_DATA/.qpkg/autorun/run.sh 
[ -x $RUN ] && $RUN

Le script run.sh

#!/bin/sh

RUNDIR="$( cd -P "$( dirname "$0" )" && pwd )"
echo "RUN: " `date` >> $RUNDIR/log.txt

#Start all optWare packages
for i in /opt/etc/init.d/S??* ;do              

     case "$i" in
        *.sh)
            # Source shell script for speed.
            (
                trap - INT QUIT TSTP
                set start 
                . $i
            )
            ;;
        *)
            # No sh extension, so fork subprocess.
            [ -f $i ] && $i start
            ;;
    esac
done

Le script restore_autorun.sh

#!/bin/sh
cd /
mount /dev/sdx6 /tmp/config
cp /share/MD0_DATA/.qpkg/autorun/autorun.sh  /tmp/config/autorun.sh
ls -l  /tmp/config
umount /tmp/config

Rendre les 3 scripts exécutables

chmod +x *.sh

2) A faire la première fois et après chaque changement de firmware

Exécuter cette commande depuis la ligne de commande du Qnap:

/share/MD0_DATA/.qpkg/autorun/restore_autorun.sh

Ceci va copier dans la mémoire flash (dans mon cas /dev/sdx6) le fichier autoruns.sh qui sera appeler à chaque boot.
Ce fichier a pour rôle d'appeler notre run.sh qui effectue le véritable travail.

Pourquoi ne pas tout mettre dans autorun.sh ?
- La place dans la mémoire flash est limité.
- L’accès à la mémoire flash n'est pas immédiat. Il faut d’abord la monter. Ce qui rend l’édition du fichier autoruns.sh pas pratique.

3) Adapter run.sh à vos besoins

Éditez directement le script "/share/HDA_DATA/.qpkg/autorun/run.sh" pour démarrer, initialiser ce qu’il vous plaira.
La version présenté ci-dessus démarre tous les daemons installés par optWare et qui ont un script de démarrage dans /opt/etc/init.d (Tous les packages de optWare ne mettent pas leut script de démarrage là : Lire la doc !)

HG + SSH

Dans le cas où on utilise Mercurial dans un mode client/serveur il faut choisir un protocole de communication entre les clients et le serveur. Cette page récapitule les options possibles.

Si on ne veut pas installer des applications supplémentaires (Rhodecode, hgweb, hg-ssh ect…) la seule solution efficace est ssh. Mais c’est aussi la solution la moins documentée !

Le principe de fonctionnement de hg + ssh est le suivant :
Le hg coté client va utiliser ssh pour exécuter les commandes hg coté serveur et communiquer avec.

Le problème c’est que des commande comme celle-ci on n’a pas envie de les taper ni de rentrer le mot de passe à chaque fois.

“C:\Program Files\TortoiseHg\TortoisePlink.exe” -ssh -2 -i “C:\Documents and Settings\All Users\Documents\ssh\hg\id_rsa.ppk" hg@mon.domaine.com “hg -R /home/hg/repo1 serve –stdio”

Pour automatiser il faut :

• Utiliser un client graphique. Il s’occupera de construire la commande et de l’exécuter.  Le meilleur des clients graphiques est TortoiseHg
• Utiliser ssh avec une paire de clefs publique/privée pour éviter de taper le mot de passe à chaque commande.

1) Installation de Mercurial

On partira du principe que le serveur est sous Unix et le client sous Windows.

* L’installation de TortoiseHg sur le poste Windows n’est pas un problème. Il inclut tout : Mercurial, l'interface graphique et même le client ssh : TortoisePlink.exe (mais on peut en utiliser un autre).
* L'installation de Mercurial sur le serveur Unix est basique. Il suffit d'installer le package correspondant à son Unix ou à sa distribution Linux. (Il faut avoir python 2.6+ deja installé).


2) La paire de clefs publique/privée

Il faut ensuite créer la paire de clefs, déposer la clef publique sur le serveur Unix et expliquer à TortoisePlink ou trouver la clef privée. Attention la clef privée doit être au format ppk. Ce format de clef est propre à PuTTY, et TortoisePlink est basé sur le Plink de PuTTY.

Pour générer cette paire de clefs il faut utiliser puttygen, qui ne fait pas partie de TortoiseHg mais de de PuTTY.  Voir cette page sur comment générer cette paire de clefs avec puttygen.

Important : Pour simplifier ne pas attribuer de passphrase à la clef privée.

Par la suite on supposera que les noms de fichiers pour la paire de clefs sont:
   Publique : hg_rsa.pub
   Privée : hg_rsa.ppk

Déposer la clef publique sur le serveur Unix dans le répertoire de l’utilisateur dédié à hg. En principe on crée un utilisateur nommé ‘hg’ et les repository sont stockés dans son home directory.  Donc on dépose la clef publique hg_rsa.pub dans le répertoire /home/hg/.ssh  du serveur.

Ensuite il faut ajouter cette clef publique à la fin du fichier /home/hg/.ssh/authorized_keys
   cat hg_rsa.pub >> authorized_keys
On peut ensuite supprimer le fichier hg_rsa.pub coté serveur
   rm hg_rsa.pub



3) Mercurial.ini
Il faut maintenant expliquer à Hg comment utiliser ces clefs.
Dans le fichier %USERPROFILE%\Mercurial.ini ajouter dans la section [ui] la ligne

ssh = "C:\Program Files\TortoiseHg\TortoisePlink.exe" -ssh -2 -i "C:\Documents and Settings\Path\To\hg_rsa.ppk"

4) Init + Clone
Coté serveur, en utilisant le user dédié à hg, créer un repository vide:

cd /home/hg
hg init PremierTest

Coté client créer le repertoire PremierTest
Click bouton droit sur ce répertoire puis dans le menu contextuel sélectionner TortoiseHg > Clone ..

Remplacer le contenu du champ « Source » par   
   ssh://hg@mon.serveur.com//home/hg/PremierTest
ou  
   ssh://hg@mon.serveur.com/PremierTest
(en supposant que votre utilisateur soit hg)

ATTENTION : 
  Ne pas oublier le nom du user coté Unix (ici hg)
  Respecter la case du path coté Unix.  
  C'est bien un double / ou un simple / entre le nom du serveur et le path

Quand le path commence par un double / cela signifie qu'il est absolu.
Quand il commence par un simple / cela signifie qu'il est relatif au home directory du user (ici 'hg')

Un path relatif est moins dépendant des variations de l'organisation sur le disque du serveur et est donc préférable car plus stable.

Puis cliquer sur le bouton "Clone".

A partir de là il ne sera plus nécessaire de faire référence à ssh ou au nom du serveur. TortoiseHg a tout enregistré et générera les commandes ssh adéquates.

5) Apprendre !

Voici un très bon tutoriel (plein d'humour) sur Mercurial. Il ne présente que l'utilisation de la ligne de commande (hg). Mais la conversion en clicks sur l'interface graphique de TortoiseHg est facile.