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.

Reverse avec apktool

Si, pour vous instruire sur Android, vous avez regardé le contenu d’un fichier apk (qui est en fait un fichier zip) vous avez constaté que les fichiers texte, comme les xml, sont illisibles. Heureusement il y a apktool !

Apktool est une application open source, écrite en java, qui permet de faire du reverse engineering sur des applications Android (apk).

Attention son téléchargent se fait en deux temps :

1. Le fichier java apktool.jar, le même quelle que soit la plateforme Win/Mac/Linux.
   Le nom de l’archive qui contient ce fichier est de la forme apktool<x.y.z>.tar.bz2
2. Un script et  un binaire (dépendant de la plateforme) pour lancer l’exécution du jar.
   Le nom de l’archive qui contient ce fichier est de la forme apktool-install-<plateforme>-r<xx>-brut1.tar.bz2

On copy l’ensemble de ces fichiers dans le même répertoire. L’idéal est d'avoir ce répertoire dans le PATH
Sous Windows on a donc : apktool.jar + apktool.bat + aapt.exe

USAGE 
Ouvrir une console (boite dos) et taper ( sans oublier le 'd' )

apktool  d  \path\to\application.apk

Un répertoire avec le nom de l’application a été créé dans le repertoire courant. Il contient les fichiers en clair. Il ne vous reste plus qu'a explorer !...
(Pour plus de détails sur les paramètres taper juste : apktool)

Où est le code java ?
Les fichiers java sont présentés sous forme de fichiers "smali". Il s'agit du code assembleur utilisé par la machine virtuelle Dalvik.

Application utile:
Il existe des sites web qui vous proposent de créer enligne votre application Android (et iPhone). Les applications ainsi générées nécessitent des droits très surprenant sans rapport avec les besoins réel de l'application. Que contient le fichier .apk à la fin ? Grâce à apktools vous allez découvrir tout ce qui est ajouté (en cachette) à votre application (pub, appel de numéro, liens vers d'autre sites, player étrange, ect) et tout ce qui en fait n'est pas dans votre application mais sur des serveurs.
Donc, grâce à apktool, j'ai appris qu'il ne fallait surtout pas utiliser ces services : trop gratuits pour être honnêtes  !!
Pour aller plus loin...