- Cin - Cinelerra-GG Mailing Lists

Re: [Cin] Colour profiles in photo
by Andrew Randrianasulu 06 Aug '22

06 Aug '22

пт, 5 авг. 2022 г., 20:05 Einar Rünkaru <einarrunkaru(a)gmail.com>: > > > On 05/08/2022 08:08, Andrew Randrianasulu wrote: > > > > > > чт, 4 авг. 2022 г., 14:36 Andrew Randrianasulu <randrianasulu(a)gmail.com > > <mailto:randrianasulu@gmail.com>>: > > > > https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html > > <https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html> > > > > > > It seems not all icc profiles are the same ... > > Conversion from one profile to another may be done different ways. > Well, I was amazed by existence of unbounded mode (where values can be less than zero or more than 1.0) but I guess Cinelerra not ready for this ) Also, I was surprized there is more than one method for describing those tone curves ... > > Profiles are of course not the same > https://www.color.org/version4html.xalter > > > > > > I think for cin-gg it makes sense converting from biggest rgba-float > > (32 bit floating point value per color channel) , and for CVE from > > 16 bit/channel int format .... (I think back in time Adam deleted > > int 16 formats from Cinelerra 2.0 as opposed to cin 1.2 saying they > > were not as good as true 32 fp) > > 32 bit fp is not 32 bits - it has only 24 significant bits. Fp pixel > value is 0 <= value < 1. > Yeah, thanks for correction > > > I put some emphasis on opengl output because it offloads some of > > per-pixel math to graphics hw, but slower sw only mode probably will > > work as proof of concept. > > > > As far as I understand you even can have colord daemon monitoring > > hot-plugged output devices incl. monitors and providing associated > > profile via some api (?) yet I only compiled it and newer used ... > > > > It seems at least two display pathes needed, one for traditional 8 > > bit displays and another for newer 10 bit ones. i thought because > > color profiles known and used ever since 1996 or so, 8 bit output > > can be done first .. > > > > I'll try to find simpler lcms2 examples ... > > Cin should detect the output device and select appropriate conversion > > > > > > > > > > Does this example count as useful tutorial? > > > > > https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-thro… > > < > https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-thro… > > > > > > It uses rgb to cmyk and two profiles, but hopefully one just can call > > this with one real and one built-in profile? It was nice to know you can > > do scanlines with lcms, too .... > > Looks reasonable > ---- Also, littecms pdf documentation in doc folder says you can use same buffer for input and output as long as its organization remain the same ... --- Scanline overlap It is safe to use same block for input and output, but only if the input and output are coded in same format. For example, you can safely use only one buffer for RGB to RGB but you cannot use same buffer for RGB as input and CMYK as output. --- > > > > > > I also was reading ninedegreesbelow.com <http://ninedegreesbelow.com> > > articles on color spaces and it seems some of our trouble with blend > > modes with text and fades caused by (missing?) linearization, see > > > > https://ninedegreesbelow.com/photography/test-for-linear-processing.html > > < > https://ninedegreesbelow.com/photography/test-for-linear-processing.html> > > > > I did some hack for normal blend mode using code from stackoverflow and > > code posted in our bugzilla > > > > See > > https://www.cinelerra-gg.org/bugtracker/view.php?id=559 > > <https://www.cinelerra-gg.org/bugtracker/view.php?id=559> > > There are broken links - not very useful. > Sorry, most likely gmail client on Android not very like copy pasted links.... > If I understand right, the problem is related to alpha. When you mix one > frame with frame with shaped alpha, the second frame "cuts" itself into > the first. The result may be unexpected. > > > > So, in theory this (fast) linearization step should be added to all > > modes, or at image-reading stage only? > > My idea is that video/image loading converts to internal format > including linearization. What is mode? > If I look at right place native png reader outputs into rgb(a)8 or rgb(a)16 .. int FilePNG::colormodel_supported(int colormodel) { if( colormodel == BC_RGB888 || colormodel == BC_RGBA8888 ) return colormodel; if( colormodel == BC_RGB161616 && native_cmodel == BC_RGBA161616 return colormodel; if( native_cmodel >= 0 ) return native_cmodel; int use_16bit = BC_CModels::is_float(colormodel) || BC_CModels::calculate_max(colormodel) > 255 ? 1 : 0; return BC_CModels::has_alpha(colormodel) ? (use_16bit ? BC_RGBA16161616 : BC_RGBA8888) : (use_16bit ? BC_RGB161616 : BC_RGB888); } No specific icc handling ... I guess ffmpeg png reader also was dropping icc profile info until very recently .... > > > Also, good way to put lcms transform code in our rgb2rgb function > > (somewhere in guicast? ..but in cingg some of this code python-generated > > and I do not know python at all ..), just with additional parameters > > like pointer to in and out profiles? If any of them null then just not > > execute transform call ... > > > I don't know python too. > I think I found point where new function can be inserted for display: vdevicex11 In function VDeviceX11::write_buffer(VFrame *output_channels, EDL *edl) // printf("VDeviceX11::write_buffer %d output_channels=%p\n", __LINE__, output_channels); // printf("VDeviceX11::write_buffer %d input color_model=%d output color_model=%d\n", // __LINE__, output_channels->get_color_model(), bitmap->get_color_model()); if( bitmap->hardware_scaling() ) { BC_CModels::transfer(bitmap->get_row_pointers(), output_channels->get_rows(), 0, 0, 0, output_channels->get_y(), output_channels->get_u(), output_channels->get_v(), 0, 0, output_channels->get_w(), output_channels->get_h(), 0, 0, bitmap->get_w(), bitmap->get_h(), output_channels->get_color_model(), bitmap->get_color_model(), -1, output_channels->get_w(), bitmap->get_w()); } else { BC_CModels::transfer(bitmap->get_row_pointers(), output_channels->get_rows(), 0, 0, 0, output_channels->get_y(), output_channels->get_u(), output_channels->get_v(), (int)output_x1, (int)output_y1, (int)(output_x2 - output_x1), (int)(output_y2 - out 0, 0, (int)(canvas_x2 - canvas_x1), (int)(canvas_y2 - canvas_y1), output_channels->get_color_model(), bitmap->get_color_model(), -1, output_channels->get_w(), bitmap->get_w()); } So bitmap->get_row_pointers() can be used as buffer argument for cms* functions? I ignore direct mode above for now ... For initial experiments even just hardcoded path to monitor profile should be enough to see difference and experience speed lost? And for encoding this profile into media/file 'asset' structure must be altered first to hold icc profile type from lcms2.h and then encoder functions should look if there attached profile and pass it to libacvodec/libavformat ... > > > > > Adding profile to some video container hopefully will be not very > > hard task (i forgot about this patch for ffmpeg's mov muxer from > > 2019 i talked about in cingg bug ...) > > > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/250398.html > > <http://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/250398.html> > > This patch is applied. > Thanks for checking! > > > > > > Input side hopefully already covered by ffmpeg.git patches (input > > image format icc profile only should matter at decompressing into > > some pixel array? Because further processing will alter those pixels > > ...or I am wrong and input media profiles must be somewhat combined > > during track compositing?) > > > > You have to select the best internal format or you have to change and > test 6 x N paths in every effect. N is in hundreds. > But then is there any sense in making profile-based transfer functions to be available for rest of cinelerra, like in cingg's case guicast/bcxfer.C place? (Where BC_CModels::transfer currently defined ) > Einar >

1 0

Colour profiles in photo
by Andrew Randrianasulu 05 Aug '22

05 Aug '22

https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html It seems not all icc profiles are the same ... I think for cin-gg it makes sense converting from biggest rgba-float (32 bit floating point value per color channel) , and for CVE from 16 bit/channel int format .... (I think back in time Adam deleted int 16 formats from Cinelerra 2.0 as opposed to cin 1.2 saying they were not as good as true 32 fp) I put some emphasis on opengl output because it offloads some of per-pixel math to graphics hw, but slower sw only mode probably will work as proof of concept. As far as I understand you even can have colord daemon monitoring hot-plugged output devices incl. monitors and providing associated profile via some api (?) yet I only compiled it and newer used ... It seems at least two display pathes needed, one for traditional 8 bit displays and another for newer 10 bit ones. i thought because color profiles known and used ever since 1996 or so, 8 bit output can be done first .. I'll try to find simpler lcms2 examples ... Adding profile to some video container hopefully will be not very hard task (i forgot about this patch for ffmpeg's mov muxer from 2019 i talked about in cingg bug ...) Input side hopefully already covered by ffmpeg.git patches (input image format icc profile only should matter at decompressing into some pixel array? Because further processing will alter those pixels ...or I am wrong and input media profiles must be somewhat combined during track compositing?)

1 1

Re: [Cin] Colors tip from forum
by Andrew Randrianasulu 02 Aug '22

02 Aug '22

вт, 2 авг. 2022 г., 20:10 Einar Rünkaru <einarrunkaru(a)gmail.com>: > Hi. > > On 02/08/2022 11:37, Andrea paz wrote: > > > Thanks for the responses; glad to hear from you again. > > In the CVE readme you mention the internal 16-bit color model. Since > > you remain the only deep Cinelerra expert (besides Adam, with whom it > > is difficult to interact), may I ask you to explain how color works in > > Cinelerra? Is it converted continuously as needed? > > Video is decoded to internal representation (look at settings/format). > Internal format is unpacked 3..4 values every pixel. CVE has only > RGBA-16 and AYUV-16 pixel formats. All values are 16 bit. > > CVO (and probably CGG) have 6 internal pixel formats (8-bit and float) > > > Does each plugin > > make the conversions it needs? > > All plugins see the frames only in internal format and modify this as > needed. > > > What do the color model settings affect > > and what are they affected by? > > Color model describes internal pixel format > > > Is it possible to implement ICC > > profiles? > > Probably. How? > Good question. I was looking into mplayer2's code for display part https://github.com/astiob/mplayer2/blob/all/libvo/vo_gl3.c Then I found news from yesteryear about lcms2 plugin https://littlecms.com/plugin/ "Little CMS floating point plug-in accelerates 8 bit and floating point color transforms, ".." The speedup is accomplished by implementing new interpolation kernels, adding optimizations and re-arranging memory layouts. Additionally, it can use SIMD instructions if present." Then there is new infrastructure in ffmpeg git: http://ffmpeg.org/pipermail/ffmpeg-devel/2022-July/299438.html https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/61ffa23c2e42887b32d469d9e69… "avcodec/codec_internal: add cap for ICC profile support" As far as I understand it only works with webp, tiff, png and mjpeg as video format but hopefully can be extended in future? > > In short, I am not clear about anything related to color > > treatment in Cinelerra. This is an issue that we have been dragging > > around for years (for example see the thread: > > > https://www.cinelerra-gg.org/forum/help-video/yuv-to-rgb-conversion-issues/ > ) > > but the confusion is total and we can't figure it out. > > Few mentions were made many years ago: > > https://lists.cinelerra-cv.org/pipermail/cinelerra/2018q4/009903.html > > https://www.mail-archive.com/cinelerra@skolelinux.no/msg13761.html > > Original Cinelerra does not care about colorspaces. It uses what comes > out from decoder. Some effects work differenlly depending on colorspace. > Sometimes pixel values are converted to float, sometimes to 8-bit for an > effect. Fixing it takes couple of man-years. > > CVE converts color to full-scale (0..65565). All effects work with full > scale values. Encoding converts to colorspace required by the codec. > > Einar > > PS Removed CinGG ML - it does not accept my mails - I am not subscribed. > > >

1 0

Re: [Cin] Colors tip from forum
by Andrea paz 02 Aug '22

02 Aug '22

> The purpose of the plugin was to compare different color conversion > routines for testing. > The test is moved now to "Video Tests" plugin. Less confusion. > Einar Thanks for the responses; glad to hear from you again. In the CVE readme you mention the internal 16-bit color model. Since you remain the only deep Cinelerra expert (besides Adam, with whom it is difficult to interact), may I ask you to explain how color works in Cinelerra? Is it converted continuously as needed? Does each plugin make the conversions it needs? What do the color model settings affect and what are they affected by? Is it possible to implement ICC profiles? In short, I am not clear about anything related to color treatment in Cinelerra. This is an issue that we have been dragging around for years (for example see the thread: https://www.cinelerra-gg.org/forum/help-video/yuv-to-rgb-conversion-issues/) but the confusion is total and we can't figure it out. Few mentions were made many years ago: https://lists.cinelerra-cv.org/pipermail/cinelerra/2018q4/009903.html https://www.mail-archive.com/cinelerra@skolelinux.no/msg13761.html

1 0

Re: [Cin] Colors tip from forum
by Andrea paz 01 Aug '22

01 Aug '22

> There was not fully implemented and disabled feature like this. It was > removed in commit "Removed unused dynamic folders feature from resources > window" (27 Dec 2013). > > Einar Hi, thanks for the info. I can't find the commit on git. May I ask why you removed The ColorSpace plugin from CVE? Is it not working well?

1 0

July release of AppImages
by Phyllis Smith 31 Jul '22

31 Jul '22

The AppImages for July are now available at: https://cinelerra-gg.org/download/images/ Unfortunately, the upgrade of OpenEXR as credited to Manuel V can not be done because I struggled and struggled to find a way to use "without-openexr" to also exclude Imath and could not find a way even tried checking cmake version to exclude and it still uses "forced" for Imath. I do not want to prevent older distrros having "cmake" lower than the required 3.12 from building; as long as they can build correctly "without-openexr'". Hopefully, a solution is still viable. Next following the work of Andrew and testing by Andrea will be testing the FFmpeg 5.1 upgrade. ********************************************************************************************************** *GIT for Cinelerra-GG has the following changes from 07/01/2022-07/31/2022* Library upgrades for the following: Libaom to 3.4.0 from 3.2.0 Libvpx to 1.12.0 from 1.11.0 Minor patches to configure.ac for needed configuration changes by Andrew.

1 0

Colors tip from forum
by Andrea paz 31 Jul '22

31 Jul '22

>From this post by DeJay: https://www.cinelerra-gg.org/forum/help-video/yuv-to-rgb-conversion-issues/… I added the example in the manual. I attach the changes. See if it is okay.

3 11

Checked into GIT updated libraries
by Phyllis Smith 29 Jul '22

29 Jul '22

As Andrew provided patch updates and I checked on older versions of O/S (Ubuntu 16 and 32-bit Debian 9.1) the following have been updated: libaom-v3.4.0 (from v3.2.0) libvpx-1.12.0 (from 1.11.0) Be aware that if you switch back and forth between an older and newer version BE SURE TO "rebuild index" on you media file or you will see weirdness like I did because the rendered file is a different size between the old library version and the new library version. This will not be a problem for most people - probably just testers who use the same file names (like I always do!) Also, note that I will try to remember to "Credit" the comment in Git with the author because someone noted that that was not being done in Git. I had always put it in the Releasenotes.pdf as the appropriate place because seen by more people. Only programmers or users who do their own builds ever look at Git, but many more people look at the release notes because they want to see whether or not it is necessary to update to the latest release. So for example this latest checkin has the comment of: "Credit libaom/libvpx teams and Andrew patch update" You can stop reading this now, but I have to say in my defense on this Git oversite is that Git was created by Linus Torvalds (in Europe so was not known in the United States right away) in the year 2005. Although that was 17 years ago, it was not even available during our professional working years where we started out with Control Data Corporation and Cray mainframe computers. So basically the common consensus on the "proper" use of Git checkins is not even on my radar. End of rant!

3 6

External folder with cingg patches
by Andrew Randrianasulu 26 Jul '22

26 Jul '22

Due to massive lib updates patches weight 23 mb! https://cloud.mail.ru/public/xZGW/K8FctMtP3 (Note, I tried to update mpegts muxer using my earlier single.diff from May, 5th - for encoding you need to modify bluray profile ...)

2 1

Fwd: X265 aarch64 patch
by Andrew Randrianasulu 25 Jul '22

25 Jul '22

Actual patch from https://github.com/Vargol/ffmpeg-apple-arm64-build Found via https://bitbucket.org/multicoreware/x265_git/issues/563/patch-neon-arm64-im… ---------- Forwarded message --------- От: Andrew Randrianasulu <randrianasulu(a)gmail.com> Date: сб, 23 июл. 2022 г., 22:40 Subject: X265 aarch64 patch To: <cin-request(a)lists.cinelerra-gg.org> Can you check attached patch on aarch64? Without it static build of x265 fails on my new aarch64 termux .. Put in thirdparty/src I also trying to make libvpx/libaom update, but while libvpx 1.12 can be put as is with patch files simply renamed libaom 3.4.0 need some manual work .. Also, ffmpeg 5.1 is out !

3 2