Change QC for camera test suite to be able to test for first-stage compressed videos

Aperta
  • Qualcosa non va?
#85 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
opencv, python
Ambito
testing

Direzione di ricerca

Inizia dal codice collegato in src/aind_video_utils/ffmpeg_utils.py e confronta il relativo comportamento di QC nella compressione della prima fase con la suite di test della videocamera presente in questo repository. Chiarisci come la suite debba interpretare i video della prima fase, inclusi la luma a intervallo completo e i metadati dello spazio colore mancanti. L'attività è completata quando la QC può testare video compressi della prima fase con una gestione degli intervalli concordata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Ticket created after a discussion on this group chat: https://teams.microsoft.com/l/message/19:[email protected]/1764195675772?context=%7B%22contextType%22%3A%22chat%22%7D

Galen's code: https://github.com/AllenNeuralDynamics/aind-video-utils/blob/836575978000e8c6b31f79f0b61936d8539afef7/src/aind_video_utils/ffmpeg_utils.py#L25

To be fair, Galen already has code that does QC on the first-stage compression video while Bruno's code assumes the video is twice-compressed. Keeping this ticket to retain the information.

Per Galen:

But there are other issues, like really your luma for yuv videos should be in the "standard range" (16 to 235) for the output of the second-stage encoder, and we developed the first-stage encoder to use the full range (0 to 255) to reduce quantization noise before being gamma-encoded.

However you will not be able to see that if your data are automatically (through an unknown conversion path) converted to rgb (presumably 0 to 255). Worse, if your data are weird in some way, like the first stage encoder which uses full range, then it is totally implementation dependent on how those values are converted to RGB. Is the full range properly detected and honored? Is it ignored and values 0-15 and 236-255 now appear to be saturated? Even worse yet, many videos have no color space metadata, and might do things like use the full range (0-255) and not properly advertise it, so then it's really not clear how opencv or any other consumer should interpret the luma in 0-15 and 236-255.

Lingua principale
Python
Stelle
0
Fork
1
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di AllenNeuralDynamics/contraqctor

Tutte le issue di AllenNeuralDynamics/contraqctor

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.