Test de compression Prores au lieu de H265 lors du post-traitement pour voir si on gagne en définition…
Donc pour vous, quelle vous semble être la meilleure définition ?
Le rendu colorimétrique et le contraste sont différents, mais c’est un autre sujet…
Le détail des textes sur l’antenne GNSS aide pour juger 
Bon à savoir: les fichiers Prores sont bien plus volumineux.
Chaque image est compressée unitairement (image de type “I”) avec des techniques proches du JPEG (DCT), et il n’y a pas d’images de type “P” ou “B” qui ne sont que des différences avec les images précédentes ou suivantes avec des informations sur les déplacements des macroblocs, ce qui crée des artefacts supplémentaires.
C’est pas magique, mais ça limite la seconde compression lors du post-traitement:
Vu que les fichiers sont bien plus volumineux (x12 environ) on peut les supprimer une fois les images extraites par le script.
L’app de post-traitement permet aussi de sortir des JPEG… il faut que je teste ça, car ça éliminerai totalement une étape de décompression/recompression.
Une info de plus pour le Prores: sur la même capture timelapse, les images JPEG finales pèsent 5.2Go quand la compression intermédiaire est en H265 et 5.9Go quand on passe en Prores.
Ceci indique indirectement qu’il y a un peu plus de détails en Prores.
Merci beaucoup pour le partage !
De mon côté, assez déçu du rendu final avec le mode timelapse vidéo 
Inconvénients
Avantages
Je cherche donc à creuser le mode photo avec intervalle pour nettement gagner en lisibilité et qualité globale : All Panoramax street level imagery (merci @atchisson)
Les deux gros points négatifs :
Avez-vous des pistes à ce sujet ?
Toujours des compromis et des choix à faire… en attendant la caméra parfaite
Pour la luminosité, je monte souvent de +0.3EV, même en photo, ça brûle un peu plus le ciel, mais c’est pas vraiment gênant.
As-tu configuré le mode HDR (10bits) pour le timelapse et les vidéos ?
Lors du post-traitement ça permet ensuite de choisir “shadowboost” comme tone-mapping.
Il faut que j’essaie cela, merci.
Sinon pour le stockage, tu as quoi comme SSD ?
J’ai essayé avec deux différents et il ne les a pas reconnus
Testé avec un boitier USBC/NVMe tout à fait standard.
Par contre, formatage en exFAT sûrement obligatoire.
Bonjour,
Des nouvelles du stitching des “photos par intervalles” sur la camera ?
cette caméra me fait envie, mais sans possibilité de l’utiliser sous linux c’est un no-go.
J’ai tenté un stitching via le script hugin ci-dessus (en virant la mise à l’horizontale automatique pour le moment, le temps de trouver comment compiler Equirectangular_rotate). J’ai utilisé la photo de @cquest en haut du thread…
ça a l’air pas mal, mais la résolution de la photo dans le forum n’étant que de 1920x960 c’est pas facile de jauger la qualité 
Est-ce qu’une bonne âme pourrait mettre à dispo une photo non stitchée dans sa résolution d’origine (13888x6944 a priori) ? Sur https://drop.chapril.org par exemple ?
Mon test donne ça :
Merci d’avance !
Salut, voila une image non stitchée : https://drop.chapril.org/download/a4f49a97692865ce/#98TYnqcIucAOVd_v4vTlKA
à noter que j’ai des protections de lentille, contrairement à Christian
Merci pour la photo !
Avec le script et les réglages de son créateur, le stitch est très perfectible sur cette photo. Je suppose qu’il faut refaire un “réglage” pour la caméra (au mieux) avec Hugin ( un .pto) . Je maîtrise encore mal Hugin, mais j’ai fait quelques test. Je vais regarder pour traiter précisément cette photo et voir ce que ça donne
L’hypothèse c’est qu’une fois qu’on a un réglage Hugin qui fonctionne bien pour une caméra, il sera bon pour toutes les photos prises par la même caméra…
ca sera à vérifier ensuite 
En théorie oui… mais dans la pratique c’est moins sûr, malheureusement !
Pas évident…
Pourtant j’ai mis une trentaine de points de contrôles a la main (hugin n’en trouve aucun en automatique, contrairement à la photo de Christian)
Est-ce que les protections font des artefacts qui gênent ? Ou encore j’utilise mal le logiciel
Ah ! 
Il semblerait que le mieux soit l’ennemi du bien et que peu de points de contrôles (seulement 2) fassent mieux que beaucoup (même si le logiciel n’est pas content).
je viens de tester par acquis de conscience et, surprise, qoocamstudio (v3.3.0.3 a ce jour) semble fonctionner correctement sous linux (mint ici) avec wine.
Rapidité de traitement et qualité du stitch sans commune mesure avec hugin (et sans réglages particuliers).
Super nouvelle ça… il faut que je teste !
le seul soucis que j’ai vu c’est des popups qui ne s’affichent pas (notamment lors du clic sur le bouton d’export, et la popup “export terminé”)… Suffit de cliquer “en dehors de la fenêtre de l’appli”, ou 2 fois sur l’icône dans la barre des taches pour que ça revienne.
Je viens de voir aussi que l’appli veut bien stitcher une image “originale” de qoocam, mais ne fait rien sur ton image d’exemple récupérée du forum (puis upsizée à la taille des images qoocam).
Probablement aucun rapport avec linux, je suppose que les metadatas dans l’image originale contiennent des infos pour le stitch avec l’appli officielle. (y’a notamment un gros blob dans les exifs)
Petit souci avec une perche de 3 m et câble de charge branché, j’ai cassé et perdu le cache de la tape d’accès au port USB c. Les branche d’arbres trop proche de la velo route 
J’espère que les photos seront de bonne qualitées.
J’ai parcouru tout le contis et une petite de Saint julien en born.
