Z9

[jdm]

Bon courage aux photographes 

De la panneautique LED en bord de court
Comme c'est le cas dans les stades et de nombreux courts de tennis, Roland-Garros s'équipe cette année de panneaux LED en bord de court. Outre l'affichage des principaux sponsors du tournoi, la panneautique permettra de dynamiser le spectacle sportif avec notamment une scénarisation de l'entrée des joueurs sur le court.

Pour le foot ils peuvent diffuser des pub ciblées selon les pays, ce qui signifie que ce que l'on voit sur le stade n'est pas ce qui sera transmis ...

https://twitter.com/UltraLinx/status/1411807406728925196

[Verso92]

Effectivement.

Le Micro programme du Z9 comme tout programme est constitué de blocs ayant chacun une fonction, on assemble ces blocs pour former le programme.
Et on ne réécrit pas tous les blocs à chaque fois ça serait trop long que d'utiliser des blocs fiables et testés.

Dans notre cas je pense qu'ils ont tout simplement réutilisé le bloc écrit pour les One. L'algorithme pour faire tourner deux fichiers par image dans le tampon serait obligatoirement différent, ils ne l'on pas réécrit.

C'est, comme évoqué précédemment, la cause la plus plausible (architecture logicielle existante. Reste à espérer qu'il n'y ait pas du hard impliqué...).

[flitter]

Déjà, tu prends l'exemple d'Olympus qui, sur un boitier à moins de 1 500€, semble faire beaucoup mieux que Nikon sur ce critère là... étonnant, non ?
TPMD (Touche Pas Mon Doudou) !

Et sur le nouveau ( 2200 roros) les progrès sont encore là, 18 mois après leur rachat.
https://www.olympus.fr/site/fr/c/cameras/om_d_system_cameras/om_d/om_1/index.html

[luistappa]

Je ne vois pas trop où ça pourrait coincer en hard puisque le tampon est bien prévu pour stocker du jpg, du raw ou du jpg+raw. Là c'est purement soft avec une routine prévue pour faire tourner dans le tampon un seul fichier par déclenchement, les modif seraient probablement très mineures (une condition sur le flag format de fichier) si on acceptait l'option stockage jpg ou raw, c'est le stockage jpg+raw qui demanderait le plus d'adaptation du sous programme.

[kochka]

Effectivement.

Le Micro programme du Z9 comme tout programme est constitué de blocs ayant chacun une fonction, on assemble ces blocs pour former le programme.
Et on ne réécrit pas tous les blocs à chaque fois ça serait trop long que d'utiliser des blocs fiables et testés.

Dans notre cas je pense qu'ils ont tout simplement réutilisé le bloc écrit pour les One. L'algorithme pour faire tourner deux fichiers par image dans le tampon serait obligatoirement différent, ils ne l'on pas réécrit.

Pourquoi pas?
Mais ce me semble un peu trop réducteur comme explication.
Ceci dit, suite à une expérience malheureuse avec le JPG sur D2x (pour des raisons de place sur CD de sauvegarde en voyage au Pérou), je m'étais juré Plus jamais de JPG.
Mais suite à une erreur de manip je viens de prendre une 1/2 journée de photos en mode vidéo sur Z7, d'où ==> JPG et 16/9.
Au résultat, cette erreur n'a pas été clairement pénalisante.
Je sais bien que dans les cas difficiles, il vaut mieux être en raw, mais pour ces photos , je n'ai constaté aucun handicap.
Alors, si la pré-saisie doit rester en JPG, je n'en ferai pas un caca nerveux.

[Verso92]

Alors, si la pré-saisie doit rester en JPG, je n'en ferai pas un caca nerveux.

Et la post-saisie, en Jpeg ou en RAW ?

[55micro]

Alors, si la pré-saisie doit rester en JPG, je n'en ferai pas un caca nerveux.

Non bien sûr... il y a tout un tas de cas où le jpeg va bien. En iso raisonnables, bdb correcte, etc.

Mais on aurait pu supposer que sur un boîtier pro, qui offre le pré-déclenchement, les utilisateurs vont rencontrer des conditions limites (photographes animaliers, sport en salle...) dans lesquelles le raw aurait été bienvenu.
Par exemple, on peut râler (un peu) que le mode silencieux sur un Canon RP soit limité au jpeg, mais le comprendre comme une segmentation marketing assumée. Plus tu montes en gamme, moins ce type de limitation devient justifiable.

[luistappa]

 [at] Kochka : la programmation c'est pas forcément compliqué mais c'est juste bien organisé.

L'intérêt d'une programmation structurée est justement que les blocs soit réutilisables d'un programme à l'autre.

Tiens il est même très possible que le bloc qui permet l'enregistrement du pré-déclenche soit là depuis le début dans le FW du Z9. Il n'était juste jamais activé puisque rien dans le corps du programme faisait appel à lui.

Exemple : tu avais dans Windows 7 des bouts de Windows NT non actifs mais que l'on pouvait très bien activer même si ce n'était pas documenté.

[Verso92]

Ben voyons ... 

Des blocs de programmation 

Le terme n'est pas forcément bien choisi, mais c'est ça, dans l'esprit.

"Module" me semble pas mal ?


Quand j'étais développeur hardware, il y avait régulièrement des chantiers/groupes de travail pour faire en sorte de faire des modules réutilisables. Mais ça complexifiait inutilement les designs (modules paramétriques, testés dans différentes configurations et lourdement documentés), et ça n'est jamais allé très loin (sauf dans les circuits programmables, où les fabricants ou les développeurs tiers proposaient des modules/IP).

En ce qui me concerne, j'ai toujours préféré le re-use "pragmatique"...  ;-)

[luistappa]

Oui techniquement : Sous-programme en Français, subroutine in english.
Mais modules oui aussi.

blocs, briques c'était pour imager, car tout le monde n'a pas fait de programmation.

[kochka]

Et la post-saisie, en Jpeg ou en RAW ?

Au gré de l'officiant.

[kochka]

[at] Kochka : la programmation c'est pas forcément compliqué mais c'est juste bien organisé.

L'intérêt d'une programmation structurée est justement que les blocs soit réutilisables d'un programme à l'autre.

Tiens il est même très possible que le bloc qui permet l'enregistrement du pré-déclenche soit là depuis le début dans le FW du Z9. Il n'était juste jamais activé puisque rien dans le corps du programme faisait appel à lui.

Exemple : tu avais dans Windows 7 des bouts de Windows NT non actifs mais que l'on pouvait très bien activer même si ce n'était pas documenté.

Je comprends bien, mes cours d'assembleurs datent de 1971/72 et depuis j'ai fait organiser quelques trucs comme çà, à une époque où ce n'était pas encore la mode  (A l'époque nous parlions de briques).
Si Nikon ne propose pas encore le raw,  j'aurais plutôt tendance à supposer une bonne raison que le manque d'idée, ou une mauvaise organisation.
Mais ce ne sont que des suppositions.
Pour rejoindre ce qu'explique Verso, j'avais inversement imposé dans certains cas ce que j'avais appelé faute d'idée plus parlante, "l'étanchéité" de certaines parties logiciel, ne tenant pas à tout re-tester chaque fois qu'un logiciel proche évoluait dans le même matériel.
Pour être plus clair:  CB avec Amex ou Dinner's dans les TPE

[restoc]

Le FW 2.0 est dispo depuis qqs heures. 68 Mbytes.

-Il semble que la maj directe par wifi /Snapbridge ne soit plus proposée.
-Pour ceux qui ne lisent pas l'anglais le Supplement du Manuel guide de référence en Français n'est pas encore disponible à cette heure ; Prendre le petit déjeuner d'abord!!

[restoc]

FW 2.0 : Supplément au Guide de Reference.

https://download.nikonimglib.com/archive5/eHj3L00EoCuu05wf9IB34Gmap098/Z9_FU_addendum_(En)01.pdf

Rectif : la maj via Wifi et Snapbridge est disponible selon ce document .. mais ne l'est pas via la page de téléchargement normale....
Attention :
Aprés update 2., pour ceux qui font du raw et utilisent C1, LR, DXO etc.: l'appareil par défaut est mis en Raw HE. ... Cà va en surprendre plus d'un ...

[Rami]

Des blocs de programmation 

https://www.editions-eni.fr/open/mediabook.aspx?idR=3b0b7edb3ad5f3f8d594e5ebfbf75943

[Verso92]

Attention :
Aprés update 2., pour ceux qui font du raw et utilisent C1, LR, DXO etc.: l'appareil par défaut est mis en Raw HE. ... Cà va en surprendre plus d'un ...

Comment cela est-ce possible ?

Si les photos ont été prises en NEF compressés sans perte (par exemple), comment pourront-elles être ouvertes par C1/LR/DxO en NEF "HE" ?

Comprendre que les NEF compressés sans perte ne seront plus lus ? autre ?

Je ne savais pas qu'on parlait informatique à ce niveau là chez Nikon 😂

Je comprends mieux certaines incohérences et lacunes...  ;-)

[Tonton-Bruno]

Je vais tenter un résumé sans grand espoir de clore ce débat stérile.

En raison de contraintes d'enregistrement, Nikon ne propose sur le Z9 que des rafales en jpg pour les cadences de 30 et de 120i/s.

A l'occasion de la sortie du FW2.0 Nikon offre une nouvelle fonctionnalité très intéressante qui consiste à pouvoir enregistrer les photos entre 0,3 et 1s avant le déclenchement, pourvu qu'on maintienne le déclencheur enfoncé à mi-course pendant ce laps de temps. La durée totale de la rafale après le déclenchement est programmable entre 1 et 4s.
Il s'agit donc d'une fonction destinée à faciliter la saisie d'un instant très particulier, on pourrait dire "l'instant décisif à la portée de tous".
Cette fonction n'est disponible que pour les rafales de 30 ou 120i/s, donc exclusivement en JPG.

Tout le monde aurait envie de disposer de cette fonction aussi pour les rafales de fichiers RAW, à 10, 15 ou 20i/s.

Ce serait un tel avantage face à la concurrence que tout le monde comprend que si Nikon avait pu le proposer il l'aurait fait.

Nous n'avons aucune idée des contraintes techniques qui n'ont pas permis à Nikon de pousser plus loin son avantage, et il ne fait aucun doute que si cette contrainte peut être levée dans un futur proche sans intervention hardware au niveau du SAV, elle le sera.

La seule chose certaine, c'est que cette fonctionnalité très séduisante dont on avait vu les prémices sur les Nikon One est promise à un bel avenir et qu'on la retrouvera certainement dans tous les futurs boîtiers, même d'entrée de gamme... et y compris en RAW, cela va sans dire !

[Verso92]

Entre un One et son processeur d'il y a 10 ans et un Z9 d'aujourd'hui , j'imagine qu'il y a un gouffre hardware et software .

Sur ces machines , compte tenu du besoin de réactivité/instantanéité , je n'imagine pas Nikon utiliser un langage hyper compilé généraliste mais plutôt un langage machine spécialisé ou carrément un assembleur ( donc dédié à une famille de processeur ) .

Certes on peut ré-utiliser des lignes de code ou des algorithmes déjà élaborés sur d'anciennes machines , mais parler de "blocs de programmation" facilement ré-adaptables , c'est risible ...

J'imagine un langage de "haut niveau" pour la majorité du code, avec des briques en langage "bas niveau" pour certains modules "critiques".

Le code en langage "haut niveau" est en principe recompilable sans trop de dégâts sur un autre processeur hôte.


Après, reste le mystère de cette limitation en Jpeg pour le mode "C30" (30 vps), puisque le Z9 force le Jpeg normal "large" dans ce cas, format plus gourmand que le NEF "HE"...

[yorys]

...
Mais on aurait pu supposer que sur un boîtier pro, qui offre le pré-déclenchement, les utilisateurs vont rencontrer des conditions limites (photographes animaliers, sport en salle...) dans lesquelles le raw aurait été bienvenu.
Par exemple, on peut râler (un peu) que le mode silencieux sur un Canon RP soit limité au jpeg, mais le comprendre comme une segmentation marketing assumée. Plus tu montes en gamme, moins ce type de limitation devient justifiable.

Il y a clairement, actuellement, dans le Z9 une limitation. C'est celle qui interdit d'utiliser les vitesses maximales de rafales (30 et 120 images/sec avec le Raw), est ce que cette limite est définitive (essentiellement hardware) ou provient t'elle d'un codage pas complètement optimisé on n'en sait rien, seuls les ingénieurs de chez Nikon pourraient le dire. Et si elle est hardware provient elle du processeur, du capteur, des canaux de communication interne ?, bien malin qui peut aujourd'hui affirmer quoi que ce soit, sachant que le traitement de signal à haute vitesse est un art particulier et difficile.

Je pense qu'en implémentant la nouvelle fonction d'images anticipée les développeurs (et leur direction) se sont heurté à un choix : limiter cette fonction en vitesse à 20  im/sec et l'autoriser en Raw, ou la réserver aux plus hautes vitesses avec la restriction aux Jpeg seulement. Pour une raison qui là aussi nous échappe, certainement liée à l'architecture logicielle du firmware, voire au temps disponible, il ne leur a pas été possible de proposer les deux dans cette mise à jour (ce qui laisse un espoir pour l'avenir).

Par contre je trouve leur choix actuel parfaitement logique. L'idée étant de pouvoir chopper des images extrêmement fugaces, très difficiles à saisir autrement. Dès lors plus il y aura d'images anticipées disponibles, plus il y aura de chances que l'une d'entre elles soit la "bonne". L'exemple parfait est celui de la balle de fusil, dont on peut se demander si la photo n'a pas en fait été prise avec une version béta du firmware 2.0.     

Comme il s'agit, y compris sur le plan de la communication et du marketing, de positionner le Z9 comme l'APN capable de ramener "l'image impossible", privilégier l'obtention de cette image par rapport à sa capacité de post-traitement me parait un choix judicieux et, encore une fois, logique.

Après je ne dis pas que cette fonction ne serait pas intéressante dans des situations moins extrêmes où le fait de disposer de capacités maximale de post-traitement est utile voire indispensable (portraits par exemple), mais c'est certainement moins "vendeur" que la balle de fusil (je rappelle quand même que la division photo de Nikon joue sa peau avec le Z9), cela viendra peut-être plus tard.
 

[jeanbart]

Il s'agit donc d'une fonction destinée à faciliter la saisie d'un instant très particulier, on pourrait dire "l'instant décisif à la portée de tous".

Il faut quand même que cet événement soit facilement prévisible et qu'il soit si rapide qu'il nécessite une cadence élevée pour la rafale.
Un peu comme le départ d'un 100 mètres ? Et encore au pire on utilise la rafale dès lors que les athlètes sont en position de départ.

Est-ce que ce n'est pas surtout fait pour palier en partie le très léger retard des viseurs électroniques ?

[yorys]

...
Est-ce que ce n'est pas surtout fait pour palier en partie le très léger retard des viseurs électroniques ?

Encore faudrait il connaitre le rapport entre ce retard (qui doit exister) et celui des transmission neuronales inhérentes à l'opérateur, pas trop le temps de chercher là, mais je subodore qu'il y a au moins un ordre de grandeur de différence entre les deux, voire plus (au détriment du réflexe humain).

[Verso92]

Seul Nikon le sait 🤗

On peut quand même imaginer que s'ils avaient pu le faire , ils l'auraient fait , donc il y a possiblement une incompatibilité hardware ( définitive ou temporaire )

Si c'est une incompatibilité hardware, il faudra attendre le Z9II...

[jenga]

Seul Nikon le sait 🤗

On peut quand même imaginer que s'ils avaient pu le faire , ils l'auraient fait , donc il y a possiblement une incompatibilité hardware ( définitive ou temporaire )

Bah, ils auraient dû demander aux experts en programmation de ce fil, qui sont capables de deviner l'architecture logicielle et matérielle du Z9 rien qu'en voyant sa photo.

[Verso92]

Bah, ils auraient dû demander aux experts en programmation de ce fil [...]

Ou faire sous-traiter la fonction chez Olympus (qui, eux, savent faire) ?

[jenga]

Ou faire sous-traiter la fonction chez Olympus (qui, eux, savent faire) ?

Ils savent faire des Z9?