keymlinux

Je suis d'accord, mais a un détail près, c'est valable pour le capteur de l'ASi2600 qui est exempt d'ampglow, mais si il y a ampglow, le dark sert à le soustraire des brutes, et si le gain utilisé pour les brutes et les dark est différent il via y avoir sur ou sous correction de cet ampglow Je suis tout a fait d'accord l'emploi du terme Bias permet d'éviter de confondre avec l'offset de la camera. Mais si j'étais tatillon je dirais qu'en employant le terme DOF il y a une légère contradiction, car le O de DOF c'est pour Offset, on devais utiliser l'acronyme DBF (ok, je sors... 🙂 ) La cible est NGC7788, petit amas ouvert (la cible est écrite dans le fit de la brute). et oui moi aussi je trouve qu'il y a très peu de signal sur ces brutes de 300s A @transitmk1 de confirmer si il y a eu usage de filtre restrictif ou pas (mais pour une cible comme un amas ouvert, a part un filtre anti-pollution léger, je ne vois pas l'interêt d'un filtre restrictif style S, H O ou dualband) Effectivement on ne peut pas lutter avec les conditions caniculaires, la température cible était bien -10° (apparaît dans les en têtes FITS), ensuite la camera fais ce quelle peut.... Ceci étant je pense que dans ce cas là il vaut mieux viser une température de capteur plus haute, style 0° ou 5° pour éviter que la régulation thermique soit à la ramasse et cela permettra de garantir que toutes les brutes et tous les dards sont à la même température Là par contre, désolé de te contredire, mais les dark et brutes n'ont pas été faits au même gain, c'est écrit dans les en têtes FITS des images que tu as fourni. @transitmk1 Peux tu nous confirmer si lors du pré-traitement tu as juste soustrait le masterdark (dans ce cas on ne comprend pas pourquoi autant de pixels négatifs) ou bien si tu as aussi soustrait le masterbias (là par contre la soustraction des 2 expliquerais bien le pourquoi tu obtiens autant de pixels négatifs)

Salut Robert, J'utilise aussi un Pi5 avec Nvme, que j'ai installé dans un boitier Geekworm P579 Pour le fixer sur la lunette, j'ai fait un support en impression 3D Cela serait bien incroyable qu'il n'y ait personne dans ton club astro qui ne dispose d'une imprimante 3D pour te faire un support aux dimensions de ton boitier... Le PI5 a bien un RTC intégré, mais il faut lui brancher une petite batterie sur le connecteur qui va bien (pour info 6€ la batterie sur Kubii). Pour le moment je n'ai pas encore franchi le pas, je le met à l'heure avec un dongle GPS, ou manuellement si besoin Mon boitier: Le support 3D, avec une embase "mini-vixen" à fixer sur le support du chercheur de la lulu Cordialement, Stéphane

Si les brutes et darks ne sont pas au meme gain cela ne vas pas aider… Une caméra ASI2600 cela s’utilise a gain 100 ( a gain 0 dans certains cas particuliers), je ne vois pas de raison d’utiliser les valeurs 203 ou 174… lecture:

Souvent on obtiens des pixels négatifs car on soustrait les offsets et les darks (qui eux mėme contiennent l’offset) donc on soustrait l’offset 2 fois. @transitmk1lorsque tu pré traites dans Siril, fais tu un pré-traitement: (brutes-dark)/(flat-offset) ou bien (brutes-dark-offset)/(flat-offset) Si le dark contient l’offset alors il faut faire la 1ere opération et pas la deuxième

Bonjour, 1) peux tu me préciser la version de MacOS que tu utilises et si ton mac est à processeur Intel ou ARM ? note: j'utilise le plugin avec Gimp 3.0.4 sous macOS Séquoia 15.6, macbook à processeur Intel 2) peux tu vérifier que tu as bien déclaré le répertoire où tu as dézippé le plugin dans gimp. Menu "GIMP/Settings...", puis une fois dans la fenêtre "Préférences", vérifier "dossiers/greffons" Par exemple, moi de déclare "/Users/stephane/pygap-m27-gimp3/pythonfu-gimp3", à adapter selon ton cas. 3) vérifie que les fichiers du plugin n'ont pas d'attribut de quarantaine (mis par défaut sur les fichiers téléchargés depuis internet...) par exemple chez moi (à adapter avec le nom du répertoire où tu as stocké les fichiers): ls -l@ -R /Users/stephane/pygap-m27-gimp3 Si il y a un ou plusieurs fichiers qui ont l'attribut "com.apple.quarantine" alors cela peut expliquer le problème Dans ce cas il faudra supprimer cet attribut avec la commande suivante (ici aussi adapter le nom du répertoire): xattr -d -r com.apple.quarantine /Users/stephane/pygap-m27-gimp3 4) Peut tu lancer GIMP via la ligne de commande: /Applications/GIMP.app/Contents/MacOS/gimp et copier ici dans le fil de discussion les messages obtenus au lancement Pour exemple, voici ce que j'obtiens chez moi MLS-MBP:~ stephane$ /Applications/GIMP.app/Contents/MacOS/gimp GIMP is started as MacOS application GIMP was built with MacPorts (gimp:60098): Gtk-CRITICAL **: 17:12:44.797: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed /Applications/GIMP.app/Contents/MacOS/gimp: Gimp-Widgets-CRITIQUE: gimp_dialog_factory_add_foreign: assertion 'GDK_IS_MONITOR (monitor)' failed (gimp:60098): Gtk-CRITICAL **: 17:12:45.014: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed EDIT: la présence de ces messages "Gtk-CRITICAL" n'empêchent pas le bon fonctionnement Cordialement, Stéphane

Salut Robert, Le nouveau script qui remplace le précédent est "OSC_Extract_HaOIII.ssf", normalement il est inclu avec l'installation Siril (sur mon macbook il est livré avec les binaires Siril, il ne fait pas partie des scripts téléchargeables via "Réglages/scripts" et il n'est pas dans le repository: https://gitlab.com/free-astro/siril-scripts/ OSC_Extract_HaOIII.ssf note; - si en plus d'une extraction Ha+Oiii tu as aussi à faire une extraction Sii+Oiii tu peux utiliser le même script sur tes brutes faites avec le filtre Sii+Oiii, puis ensuite tu devras renommer le fichier résultat "ha" en "sii" edit: pour info, Kstars 3.7.8 viens de sortir (13/08) , je vais tester ce soir... Cordialement, Stéphane

Bonsoir, Concernant les bias, dark et light fournis, je ne vois rien de problématique (rien qui pourrait expliquer le gros "donut" sombre sur l'image finale), les paramètres de prise de vue (iso, ouverture) sont homogènes Sur les light, l'analyse de la courbe de luminosité sur la diagonale ne fait apparaitre qu'un vignétage normal, pas de gros "donut" (donc a priori pas de buée) Par contre l'analyse de la PSF (forme des étoiles) fait apparaitre du tilt. C'est bizarre car avec un APN canon et un objectif canon l'ajustement entre les deux devrait être nickel avec très peu de jeux mécaniques donc peu de tilt. Mais si ton objectif est un 70-200 à monture EF, que tu as monté sur la monture RF de ton APN, alors il y a une bague intermédiaire EF vers RF, donc des jeux mécaniques entre chaque élément qui au final sont cumulés. A noter que si l'objectif est léger, on fixe l'APN sur la monture et on laisse l'objo en "porte a faux", mais si par contre l'objoo est plus lourd que le boitier de l'APN (et il me semble que c'est le cas avec cet objectif), alors il est préférable d'utiliser un collier à pied pour l'objectif, afin que ce soit l'objectif qui soit fixé sur la monture et que ce soit le boitier qui soit en "porte a faux" Ceci étant le tilt c'est pour les puristes qui veulent des étoiles rondes et fines, mais à ma connaissance cela ne cause pas le problème de "donut" sombre que tu rencontre. Pour les master dark et bias, rien de particulier non plus. Le master bias étant très homogène avec une valeur de 2048, tu peux au lieu de faire des bias utiliser un bias synthétique dans Siril en mettant la valeur à 2048 (c'est ce que je faisais quand j'utilisais un Canon 80D, cela marche très bien) Bias synthétique, voir ici https://siril.org/fr/tutorials/synthetic-biases/ Au final, je ne vois rien dans les images fournies qui explique le résultat obtenu avec le gros "donut" sombre Ce que tu peux tenter c'est de refaire elle traitement sans les flats. si ce sont eux qui sont la cause du problème, alors les supprimer devais faire disparaître le gros donut sombre, et au pire tu aura un peu de vignétage dans les coins Petit aparté, histoire que tu te sentes moins seul, moi aussi il m'arrive d'obtenir des résultats surprenants. ci dessous M27 imagée le 11/07 avec un C8 et un filtre ha+oiii, stack de 200x60sec, traitement avec les flats, capture d'écran de l'affichage de siril en mode auto-ajustement la même traitée sans les flats (post édité pour mettre l'image avec la même orientation...) Cordialement

Bonjour, Quand j'ouvre ton flat avec les outils Canon (DPP), il me donne un histogramme qui est plutôt au milieu (note, DPP donne un histogramme sur des valeurs normalisées en 8bits, donc entre 0 et 255) Par contre quand je l'ouvre avec Siril et que je demande les statistiques de l'image j'obtiens cela Normalement ton Canon donne des images RAW en 14bitsn donc avec des valeurs entre 0 et 16385 Donc avec des valeurs moyennes à 5000 dans le vert on est pas au milieu de l'histogramme, on est plutôt a un tiers Sachant qu'en plus à 800 iso l'offset (la valeur minimum lue est probablement à 2048, à confirmer en regardant les statistiques d'un dark ou d'un bias a même iso)), je dirais qu'il me semble que ton flat est trop sombre notes 1) utiliser un iPad n'est pas rédhibitoire pour les flats (j'utilise aussi un ancien iPad 3 pour les flat fait avec une petite lunette 2) je vois dans ton raw que tu as activé la reduction de bruit a iso élevée (mode "faible") --> tu peux désactiver, et remplacer cela par des darks que siril traiteras EDIT Avec Siril, si on regarde la courbe d'intensité lumineuse sur une ligne en diagonale de ton image l'image, avec la ligne analysée La courbe d'intensité lumineuse donne cela, on y voit bien les 2 pic vers le bas lors de la traversée de l'anneau sous illuminé Par contre sur ton flat on ne vois pas la même chose (il montre un vignettage normal) EDIT 2 Jusqu'ici on est parti du principe que ce sont les flats qui n'ont pas joué leur rôle et qui ont altéré l'image (sur correction, cela arrive parfois) Mais il y a une autre possibilité pour ce type de halo central, c'est la présence de buée (rosée) qui se dépose sur la lentille frontale de l'objectif en cours de prise de vue mais si c'était le cas je pense que tu l'aurais vu Cordialement, Stéphane

Sur le montage video de @RamRam54 on voit les trainées de quelques satellites, qui a leur altitude de quelques centaines de km sont éclairés par le soleil alors que nous au sol sommes dans la nuit. Si l'objet bizarre et bien le satellite Cosmos 2564 (ce qui reste a démontrer), vu que ce satellite est sur une orbite à plusieurs milliers de km il se peut qu'il se soit trouvé illuminé par la pleine lune même si pour nous au sol elle n'était pas encore levée. D'ailleurs il se peut bien qu'il ait été a la fois éclairé par le soleil qui venait de se coucher à l'ouest et par la lune qui allait se lever à l'est Reste a savoir si ces reflets et un peu de buée donneraient le halo observé... EDIT: par contre pour des reflets de la lune directement sur la lentille d'un telescope ou objectif photo, oui là il faut que la lune soit levée pour l'observateur au sol

Plus serieusement si l'objet est "bas" comme un drone (pas bas j'entend ici dans l'atmosphère), alors vu sa vitesse de déplacement angulaire il ne doit pas avoir une grande vitesse de déplacement dans l'air, donc comment se sustente t'il si l'objet est loin (comme un satellite à 19000 km avec une période orbitale de 11h 16min), même si sa vitesse orbitale est grande son déplacement d'angulaire paraitra faible

J'ai trouvé..il y a comme une ressemblance dans la forme...

Bonjour, Le 13/06 entre 23h30 et minuit il y a le satellite "Cosmos 2564 (761)" qui est passé entre arcturus et 20 Boo La trajectoire semble la même que l'objet sur ta séquence, par contre cela n'explique pas le halo Capture stellarium Avec une capture video (fichier MP4 a lire avec VLC) Cosmos 2564.mp4 EDIT: format de video correct a la 3eme tentative (je suis un boulet...) Cordialement

Non Les bagues T2 c'est du 42mm de diamètre avec un pas de vis de 0.75mm, c'est beaucoup utilisé en astro Les bagues M42 c'est du diamètre 42mm et pas de vis de 1mm, utilisé pour les anciens objectifs photo Une bague M42-EOS te permettra de fixer un ancien objectif photo ayant un diamètre 42mm (x1mm) sur un APN CANON Une bague T2-EOS te permettra de fixer un accessoire astro (tube allonge, réducteur/correcteur) ayant un diamètre de 42mm (x0.75mm) vers un APN Canon Cordialement

Ubuntu 24.04.2 LTS sur un raspberry PI 5 note: L'impossibilité actuelle de cumuler kstars et siril sur le même host n'est pas un problème bloquant pour moi, car je fais tourner kstars sur le raspberry pour piloter la prise de vue, mais j'utilise Siril principalement sur MacOs pour le traitement. Habituellement j'utilise Siril sur le raspberry pi pour voir les stats des lights au début de la séance de prise de vue pour ajuster le temps de pose (règle des 3 sigma) Par contre pour quelqu'un qui voudrait utiliser un PC sous linux pour faire la prise de vue avec kstars ET le traitement avec siril, cela serait bloquant Package Kstars installé: (a priori compilé ce jour 10 juin...) root@mls-nfb:~# apt search kstars-bleeding En train de trier... Fait Recherche en texte intégral... Fait kstars-bleeding/noble,now 6:3.7.7+202506101226~ubuntu24.04.1 arm64 [installé] desktop planetarium for KDE kstars-bleeding-data/noble,noble,now 6:3.7.7+202506101226~ubuntu24.04.1 all [installé, automatique] data files for KStars desktop planetarium kstars-bleeding-dbg/noble,now 6:3.7.7+202506101226~ubuntu24.04.1 arm64 [installé, automatique] debug information for the desktop planetarium for KDE Les dépendances kstars (on y trouve la libxisf) root@mls-nfb:~# apt show kstars-bleeding Package: kstars-bleeding Version: 6:3.7.7+202506101226~ubuntu24.04.1 Priority: optional Section: science Maintainer: Jasem Mutlaq <mutlaqja@ikarustech.com> Installed-Size: 31.4 MB Depends: kio, libc6 (>= 2.38), libcfitsio10t64 (>= 4.2.0~), libgcc-s1 (>= 4.0), libgsl27 (>= 2.7.1), libindi1, libkf5configcore5 (>= 4.98.0), libkf5configgui5 (>= 4.97.0), libkf5configwidgets5 (>= 5.23.0), libkf5coreaddons5 (>= 4.100.0), libkf5crash5 (>= 5.15.0), libkf5i18n5 (>= 5.69.0), libkf5kiocore5 (>= 4.96.0), libkf5kiowidgets5 (>= 4.96.0), libkf5newstuff5 (>= 4.95.0), libkf5notifications5 (>= 4.96.0), libkf5notifyconfig5 (>= 4.96.0), libkf5plotting5 (>= 4.96.0), libkf5widgetsaddons5 (>= 5.100.0), libkf5xmlgui5 (>= 4.98.0), libopencv-core406t64 (>= 4.6.0+dfsg), libopencv-highgui406t64 (>= 4.6.0+dfsg), libopencv-imgproc406t64 (>= 4.6.0+dfsg), libqt5concurrent5t64 (>= 5.6.0~rc), libqt5core5t64 (>= 5.15.1), libqt5datavisualization5 (>= 5.10.1), libqt5dbus5t64 (>= 5.14.1), libqt5gui5t64 (>= 5.14.1) | libqt5gui5-gles (>= 5.14.1), libqt5keychain1 (>= 0.7.0), libqt5network5t64 (>= 5.15.1), libqt5printsupport5t64 (>= 5.0.2), libqt5qml5 (>= 5.0.2), libqt5quick5 (>= 5.0.2) | libqt5quick5-gles (>= 5.0.2), libqt5sql5t64 (>= 5.3.0), libqt5svg5 (>= 5.6.0~beta), libqt5websockets5 (>= 5.6.0), libqt5widgets5t64 (>= 5.15.1), libraw23t64 (>= 0.21.1), libstdc++6 (>= 12), libstellarsolver, libwcs8 (>= 8.1), libxisf, zlib1g (>= 1:1.1.4), kstars-bleeding-data (>= 6:3.7.7+202506101226~ubuntu24.04.1), kstars-bleeding-dbg (= 6:3.7.7+202506101226~ubuntu24.04.1), kded5, kinit, indi-bin, breeze-icon-theme, libqt5sql5-sqlite, qml-module-qtquick-controls Recommends: xplanet, xplanet-images Conflicts: kstars Replaces: kstars Download-Size: 7470 kB APT-Manual-Installed: yes APT-Sources: https://ppa.launchpadcontent.net/mutlaqja/ppa/ubuntu noble/main arm64 Packages Le package Siril dispo a l'installation: root@mls-nfb:~# apt search siril En train de trier... Fait Recherche en texte intégral... Fait python3-sirilic/now 1.15.8-1 all [installé, local] SiriLic is a graphical frontend for SiriL scripting. siril/noble 1.4.0-beta2-0ubuntu0~nobleppa1 arm64 outil de traitement d'images astronomiques siril-common/noble,noble 1.4.0-beta2-0ubuntu0~nobleppa1 all architecture-independent files for siril Lorsque j'essaie de l'installer: root@mls-nfb:~# apt install siril Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Lecture des informations d'état... Fait Certains paquets ne peuvent être installés. Ceci peut signifier que vous avez demandé l'impossible, ou bien, si vous utilisez la distribution unstable, que certains paquets n'ont pas encore été créés ou ne sont pas sortis d'Incoming. L'information suivante devrait vous aider à résoudre la situation : Les paquets suivants contiennent des dépendances non satisfaites : libxisf : Est en conflit avec: libxisf0 mais 0.2.8-1 devra être installé E: Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu être causé par les paquets devant être gardés en l'état. et pour cause, Siril nécessite la libxisf0 qui est en conflit avec la libxisf déjà présente root@mls-nfb:~# apt show siril Package: siril Version: 1.4.0-beta2-0ubuntu0~nobleppa1 Priority: optional Section: science Maintainer: Debian Astronomy Maintainers <debian-astro-maintainers@lists.alioth.debian.org> Installed-Size: 9796 kB Depends: libavcodec60 (>= 7:6.0), libavformat60 (>= 7:6.0), libavutil58 (>= 7:6.0), libc6 (>= 2.38), libcairo2 (>= 1.15.10), libcfitsio10t64 (>= 4.2.0~), libcurl3t64-gnutls (>= 7.16.2), libexiv2-27 (>= 0.25), libffms2-5 (>= 2.21), libfftw3-single3 (>= 3.3.10), libgcc-s1 (>= 4.0), libgdk-pixbuf-2.0-0 (>= 2.25.2), libgit2-1.7 (>= 1.7.0), libglib2.0-0t64 (>= 2.75.3), libgomp1 (>= 9), libgsl27 (>= 2.7.1), libgtk-3-0t64 (>= 3.23.1), libgtksourceview-4-0 (>= 3.99.7), libheif1 (>= 1.13.0), libjpeg8 (>= 8c), libjxl0.7 (>= 0.7.0), liblcms2-2 (>= 2.14), libopencv-calib3d406t64 (>= 4.6.0+dfsg), libopencv-core406t64 (>= 4.6.0+dfsg), libopencv-imgproc406t64 (>= 4.6.0+dfsg), libopencv-stitching406t64 (>= 4.6.0+dfsg), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpng16-16t64 (>= 1.6.2), libraw23t64 (>= 0.16.0), libstdc++6 (>= 13.1), libswresample4 (>= 7:6.0), libswscale7 (>= 7:6.0), libtiff6 (>= 4.0.3), libwcs8 (>= 8.1), libxisf0 (>= 0.2.8), siril-common (= 1.4.0-beta2-0ubuntu0~nobleppa1), librsvg2-2, gvfs-backends, python3-venv, python3-pip, python3-tk Download-Size: 2584 kB APT-Sources: https://ppa.launchpadcontent.net/lock042/siril/ubuntu noble/main arm64 Packages Cordialement

Merci pour la démarche. Je pense qu'il va falloir quelques jours/semaine pour prise en compte (probablement la prochaine version de kstars) La version actuelle de Kstars 3.7.7 (qui date de la semaine dernière) utilise toujours la librairie "libxisf" spécifique au repository de Jasem Je viens de faire la mise a jour et cela bloque toujours pour l'installation de Siril (qui nécessite la librairie libxisf0 du repository officiel Ubuntu) Je vais guetter la prochaine mise a jour de kstars et je vous tiens au courant Cordialement, Stéphane

- si tu connecte un objo manuel sans contact, pour le boitier la focale sera 0 et l'ouverture sera 0 - si il y a un chip af-confirm, on peut y programmer certaines infos comme la focale et l'ouverture max (pas l'ouverture choisie lors de la prise de vue par le boitier), c'est décrit dans la doc - pour que l' exif contienne la valeur d'ouverture choisie pour la photo, tu choisis l'ouverture qui va bien pour ton expo avec la bague de l'objectif, et tu règles la même valeur sur ton boitier avant de déclencher, comme cela il enregistrera la bonne valeur (oui c'est contraignant, et peu utilisable si tu es contraint par le temps lors de la prise de vue)

Certains adaptateurs M42-EOS sont équipés d'un chip "AF confirm" Cela permet d'avoir la confirmation de mis au point (ok on s'en fout en usage astro 🙂, mais pas en usage diurne) , d'avoir certaines infos spécifiques a l'objectif dans les EXIFs (focale, ouverture max, c'est pratique si on a plusieurs objo m42), et on peut aussi enregistrer les micro-ajustement pour la mise au point J'en utilise avec divers objos m42 sur mon 80D (et avant sur un 650D), je trouve cela pratique à l'usage (attention, compatibilité aléatoire en fonction des boitiers Canon) EMF AF Confirm Chip For M42 Lens To Canon.pdf Cordialement, Stéphane

J'ai testé l'ouverture du fit avec ASIfitsviewer et Siril Avec ASIfitsviewer, aucun problème, les stats sont min=100, max=524, moy=314 et histogramme bien à gauche Avec siril (1.2 et 1.4 beta), on a des moyennes à 32000 et quelques... Donc même si AstroArt écrit ses fits de manière "atypique" (ne maitrisant pas la norme "fits" je n'ose pas écrire "incorrecte"), il semble que ASIfitsviewer semble s'en accommoder, ce qui n'est pas le cas de Siril. Je suis bien incapable de trancher sur qui a tord ou raison dans l'implémentation, le problème est-il coté AstroArt ou bien Siril, ou bien éventuellement du coté d'une librairie tierce comme libcfitsio Cordialement

Pour Siril, il me semble ( pas sur, à confirmer), que Siril n’implémente pas directement dans son code la lecture/écriture des fits, il fait appel a une librairie « libcfitsio » qui se charge des i/o (input/output) pour les fichiers fits, et c’est donc les développeurs de cette librairie qui ont la charge d’implémenter la norme fits @lock042 aurait tu un avis sur le problème rencontré ? Cordialement, Stephane

Bonjour, Il semblerait que ce problème soit connu (déjà discuté sur el forum astroart) https://www.astroart-forum.net/forum/viewtopic.php?f=2&t=222&p=749&hilit=bzero#p749 Lors de l’enregistrement du fichier fît, si il y a au moins une valeur de pixel supérieure a 32768 (ce qui est le cas sur tes dark sur les pixels chauds) alors les valeurs sont écrites en entiers signés entre -32k et +32k avec un bzero a 32768. Si par contre la valeur max des pixels est inférieure a 32k ( cas de tes bias) alors le fît est écrit avec des valeurs entre 0 et 32k et le bzero=0

Bonjour, Beau résultat, même si je trouve ton fond de ciel un peu trop noir (le risque en tirant sur les curseurs pour avoir le ciel noir c'est de perdre dans les détails faiblement lumineux) Peux tu préciser combien de poses tu as empilées et le temps de pose unitaire ? Cordialement, Stéphane

Ah, toi aussi J’y fixe une ed80 avec queue d’aronde vixen et un newton 10’´ en losmandy, dans les deux cas les vis sont un poil trop courtes. Par contre a part les vis, pas noté d’autre problème sur la tête de l’az-eq6

Bonjour, Il me semble le que la FRA500 est équipée en standard d'une queue d'aronde type Losmandy (7.6cm de large) de 30cm de long La largeur de 7.6mm permet d'avoir 2 point d'attache par anneau. S tu la remplace par une queue d'aronde vixen (mais pourquoi donc ?) celle ci ne fera que 4.3cm de large a avec une fixation unique centrale. Je ne connais pas de queue d'aronde vixen ayant 2 points d'attache dans la largeur Cordialement, Stéphane

C’est sous la pression (du public) que l’on se dépasse ! 😓