Le X20

Gus · Août 16, 2013, 18:51:51

Mais ce n'est peut-être pas un dysfonctionnement, mais un problème de configuration...
J'avais perdu les infos dans mon viseur, et cela provenait d'une combinaisons de deux paramètres dans ma configuration. C'est "matopho" qui a trouvé d'où provenait le problème, car le mode d'emploi livré avec l'appareil est vraiment insuffisant sur certains point...

matopho · Août 16, 2013, 22:50:34

Bonsoir

Lors de la réception de mon Xpro1 (en échange de tout mon matériel Canon) mon vendeur m'a dit d'utiliser la fonction (sur le X20, pas sur XPro1, les batteries sont seulement en cours de chargement) PARAMETRE1/INITIALISER/REINITIALISATION MENU PDV (et pas REINIT REGLAGE) en cas de comportement bizarre de mon appareil. En fait ca réinitialise le paramétrage aux valeurs par défaut, sauf les valeurs date/heure/langue/économie d'énergie. Cette fonction existe aussi sur les autres modèles X de Fuji

Explication: le micro-programme ne gère pas correctement certains enchainements de manipulations interdits, non prévus, ... Cela entraine le positionnement de certaines valeurs internes qui provoquent un comportement erratique.

En particulier j'avais déjà remarqué qu'il faut sortir d'un paramétrage (terminer) correctement. Autre ex. ne pas tourner la molette des modes de prise de vue pendant le choix du mode AF (page 94). Ou encore : utiliser le levier de sélection du mode de mise au point pendant un paramétrage. En fait utiliser un bouton, molette, une touche ... quand ce n'est pas prévu dans le paramétrage en cours. Les affirmations de ce paragraphe sont à confirmer et à valider..

Mais pour faire les manipulations correctement, il faut qu'elles soient décrites complètement. Et là on rejoint les posts précédents de la discussion ....

Salutations nocturnes.

yan-kee · Août 16, 2013, 23:38:07

ça fonctionne merci matopho

yan-kee · Août 17, 2013, 00:09:27

Si je mets la détection du sujet sur oui je perds mon bouton AE

Gus · Août 17, 2013, 09:38:52

CitationExplication: le micro-programme ne gère pas correctement certains enchainements de manipulations interdits, non prévus, ... Cela entraine le positionnement de certaines valeurs internes qui provoquent un comportement erratique.

C'est ce que l'on appelle un bug, non?

matopho · Août 17, 2013, 13:51:40

Bonjour,

Non, pas un bug, mais une absence de fonctionnalité : la récupération des erreurs provoquées par les manipulations non prévues. Cela s'analyse lors de la conception et est difficille à mettre en oeuvre si le langage de programmation ne le permet pas. Un avantage du langage Ada, langage temps réel. Le micro-programme ne doit certainement pas utiliser ce langage.
PS : désolé pour ce charabiat d'informaticien.

Gus · Août 17, 2013, 16:39:46

Le vrai "temps réel" n'existe pas !
Le traitement d'une information prend toujours un minimum de temps (conversion, mesure, traitement de l'informatiion, action...)
C'est un problème bien connu des automaticiens sur tout les phénomènes rapides (machine outil, réacteurs chimiques ou nucléaires, ...)

Mais quand deux actions de paramétrage et ou de configuration conduisent à un dysfonctionnement, on parle alors de bug, car si les programmes étaient bien fait cela ne devrait pas se produire .
Parfois sur certains automates, il y a des configurations interdites. Dans ce cas un message d'information s'affiche en clair à l'écran.

Dans le cas d'un appareil photo ce n'est pas très grave, mais dans d'autres domaines les conséquences peuvent être dramatiques...

Bon, je suis encore en vacances pour quelques heures, alors les bugs attendront !

matopho · Août 17, 2013, 19:11:48

Bonjour,

L'objet de ma réponse n'était pas de dire qu'un appareil photo doit être considéré comme temps réel. Mais qu'il existe une façon de réaliser un programme ou une partie de programme où l'on dit : si quelque chose se passe qui n'est pas prévu dans le code précédent alors fait cela. C'est une des facilités de Ada. Apparemment cela n'existe pas dans le microprogramme des modèles X de Fuji, donc comportement erratique. Ce n'est pas dommageable, il suffit de le savoir et savoir quoi faire.

Un bug est une erreur dans la réalisation d'une fonction. L'absence de fonction ne peut pas être un bug puisque la fonction n'existe pas. Quelque chose, même immatériel comme un code informatique, qui n'existe pas ne peut être faux. Sauf à qualifier de bug tout comportement qui ne satisfait pas l'utilisateur. Mais cela suppose que l'utilisateur connaisse tout le fonctionnement du programme pour ne pas faire d'erreurs de manipulation.

"programme bien fait" : cela n'existe pas car il est impossible de prouver par un autre programme qu'un programme fait ce qu'on attend de lui. Un programme est toujours l'œuvre d'un humain, donc faillible.

"un message d'information s'affiche à l'écran" : encore faut-il que cela soit prévu, un programme ne faisant que ce que le concepteur a prévu.

Je ne suis plus un travailleur, mais parfois certaines choses resurgissent.

Salutations

Gus · Août 17, 2013, 20:19:55

Citation de: matopho le Août 17, 2013, 19:11:48
..."un message d'information s'affiche à l'écran" : encore faut-il que cela soit prévu, un programme ne faisant que ce que le concepteur a prévu...

Il est souvent là le problème !

matopho · Août 18, 2013, 00:11:25

Personne n'empêche quiconque de concevoir son propre appareil photo et de le faire construire. Il répondra aux souhaits du concepteur mais également à ceux de l'utilisateur ....

Salutations

Goelo · Août 18, 2013, 10:34:13

Citation de: matopho le Août 18, 2013, 00:11:25
Personne n'empêche quiconque de concevoir son propre appareil photo et de le faire construire. Il répondra aux souhaits du concepteur mais également à ceux de l'utilisateur ....

Salutations

Enfin... si tout va bien...

Greenforce · Août 18, 2013, 11:29:28

Je propose d'ailleurs de créer une rubrique avec les boitiers "faits maison".... intéressant!

voxpopuli · Août 18, 2013, 15:06:45

Citation de: matopho le Août 17, 2013, 19:11:48
Bonjour,

L'objet de ma réponse n'était pas de dire qu'un appareil photo doit être considéré comme temps réel. Mais qu'il existe une façon de réaliser un programme ou une partie de programme où l'on dit : si quelque chose se passe qui n'est pas prévu dans le code précédent alors fait cela. C'est une des facilités de Ada. Apparemment cela n'existe pas dans le microprogramme des modèles X de Fuji, donc comportement erratique. Ce n'est pas dommageable, il suffit de le savoir et savoir quoi faire.

Un bug est une erreur dans la réalisation d'une fonction. L'absence de fonction ne peut pas être un bug puisque la fonction n'existe pas. Quelque chose, même immatériel comme un code informatique, qui n'existe pas ne peut être faux. Sauf à qualifier de bug tout comportement qui ne satisfait pas l'utilisateur. Mais cela suppose que l'utilisateur connaisse tout le fonctionnement du programme pour ne pas faire d'erreurs de manipulation.

"programme bien fait" : cela n'existe pas car il est impossible de prouver par un autre programme qu'un programme fait ce qu'on attend de lui. Un programme est toujours l'œuvre d'un humain, donc faillible.

"un message d'information s'affiche à l'écran" : encore faut-il que cela soit prévu, un programme ne faisant que ce que le concepteur a prévu.

Je ne suis plus un travailleur, mais parfois certaines choses resurgissent.

Salutations

La fonction "gestion des cas non prévus" est le B.A-BA pour éviter les effets de bords ... qui produisent des bugs. N'importe que langage permet de le mettre en oeuvre.

matopho · Août 18, 2013, 16:16:40

Ce que j'ai voulu faire comprendre c'est qu'il faut le prévoir. Si ça ne l'est pas, ça ne le fait pas, et ce n'est pas un bug. Et selon le langage c'est plus ou moins facile. Et avec le langage cité cela se fait avec qq instructions à la fin d'une fonction ou d'un ensemble de fonctions.

Le mieux c'est de faire des essais de toutes les fonctions, documentées ou pas, de leur combinaisons, en notant ce que ca fait, en faisant des schémas pour avoir une vue d'ensemble que ne fournit pas la doc. Si j'arrive au bout et que je le fais avec un outil de dessin je le publierai sur ce forum.
Salutations

al1sth · Août 18, 2013, 18:14:30

Bonjour,
J'ai un X20 depuis peu et j'ai remarqué qu'en mode priorité au diaph "A", il ne dépasse pas le 1000éme de seconde. A pleine ouverture au soleil c'est la surex.
J'ai manqué quelque chose dans les réglages ou il n'y a rien à faire ?

titroy · Août 18, 2013, 18:50:48

La vitesse maxi est conditionnée par l'ouverture : cette contrainte est liée à l'obturateur electronique. Il faut surveiller le paramètre vitesse (passe en rouge) et adapter l'ouverture en conséquence.
En mode A, la vitesse n'est pas limitée au 1/1000 de façon générale ! Try it.

Gus · Août 18, 2013, 19:10:44

Citation de: matopho le Août 18, 2013, 00:11:25
Personne n'empêche quiconque de concevoir son propre appareil photo et de le faire construire. Il répondra aux souhaits du concepteur mais également à ceux de l'utilisateur ....

Salutations

Hou là là !!!

al1sth · Août 18, 2013, 20:58:22

L
Merci Titroy, mais ce que je craignais, je peux être contrains de ne pas ouvrir au maxi.

Mistral75 · Août 18, 2013, 22:48:49

Citation de: titroy le Août 18, 2013, 18:50:48
La vitesse maxi est conditionnée par l'ouverture : cette contrainte est liée à l'obturateur électronique. (...)

A l'obturateur central plutôt.

Greenforce · Août 19, 2013, 14:22:04

Citation de: al1sth le Août 18, 2013, 18:14:30
Bonjour,
J'ai un X20 depuis peu et j'ai remarqué qu'en mode priorité au diaph "A", il ne dépasse pas le 1000éme de seconde. A pleine ouverture au soleil c'est la surex.
J'ai manqué quelque chose dans les réglages ou il n'y a rien à faire ?

Et en passant en mode M ?

Mistral75 · Août 19, 2013, 14:42:18

Citation de: Greenforce le Août 19, 2013, 14:22:04
Et en passant en mode M ?

C'est l'obturateur le facteur limitant (temps de pose mini fonction de l'ouverture), pas le mode.

titroy · Août 19, 2013, 14:57:11

Citation de: al1sth le Août 18, 2013, 20:58:22
L
Merci Titroy, mais ce que je craignais, je peux être contrains de ne pas ouvrir au maxi.

Tu peux faire l'essai tres facilement : on peut obtenir ce problème à f4 par exemple : dans ce cas, la vitesse maxi sera supérieure, mais inférieure au besoin pour obtenir une exposition correcte.

Les vitesses grimpent très vite lorsque le boîtier est configuré en iso auto et dr auto: en cas de contraste fort, le boîtier fera grimpé le niveau du DR (on peut dire plus simplement le niveau de traitement des Bl, Hl ), or pour pousser le niveau du DR, les isos doivent obligatoirement monter !!
On peut donc se retrouver en plein soleil à iso 400, et à f4, la vitesse peut grimper au 1/2000 !
On atteint alors très vite la vitesse maxi autorisée à f4, par exemple.

Enfin, pour répondre à un autre post, cette vitese maxi dépend de l'ouverture pas du mode ( il existe également une contrainte par mode, mais c'est autre chose, ne pas confondre)

titroy · Août 19, 2013, 14:57:52

Citation de: Mistral75 le Août 19, 2013, 14:42:18
C'est l'obturateur le facteur limitant (temps de pose mini fonction de l'ouverture), pas le mode.

Grillé

titroy · Août 19, 2013, 14:59:43

Citation de: Mistral75 le Août 18, 2013, 22:48:49
A l'obturateur central plutôt.

Oui, ta formulation est la bonne !

J ai du déraper sur le clavier !

Greenforce · Août 19, 2013, 15:19:58

Citation de: Mistral75 le Août 19, 2013, 14:42:18
C'est l'obturateur le facteur limitant (temps de pose mini fonction de l'ouverture), pas le mode.

ok, merci.