Re: [Cin] HDR footage from images via ffmpeg

[Andrew Randrianasulu via Cin]

ср, 31 мая 2023 г., 22:35 Andrew Randrianasulu :

>
>
> ср, 31 мая 2023 г., 14:09 Andrea paz :
>
>> > is HDR basically "some 8 or 10 bit tech + wide gamut light emitting"?
>>
>> I am not familiar with HDR. All I know is theoretical and dated
>> (Brinkmann's book on compositing).
>> HDR can only be in floating point, using a normalized color range (0-1
>> instead of 0-255, etc.). In fact in floating point it is possible to
>> have values above 1 while in 8, 10 -bit it is not possible to have
>> values above the limits.
>> Upon receiving an HDR video signal, there are algorithms to map and
>> balance these values on SDR or HDR displays. This is called tone
>> mapping.
>> To summarize it is necessary:
>> 1- An HDR video signal (usually obtained by merging multiple frames at
>> different exposures).
>> 2- A tone mapping tool
>> 3- A suitable display (usually high nits, i.e., brilliance)
>>
>
> So, may be due to 1) modern smartphones have so many cameras!
>
>
>
> I am looking at shotcut forums just for inspiration
>
> https://forum.shotcut.org/t/hdr-support-export/29666/11
>
> 
>
> Any editor working in HDR needs to be able to import BT.2100 HLG, BT.2100
> PQ, BT.2020 and BT.709 files and map them to a common timeline format,
> output to those 4 formats, and allow the user to calculate the HDR10
> metadata if you choose to have a PQ output format (this isn’t automatic as
> you need to know the gamut and peak brightness of the monitor you edited
> on).
>
> ===
>
>
> https://www.voukoder.org/forum/thread/1005-good-x265-settings-mar-2022-update-merged-to-v11-1/
>
> === quote ===
>
> *HDR Support (x264 & x265):*
>
>
> *Tagging DCI-P3:* --master-display
> G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(?,1)
>
> *Tagging BT.709:* --master-display
> G(15000,3)B(7500,3000)R(32000,16500)WP(15635,16450)L(?,1)
>
> *TaggingBT2020:* --master-display
> G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(?,1)
>
> The L(?,1) indicates lux ratio (e.g., 1000:1). This value has no standard
> and needs to be checked and written manually on each HDR video.
>
>
> If tagging for the source vid is unknown, find 1 of the following format
> in source video metadata:
>
> DCI-P3: G(x0.265, y0.690), B(x0.150, y0.060), R(x0.680, y0.320),
> WP(x0.3127, y0.329)
>
> bt.709: G(x0.30, y0.60), B(x0.150, y0.060), R(x0.640, y0.330),
> WP(x0.3127,y0.329)
>
> bt.2020: G(x0.170, y0.797), B(x0.131, y0.046), R(x0.708, y0.292),
> WP(x0.3127,y0.329)
>
>
> *Content lumiance x265: *--max-cll  frame-avg light level cd/m2> e.g., 1000,640
>
> *Content lumiance x264: *--cll  frame-avg light level cd/m2> e.g., 1000,640
>
> CLL has no standard and needs to be checked and written manually on each
> HDR video
>
>
> *Indicate HDR10 content in supplemential enhance info (SEI)**, x264 **: *
> --hdr10
>
>
> *Optimize HDR10 content (increase video size) per block (optional, x264
> [image: :(] *--hdr10-opt
>
>
> *Indicate color range and transfer properties: *--colormatrix 
> --transfer 
>
> Color range can vary thanks for both compatibility and multple HDR
> implementations, (e.g., gbr bt709 fcc bt470bg smpte170m YCgCo bt2020nc
> bt2020c smpte2085 ictcp). Check the source video metadata for them
>
>
> 
>
>
> https://stackoverflow.com/questions/69251960/how-can-i-encode-rgb-images-into-hdr10-videos-in-ffmpeg-command-line
>
> this answer says mastering-display is NOT for your editing display but for
> ideal viewing display! Are they supposed to be the same?
>
> Not sure how you calculate max-cll et all from your display / source ...
>
>
>
https://github.com/HDRWCG/HDRStaticMetadata


HDRStaticMetadata

HDR GENERATOR TOOL In its essence, this tool will calculate the maxFall and
maxCLL of a 16-bit TIFF frame using the formula 'PQ1_f' (to linearize).
This application will scan a folder of TIFF files and proceed to perform
calculations on the files. File results are calculated concurrently
according to the number of threads a user specifies. The results are logged
to a file. The files processed and the time the files were processed are
logged as well. OpenImageIO is used to read the files into a 16bit vector.
OpenCV is used for conveniently accessing pixels as well as croping an
image for frame average light level calculations. QtCore and QtConcurrent
are used for abstracted file system access and concurrency respectively.
The text files generated in this process are then analyzed in a post
process tool to calculate maxFall and maxCLL values at 99.9%.

===


from https://forum.doom9.org/archive/index.php/t-177135.html


View Full Version : How to analyze an HDR video for peak brightness level
for the setting of metadata?


--

so, this is a bit more complicated than just feeding x265 with params 





>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrew Randrianasulu via Cin]

ср, 31 мая 2023 г., 14:09 Andrea paz :

> > is HDR basically "some 8 or 10 bit tech + wide gamut light emitting"?
>
> I am not familiar with HDR. All I know is theoretical and dated
> (Brinkmann's book on compositing).
> HDR can only be in floating point, using a normalized color range (0-1
> instead of 0-255, etc.). In fact in floating point it is possible to
> have values above 1 while in 8, 10 -bit it is not possible to have
> values above the limits.
> Upon receiving an HDR video signal, there are algorithms to map and
> balance these values on SDR or HDR displays. This is called tone
> mapping.
> To summarize it is necessary:
> 1- An HDR video signal (usually obtained by merging multiple frames at
> different exposures).
> 2- A tone mapping tool
> 3- A suitable display (usually high nits, i.e., brilliance)
>

So, may be due to 1) modern smartphones have so many cameras!



I am looking at shotcut forums just for inspiration

https://forum.shotcut.org/t/hdr-support-export/29666/11



Any editor working in HDR needs to be able to import BT.2100 HLG, BT.2100
PQ, BT.2020 and BT.709 files and map them to a common timeline format,
output to those 4 formats, and allow the user to calculate the HDR10
metadata if you choose to have a PQ output format (this isn’t automatic as
you need to know the gamut and peak brightness of the monitor you edited
on).

===

https://www.voukoder.org/forum/thread/1005-good-x265-settings-mar-2022-update-merged-to-v11-1/

=== quote ===

*HDR Support (x264 & x265):*


*Tagging DCI-P3:* --master-display
G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(?,1)

*Tagging BT.709:* --master-display
G(15000,3)B(7500,3000)R(32000,16500)WP(15635,16450)L(?,1)

*TaggingBT2020:* --master-display
G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(?,1)

The L(?,1) indicates lux ratio (e.g., 1000:1). This value has no standard
and needs to be checked and written manually on each HDR video.


If tagging for the source vid is unknown, find 1 of the following format in
source video metadata:

DCI-P3: G(x0.265, y0.690), B(x0.150, y0.060), R(x0.680, y0.320),
WP(x0.3127, y0.329)

bt.709: G(x0.30, y0.60), B(x0.150, y0.060), R(x0.640, y0.330),
WP(x0.3127,y0.329)

bt.2020: G(x0.170, y0.797), B(x0.131, y0.046), R(x0.708, y0.292),
WP(x0.3127,y0.329)


*Content lumiance x265: *--max-cll  e.g., 1000,640

*Content lumiance x264: *--cll  e.g., 1000,640

CLL has no standard and needs to be checked and written manually on each
HDR video


*Indicate HDR10 content in supplemential enhance info (SEI)**, x264 **: *
--hdr10


*Optimize HDR10 content (increase video size) per block (optional, x264
[image: :(] *--hdr10-opt


*Indicate color range and transfer properties: *--colormatrix 
--transfer 

Color range can vary thanks for both compatibility and multple HDR
implementations, (e.g., gbr bt709 fcc bt470bg smpte170m YCgCo bt2020nc
bt2020c smpte2085 ictcp). Check the source video metadata for them




https://stackoverflow.com/questions/69251960/how-can-i-encode-rgb-images-into-hdr10-videos-in-ffmpeg-command-line

this answer says mastering-display is NOT for your editing display but for
ideal viewing display! Are they supposed to be the same?

Not sure how you calculate max-cll et all from your display / source ...
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrea paz via Cin]

> is HDR basically "some 8 or 10 bit tech + wide gamut light emitting"?

I am not familiar with HDR. All I know is theoretical and dated
(Brinkmann's book on compositing).
HDR can only be in floating point, using a normalized color range (0-1
instead of 0-255, etc.). In fact in floating point it is possible to
have values above 1 while in 8, 10 -bit it is not possible to have
values above the limits.
Upon receiving an HDR video signal, there are algorithms to map and
balance these values on SDR or HDR displays. This is called tone
mapping.
To summarize it is necessary:
1- An HDR video signal (usually obtained by merging multiple frames at
different exposures).
2- A tone mapping tool
3- A suitable display (usually high nits, i.e., brilliance)
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrew Randrianasulu via Cin]

вс, 28 мая 2023 г., 01:17 Andrea paz :

> > But monitor itself can provide  this info, via edid? If I read info
> about compiz color management plugin correctly 
> I don't know because I have never dealt with HDR displays, but since
> it is a VESA certification, I think it is likely to be found in the
> EDID.
>

https://dmitry-s-safonov.medium.com/full-screen-color-correction-in-linux-f2925be58f97


is HDR basically "some 8 or 10 bit tech + wide gamut light emitting"?
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrea paz via Cin]

> But monitor itself can provide  this info, via edid? If I read info about 
> compiz color management plugin correctly 
I don't know because I have never dealt with HDR displays, but since
it is a VESA certification, I think it is likely to be found in the
EDID.
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrew Randrianasulu via Cin]

вс, 28 мая 2023 г., 00:50 Andrea paz :

> I have X11 so I can use the ICC profiles. The 10 bit depth color works
> halfway for me: some applications work, some crash or give wrong
> colors but most don't take the 10 bits into account. I didn't know the
> 'export' line you passed me, I'm probably doing something wrong but it
> doesn't work. It produces a series of graphics server errors. I have
> given up trying by now.
>

yeah, might be egl/mesa regression ...


> However, HDR is not going from 8 bits to 10 bits or higher.
> Whatever color depth is used, HDR means being able to map values
> outside its limits onto the monitor.


But monitor itself can provide  this info, via edid? If I read info about
compiz color management plugin correctly 

To do this also requires an
> HDR-type monitor.
> https://wiki.archlinux.org/title/HDR_monitor_support
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrea paz via Cin]

I have X11 so I can use the ICC profiles. The 10 bit depth color works
halfway for me: some applications work, some crash or give wrong
colors but most don't take the 10 bits into account. I didn't know the
'export' line you passed me, I'm probably doing something wrong but it
doesn't work. It produces a series of graphics server errors. I have
given up trying by now.

However, HDR is not going from 8 bits to 10 bits or higher.
Whatever color depth is used, HDR means being able to map values
outside its limits onto the monitor. To do this also requires an
HDR-type monitor.
https://wiki.archlinux.org/title/HDR_monitor_support
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrew Randrianasulu via Cin]

сб, 27 мая 2023 г., 23:45 Andrew Randrianasulu :

>
>
> сб, 27 мая 2023 г., 23:19 Andrew Randrianasulu :
>
>>
>>
>> сб, 27 мая 2023 г., 23:05 Andrea paz :
>>
>>> I think HDR in Linux is still a long way off. Wayland seems to have
>>> started working on it these days. Monitors and TVs claimed to be HDR
>>> are mostly Fake-HDR. However, you can't have HDR without Color
>>> Management.
>>>
>>
>>
>> https://www.reddit.com/r/linuxquestions/comments/xryg63/does_linux_support_dcip3_or_10_bit/
>>
>> 
>> leo_sk5
>> 
>> • 8 mo. ago
>>
>> 10-bit works. You can get DCI-P3 with proper colour profile. Just use
>> x11. You probably read about wayland where these are work in progress. Btw,
>> linux itself may support 10bit colour, but same can not be said for other
>> software that runs on linux.
>>
>> Just put DefaultDepth 30 in /etc/X11/xorg.conf.d/ (default value would
>> be 24). If you also run kde, consider running echo "export
>> KWIN_OPENGL_INTERFACE=egl" >~/.config/plasma-workspace/env/use_egl.sh
>> also, as kde may crash otherwise. With above changes, 10-bit colour works
>> for me in kde
>>
>> 
>>
>>
>> I wonder how THOSE color profiles look Do you have one? Can you run
>> some testing/introspection programs on it?
>>
>
> Also
>
> https://github.com/compiz-reloaded/compicc
>
> ===
>
> Features
>
> CompICC uses Oyranos to configure the ICC profiles for each monitor. The
> order of monitor configuration inside Oyranos is, first look in the Oyranos
> DB for a explicit configured ICC profile, if no then scan the installed ICC
> profiles for one matching the to be setup device, if not generate on the
> fly from the monitors EDID data block, if not try from the Xorg log and as
> a last means take sRGB, if not fail miserably ;-)
>
>- instant desktop colour correction on GPU with compiz
>- multi monitor support
>- ICC Profile in X support
>- X Color Management 0.3 DRAFT1 support
>- EDID -> ICC profile on the fly
>- 16-bit per channel compositing
>- hotplug capable
>- wide gamut monitor calibration
>- support 30-bit monitors
>
> =
>
> I wonder if you ever get better result by using those system-wide methods
> .
>
>>

http://www.oyranos.org/2014/05/image-editing-with-30-bit-monitors/index.html


Krita supports with the OpenGL backend even native 10-bit per colour
component. Menus in Sketch are black. Krita shows minimal artefacts through
twice colour converting from image to sRGB by Krita and from sRGB to the
monitor colour space by CompIcc. But this effect is much lesser visible
than the improvements through its 30-bit support.


so ... it was kinda  working (probably with nvidia quadro?) back in
2014 ...

I never heard about THIS color management system before 

>
>>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrew Randrianasulu via Cin]

сб, 27 мая 2023 г., 23:19 Andrew Randrianasulu :

>
>
> сб, 27 мая 2023 г., 23:05 Andrea paz :
>
>> I think HDR in Linux is still a long way off. Wayland seems to have
>> started working on it these days. Monitors and TVs claimed to be HDR
>> are mostly Fake-HDR. However, you can't have HDR without Color
>> Management.
>>
>
>
> https://www.reddit.com/r/linuxquestions/comments/xryg63/does_linux_support_dcip3_or_10_bit/
>
> 
> leo_sk5
> 
> • 8 mo. ago
>
> 10-bit works. You can get DCI-P3 with proper colour profile. Just use x11.
> You probably read about wayland where these are work in progress. Btw,
> linux itself may support 10bit colour, but same can not be said for other
> software that runs on linux.
>
> Just put DefaultDepth 30 in /etc/X11/xorg.conf.d/ (default value would be
> 24). If you also run kde, consider running echo "export
> KWIN_OPENGL_INTERFACE=egl" >~/.config/plasma-workspace/env/use_egl.sh
> also, as kde may crash otherwise. With above changes, 10-bit colour works
> for me in kde
>
> 
>
>
> I wonder how THOSE color profiles look Do you have one? Can you run
> some testing/introspection programs on it?
>

Also

https://github.com/compiz-reloaded/compicc

===

Features

CompICC uses Oyranos to configure the ICC profiles for each monitor. The
order of monitor configuration inside Oyranos is, first look in the Oyranos
DB for a explicit configured ICC profile, if no then scan the installed ICC
profiles for one matching the to be setup device, if not generate on the
fly from the monitors EDID data block, if not try from the Xorg log and as
a last means take sRGB, if not fail miserably ;-)

   - instant desktop colour correction on GPU with compiz
   - multi monitor support
   - ICC Profile in X support
   - X Color Management 0.3 DRAFT1 support
   - EDID -> ICC profile on the fly
   - 16-bit per channel compositing
   - hotplug capable
   - wide gamut monitor calibration
   - support 30-bit monitors

=

I wonder if you ever get better result by using those system-wide methods
.

>
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrew Randrianasulu via Cin]

сб, 27 мая 2023 г., 23:05 Andrea paz :

> I think HDR in Linux is still a long way off. Wayland seems to have
> started working on it these days. Monitors and TVs claimed to be HDR
> are mostly Fake-HDR. However, you can't have HDR without Color
> Management.
>

https://www.reddit.com/r/linuxquestions/comments/xryg63/does_linux_support_dcip3_or_10_bit/


leo_sk5

• 8 mo. ago

10-bit works. You can get DCI-P3 with proper colour profile. Just use x11.
You probably read about wayland where these are work in progress. Btw,
linux itself may support 10bit colour, but same can not be said for other
software that runs on linux.

Just put DefaultDepth 30 in /etc/X11/xorg.conf.d/ (default value would be
24). If you also run kde, consider running echo "export
KWIN_OPENGL_INTERFACE=egl" >~/.config/plasma-workspace/env/use_egl.sh also,
as kde may crash otherwise. With above changes, 10-bit colour works for me
in kde




I wonder how THOSE color profiles look Do you have one? Can you run
some testing/introspection programs on it?
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrea paz via Cin]

I think HDR in Linux is still a long way off. Wayland seems to have
started working on it these days. Monitors and TVs claimed to be HDR
are mostly Fake-HDR. However, you can't have HDR without Color
Management.
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrew Randrianasulu via Cin]

сб, 27 мая 2023 г., 20:20 Andrew Randrianasulu :

>
>
> сб, 27 мая 2023 г., 20:09 Phyllis Smith :
>
>> Certainly merits looking at to see how useful it might be to add.
>>
>
> https://github.com/sekrit-twc/zimg
>
> ah,  c++17! so only new OSes with new compilers will get it 
>


upd: it was only recently-merget cxx17 branch on github, 3.0.4 release
apparently work on older os/compilers ...

https://github.com/sekrit-twc/zimg/releases/tag/release-3.0.4

"checking whether C++ compiler accepts -std=c++14... yes" on gcc 11.2 may
be we can dive deeper in history ...

may be 2.8?

https://src.fedoraproject.org/repo/pkgs/zimg/




>> On Sat, May 27, 2023 at 10:56 AM Andrew Randrianasulu via Cin <
>> cin@lists.cinelerra-gg.org> wrote:
>>
>>> Note there was additional discussion about using zimg/zscale filter in
>>> ffmpeg for getting p3-d65
>>>
>>> https://www.reddit.com/r/ffmpeg/comments/ty9c5k/color_metadata_dcip3/
>>>
>>>
>>> 
>>>
>>>  Zscale does have support for DCI white point P3 and D65 P3.
>>>
>>> ffmpeg -i INPUT.mp4 -c:v libx265 -crf 20 -vf
>>> zscale=r=limited:m=2020_ncl:t=2020_10:p=smpte431:c=topleft,format=yuv420p10
>>> -color_primaries smpte431 -colorspace bt2020nc -color_trc bt2020_10bit
>>> -color_range tv OUTPUT.mp4
>>>
>>>
>>> ===
>>>
>>>
>>> I wonder if such file plays in say mpv as HDR on your display?
>>>
>>> old ffmpeg patches (2016):
>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201962.html
>>>
>>> "vf_colorspace: Add support for smpte 431/432 (dci/display p3)
>>> primaries" but previous 2 patches might be not so trivial ...
>>>
>>>
>>>
>>> https://discuss.pixls.us/t/experimenting-with-hlg-and-hdr10-for-still-images/23361?page=2
>>>
>>> 
>>>
>>> ffmpeg -loop 1 -r 24 -t 30 -i DSC02236.tif -vf
>>> pad=3840:2160:302:0:black,zscale=tin=linear:t=arib-std-b67:npl=800:m=bt2020nc,format=yuv420p10le
>>> -c:v libx265 -preset medium -crf 26 -x265-params
>>> "colorprim=bt2020:atc-sei=18:colormatrix=bt2020nc" naturalbridge.mp4
>>>
>>> 
>>>
>>> zimg2 should be in Debian since late 2021
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966059
>>>
>>> ffmpeg (7:4.3.2-2) experimental; urgency=medium
>>>  .
>>>* debian/:
>>>  - Build with zimg (Closes: #966059 
>>> )
>>>
>>>
>>> I wonder if cingg should add zimg too?
>>>
>>> --
>>> Cin mailing list
>>> Cin@lists.cinelerra-gg.org
>>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>>
>>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Andrew Randrianasulu via Cin]

сб, 27 мая 2023 г., 20:09 Phyllis Smith :

> Certainly merits looking at to see how useful it might be to add.
>

https://github.com/sekrit-twc/zimg

ah,  c++17! so only new OSes with new compilers will get it 

>
> On Sat, May 27, 2023 at 10:56 AM Andrew Randrianasulu via Cin <
> cin@lists.cinelerra-gg.org> wrote:
>
>> Note there was additional discussion about using zimg/zscale filter in
>> ffmpeg for getting p3-d65
>>
>> https://www.reddit.com/r/ffmpeg/comments/ty9c5k/color_metadata_dcip3/
>>
>>
>> 
>>
>>  Zscale does have support for DCI white point P3 and D65 P3.
>>
>> ffmpeg -i INPUT.mp4 -c:v libx265 -crf 20 -vf
>> zscale=r=limited:m=2020_ncl:t=2020_10:p=smpte431:c=topleft,format=yuv420p10
>> -color_primaries smpte431 -colorspace bt2020nc -color_trc bt2020_10bit
>> -color_range tv OUTPUT.mp4
>>
>>
>> ===
>>
>>
>> I wonder if such file plays in say mpv as HDR on your display?
>>
>> old ffmpeg patches (2016):
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201962.html
>>
>> "vf_colorspace: Add support for smpte 431/432 (dci/display p3) primaries"
>> but previous 2 patches might be not so trivial ...
>>
>>
>>
>> https://discuss.pixls.us/t/experimenting-with-hlg-and-hdr10-for-still-images/23361?page=2
>>
>> 
>>
>> ffmpeg -loop 1 -r 24 -t 30 -i DSC02236.tif -vf
>> pad=3840:2160:302:0:black,zscale=tin=linear:t=arib-std-b67:npl=800:m=bt2020nc,format=yuv420p10le
>> -c:v libx265 -preset medium -crf 26 -x265-params
>> "colorprim=bt2020:atc-sei=18:colormatrix=bt2020nc" naturalbridge.mp4
>>
>> 
>>
>> zimg2 should be in Debian since late 2021
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966059
>>
>> ffmpeg (7:4.3.2-2) experimental; urgency=medium
>>  .
>>* debian/:
>>  - Build with zimg (Closes: #966059 
>> )
>>
>>
>> I wonder if cingg should add zimg too?
>>
>> --
>> Cin mailing list
>> Cin@lists.cinelerra-gg.org
>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] HDR footage from images via ffmpeg

[Phyllis Smith via Cin]

Certainly merits looking at to see how useful it might be to add.

On Sat, May 27, 2023 at 10:56 AM Andrew Randrianasulu via Cin <
cin@lists.cinelerra-gg.org> wrote:

> Note there was additional discussion about using zimg/zscale filter in
> ffmpeg for getting p3-d65
>
> https://www.reddit.com/r/ffmpeg/comments/ty9c5k/color_metadata_dcip3/
>
>
> 
>
>  Zscale does have support for DCI white point P3 and D65 P3.
>
> ffmpeg -i INPUT.mp4 -c:v libx265 -crf 20 -vf
> zscale=r=limited:m=2020_ncl:t=2020_10:p=smpte431:c=topleft,format=yuv420p10
> -color_primaries smpte431 -colorspace bt2020nc -color_trc bt2020_10bit
> -color_range tv OUTPUT.mp4
>
>
> ===
>
>
> I wonder if such file plays in say mpv as HDR on your display?
>
> old ffmpeg patches (2016):
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201962.html
>
> "vf_colorspace: Add support for smpte 431/432 (dci/display p3) primaries"
> but previous 2 patches might be not so trivial ...
>
>
>
> https://discuss.pixls.us/t/experimenting-with-hlg-and-hdr10-for-still-images/23361?page=2
>
> 
>
> ffmpeg -loop 1 -r 24 -t 30 -i DSC02236.tif -vf
> pad=3840:2160:302:0:black,zscale=tin=linear:t=arib-std-b67:npl=800:m=bt2020nc,format=yuv420p10le
> -c:v libx265 -preset medium -crf 26 -x265-params
> "colorprim=bt2020:atc-sei=18:colormatrix=bt2020nc" naturalbridge.mp4
>
> 
>
> zimg2 should be in Debian since late 2021
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966059
>
> ffmpeg (7:4.3.2-2) experimental; urgency=medium
>  .
>* debian/:
>  - Build with zimg (Closes: #966059 
> )
>
>
> I wonder if cingg should add zimg too?
>
> --
> Cin mailing list
> Cin@lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin