#3657(swscale:new): 32 Bit per Channel sws conversion
#3657: 32 Bit per Channel sws conversion ---------------------------------+--------------------------------------- Reporter: sun | Type: enhancement Status: new | Priority: wish Component: swscale | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ---------------------------------+--------------------------------------- Hello, As there are more and more Cameras able to record with more than 8 bit per pixel and there already are programs like Shotcut and Blender which support high-precision internal processing, e.g. blender is unable to handle 10-bit videos properly, because converting a 16 bit buffer from the sws yuv to rgb conversion to its internal 32bit buffer would be too slow and therefore it has to use an 8 bit buffer. If ffmpeg could convert to 32bit directly, there wouldn't be the need to do two conversion steps, 10 ->16->32 and native high precision video support would be much easier to implement! -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: 32 Bit per Channel sws conversion -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: new Priority: wish | Component: swscale Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Changes (by gjdfgh): * cc: nfxjfg@… (added) Comment: What kind of 32 bit? Integer? Float? -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: 32 Bit per Channel sws conversion -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: new Priority: wish | Component: swscale Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by sun): Oh sorry that I forget to mention that blender uses float type buffer. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:2> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: 32 Bit per Channel sws conversion -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: new Priority: wish | Component: swscale Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by sun): Oh sorry that I forget to mention that blender uses float type buffer. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: 32 Bit per Channel sws conversion -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: new Priority: wish | Component: swscale Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by gjdfgh): Float images would be useful for some other things too, but I bet nobody wants to fight libswscale to add conversion for this (which would probably be very non-trivial). -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: 32 Bit per Channel sws conversion -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: new Priority: wish | Component: swscale Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by Cigaes): When people request float values for pixels (or samples), I always wonder if they really need the features of floats, i.e. more absolute accuracy for numbers near 0. It may make sense for samples, to keep the same relative accuracy regardless of the overall volume. For pixels, maybe issues with gamma will need more accuracy near 0, but I am not really convinced. Apart from that, I wonder if people realize that 32-bits fixed point is more accurate than floats on 99.21875% of the range. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Changes (by cehoyos): * status: new => open * version: unspecified => git-master -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:6> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by omerjerk): Hey, Sorry for commenting on an almost 2 years old ticket. But, is this still required ? I'd love to start with this. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:7> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by cehoyos): Replying to [comment:7 omerjerk]:
I'd love to start with this. How would you use the pix_fmt after adding it to libavutil?
-- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:8> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by omerjerk): Replying to [comment:8 cehoyos]:
Replying to [comment:7 omerjerk]:
I'd love to start with this. How would you use the pix_fmt after adding it to libavutil?
I went through some of the code present in utils.c file in libswscale. I'm not really sure how difficult this feature is. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:9> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
Replying to [comment:8 cehoyos]:
Replying to [comment:7 omerjerk]:
I'd love to start with this. How would you use the pix_fmt after adding it to libavutil?
I went through some of the code present in utils.c file in libswscale. I'm not really sure how difficult this feature is. Allow me to repeat my question: Once you have mastered all difficulties and added the new pixel format to
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by cehoyos): Replying to [comment:9 omerjerk]: libavutil and libswscale, what usage would the new pix_fmt have within FFmpeg? -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:10> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by richardpl): To amuse people. like you. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:11> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by gjdfgh): Certainly more usage than "important" formats like MONOWHITE. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:12> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by cehoyos): I created tickets #5302 and #5303 with floating point samples. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:13> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by emilyb): We would like to have this too. The use case is high bit depth processing in HDR mode where we want to be able to have super white/black (i.e. < 0.0 and > 1.0 values) at certain stages in the processing. Using floats is simpler to work with than 32bit integers with headroom and still has enough precision. We also do some advanced image processing which requires conversion to float at some point so having the conversion early is beneficial for performance for us. As one person noted earlier floats have higher precision around 0.0 than 1.0,but in the range [0.5, 1.0] you still have 23 bits per component in precision which is enough. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:14> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by mtc): i guess this means a component color space (RGB/XYZ based, not luminance chroma (YUV) ) RGB16float (16*3 48-bit) or RGB32float (16*3 48-bit) also using linear transfer characteristics (not [sRGB-gamma https://en.wikipedia.org/wiki/SRGB#The_sRGB_transfer_function_.28.22gamma.22...] or [HLG https://en.wikipedia.org/wiki/Hybrid_Log-Gamma] or Perceptual- Quantizer ... floating with support for negative-values to prevent data-loss (clamping-artifacts) from super-whites and outside of color-primaries'gamut colors what can occur from conversion from YUV(luminance-chroma) color spaces importing from exif2.0 sYCC (most modern camera jpegs) can clip overwhites esp blues also if then thus also support outputting into float-supporting formats e.g. OpenEXR for export into supporting rendering programs support for linearRGB heps make it easier to support linear- gamma(radiometric) image resizing -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:15> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: open Priority: wish | Component: swscale Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by mtc): gimp 2.9 now supports floating-point RGB formats -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:16> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3657: float pixel format -------------------------------------+----------------------------------- Reporter: sun | Owner: Type: enhancement | Status: closed Priority: wish | Component: swscale Version: git-master | Resolution: fixed Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Changes (by richardpl): * status: open => closed * resolution: => fixed Comment: There are gray and gbr(a)p float formats now. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3657#comment:17> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
participants (1)
-
FFmpeg