You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there any way to transform 10bit footage (e.g. yuv422p10le) without losing the dynamic range in the 10bit footage? I looked at the supported list of pixfmts in the vid.stab source (e.g. in https://github.com/georgmartius/vid.stab/blob/master/src/frameinfo.h#L32), and they all seem to be 8 bits per pixel per channel, and I see unsigned char *s are used to store pixel data in a few places in the code.
I therefore assume this would be a pretty big undertaking, but I'd like to request it anyway in case it's a reasonably straightforward change.
As a simpler case, would supporting only little endian types with full-byte depths (i.e. 8bit, 16bit eg yuv444p16le) be more feasible? IIUC, FFmpeg can trivially up-convert e.g. 10bit to 16bit, then scale back to 10bpp in an almost-lossless fashion, correct? So running a vidstabtransform filter in the middle of that filter pipeline should be possible, and would keep the implementation much simpler.
And I'd imagine that only the transform filter would absolutely need this support -- I'd guess that motion detection using footage down-sampled to 8-bit formats would work more or less identically to higher bit depths (modulo some very minor changes obviously). Is that intuition correct?
So in an ideal world it would look something like...
Hello,
Thanks for vidstab, it's a super useful tool.
Is there any way to transform 10bit footage (e.g. yuv422p10le) without losing the dynamic range in the 10bit footage? I looked at the supported list of pixfmts in the vid.stab source (e.g. in https://github.com/georgmartius/vid.stab/blob/master/src/frameinfo.h#L32), and they all seem to be 8 bits per pixel per channel, and I see
unsigned char *
s are used to store pixel data in a few places in the code.I therefore assume this would be a pretty big undertaking, but I'd like to request it anyway in case it's a reasonably straightforward change.
As a simpler case, would supporting only little endian types with full-byte depths (i.e. 8bit, 16bit eg
yuv444p16le
) be more feasible? IIUC, FFmpeg can trivially up-convert e.g. 10bit to 16bit, then scale back to 10bpp in an almost-lossless fashion, correct? So running a vidstabtransform filter in the middle of that filter pipeline should be possible, and would keep the implementation much simpler.And I'd imagine that only the transform filter would absolutely need this support -- I'd guess that motion detection using footage down-sampled to 8-bit formats would work more or less identically to higher bit depths (modulo some very minor changes obviously). Is that intuition correct?
So in an ideal world it would look something like...
Thanks in advance!
The text was updated successfully, but these errors were encountered: