AllenNeuralDynamics / AllenNeuralDynamics/contraqctor
Change QC for camera test suite to be able to test for first-stage compressed videos
- Linguagem predominante
- Python
- Estrelas
- 0
- Forks
- 1
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Descrição
Ticket created after a discussion on this group chat: https://teams.microsoft.com/l/message/19:cb7067f707394861803c6edbd2e2a57b@thread.v2/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.
Guia de contribuição
Nenhum guia de contribuição indexado para este repositório
Avaliação
Esta issue ainda não foi avaliada.