[Cin] "color hell"

Tue Jul 20 02:33:46 CEST 2021

rebased on top of this )

On Tuesday, July 20, 2021, Phyllis Smith <phylsmith2017 at gmail.com> wrote:

> These changes as provided by Andrew have been checked into GIT (finally!
> finished testing and checking):
>
> 0003-Attempt-at-differenciating-601-pal-and-ntsc.patch
> 0004-Fix-yuv_color_space-menu-after-adding-bt601-variants.patch
> 0005-Add-comment-about-order-of-array-entries-for-yuv_col.patch
> 0006-Forgot-to-alter-colorspace-plugin-for-bt2020-split.patch
> 0006-Slightly-enlarge-colirspace-menu-width.patch
> 0007-Attempt-at-differenciating-bt2020-ncl-vs-bt2020-cl.patch
> 0056-Add-simple-validation-for-yuv_color_space-prevent-cr.patch
> 0057-Add-two-more-checks-for-Cinelerra_rc-loading.patch
>
> Or in randrik9 tar from Jul 17th:
>
> 0041-Attempt-at-differenciating-601-pal-and-ntsc.patch
> 0042-Fix-yuv_color_space-menu-after-adding-bt601-variants.patch
> 0043-Add-comment-about-order-of-array-entries-for-yuv_col.patch
> 0044-Slightly-enlarge-colirspace-menu-width.patch
> 0045-Attempt-at-differenciating-bt2020-ncl-vs-bt2020-cl.patch
> 0046-Forgot-to-alter-colorspace-plugin-for-bt2020-split.patch
> +
> +
>
>
>
>
>
> On Sun, Jul 18, 2021 at 5:20 PM Andrew Randrianasulu <
> randrianasulu at gmail.com> wrote:
>
>>
>>
>> On Monday, July 19, 2021, Andrew Randrianasulu <randrianasulu at gmail.com>
>> wrote:
>>
>>> try this patch, it should preven crash in patched cin if you manually or
>>> programmatically set yuv_color_space to number cin does not recognize (but
>>> I am afraid iriginal cingg also can be crashed by just manually editing
>>> Cinelerra_rc and setting this (or even some similar) line to wrong value..
>>> some generic validation pass nedded for preventing this..)
>>
>>
>>
>>  two more checks for color range and vicon colors... apply on top of 0056
>> (I forgot to decrement index by 1 so it was not crashing on yuv_color_space
>> 5, but this was illegal value)
>>
>> if this specific vulnerability not mentioned yet in manul - I think it
>> deserves line or two.. (randomly editing Cinelerra_rc easily result in
>> crash at access...)
>>
>>
>>
>>> On Monday, July 19, 2021, Andrew Randrianasulu <randrianasulu at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Monday, July 19, 2021, Phyllis Smith <phylsmith2017 at gmail.com>
>>>> wrote:
>>>>
>>>>> More testing of "color hell" has been completed here
>>>>> I "think" that I have tested enough to check this into GIT, as long as
>>>>> users can tolerate the following that have workarounds:
>>>>> There are 2 problems that occur when going back to a previous
>>>>> Cinelerra version:
>>>>>    1) if you set YUV Color Space to 601_PAL and save settings and then
>>>>> load in a previous version, it crashes.
>>>>>
>>>>
>>>> ow, this is bad (
>>>>
>>>> probably this array I expanded in patch overflows...
>>>>
>>>>
>>>>>    2) if you set YUV Color Space to 2020_CL and save settings and then
>>>>> load in a previous version, the Color Space will report either "Low" or
>>>>> "JPEG"
>>>>>
>>>>
>>>>
>>>> hm, something steps on someone's else toes..
>>>>
>>>> not sure if it really desirable to merge in such state, may be I'll
>>>> find way to move few fields around first..
>>>>
>>>>>
>>>>> On Sat, Jul 17, 2021 at 12:47 PM Andrew Randrianasulu <
>>>>> randrianasulu at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Saturday, July 17, 2021, Phyllis Smith <phylsmith2017 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Andrew,
>>>>>>> Sorry but I have not found any difference between 601 Pal and 601
>>>>>>> NTSC other than what ffprobe reports.  The video looks 100% identical.
>>>>>>> Perhaps I am doing something wrong.  Here is what I did:
>>>>>>>
>>>>>>> 1) downloaded Cows 4k.webm (do not remember exact name)
>>>>>>> 2) deleted most of it so it does not take so long to render
>>>>>>> 3) set Format to YUV-8
>>>>>>> 4) set Preferences/Appearances/YUV color space to 601 NTSC
>>>>>>> 5) render using h2674.mp4
>>>>>>> ...6) Then reloaded shortened Cows, set Format to YUV-8 and color
>>>>>>> space to 601 PAL, rendered.
>>>>>>> 7) ran ydiff on the 2 output videos and the result is that the video
>>>>>>> is 100% the same
>>>>>>> 8) ffprobe does report smpte170m (for NTSC) ersus bt470bg (for PAL)
>>>>>>>
>>>>>>> So I am either doing something wrong, or splitting 601 and 2020 is
>>>>>>> just not relevant.  I have to do another 2020 split test yet.
>>>>>>>
>>>>>>
>>>>>> may be player/nle supposed to alter video depending on those tags? so
>>>>>> it will be visible not in encoded file but after full decoding + display IF
>>>>>> player reacts correctly to those attribs (many do not care)
>>>>>>
>>>>>>
>>>>>>> Also, when I load one of the output files in a previous version of
>>>>>>> Cinelerra without the mod, the Color Space comes up as "low" -- where that
>>>>>>> came from I have no idea.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> i altered not just encoding part but also decoding/internal
>>>>>> colorspace conversion paths - because original code does so... so different
>>>>>> reactions to same input kinda expected?
>>>>>>
>>>>>> may be you can put my patches in separate branch, incl. other
>>>>>> 'staging' patches (termux, h265-multilib, exr batchrender...)? so they will
>>>>>> be available easily yet not interfere with main branch yet...
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Wed, Jul 14, 2021 at 12:47 PM Andrew Randrianasulu <
>>>>>>> randrianasulu at gmail.com> wrote:
>>>>>>>
>>>>>>>> I made those commits into new series,  you probably want to rename
>>>>>>>> this to 0009-*.patch... I do not think old 0008 patch will do any good -
>>>>>>>> GReen-BLue-REd planar float format is not something Cin easily can convert
>>>>>>>> for internal use (I saw similar comment in oiio sources... I am not good
>>>>>>>> enough for adding even simple format to ffmpeg/swscale.. even with already
>>>>>>>> written examples)
>>>>>>>>
>>>>>>>> from
>>>>>>>>
>>>>>>>> https://github.com/OpenImageIO/oiio/blob/master/src/ffmpeg.imageio/
>>>>>>>> ffmpeginput.cpp
>>>>>>>>
>>>>>>>> case AV_PIX_FMT_GBRPF32BE:
>>>>>>>>     case AV_PIX_FMT_GBRPF32LE:
>>>>>>>>         nchannels = 3;
>>>>>>>>         datatype = TypeFloat;
>>>>>>>>         m_dst_pix_format = AV_PIX_FMT_RGB48; // ? AV_PIX_FMT_GBRPF32
>>>>>>>>         // FIXME: They don't have a type for RGB float, only GBR
>>>>>>>> float.
>>>>>>>>         // Yuck. Punt for now and save as uint16 RGB. If people
>>>>>>>> care, we
>>>>>>>>         // can return and ask for GBR float and swap order.
>>>>>>>>         break;
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wednesday, July 14, 2021, Andrea paz <
>>>>>>>> gamberucci.andrea at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I tried to compile with the two patches 0007 and 0008, but the
>>>>>>>>> compilation gives an error. I append the cin5.log, if it helps.
>>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20210720/d69b9ae6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: randrik10.tar.gz
Type: application/gzip
Size: 57146 bytes
Desc: not available
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20210720/d69b9ae6/attachment-0001.bin>