https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu... this was answered like this === copy === hTransform = cmsCreateTransform(hInProfile, TYPE_CMYK_8, hOutProfile, TYPE_ARGB_8, // ARGB is most likely for QImage INTENT_PERCEPTUAL, 0); uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) uchar *out = outImage->bits(); cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb)); === official article show bigger switch https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/ /** * Convert from Qt format to lcms2 format */ static cmsUInt32Number toLcmsFormat(QImage::Format fmt) { switch (fmt) { case QImage::Format_ARGB32: // (0xAARRGGBB) case QImage::Format_RGB32: // (0xffRRGGBB) return TYPE_BGRA_8; case QImage::Format_RGB888: return TYPE_RGB_8; // 24-bit RGB format (8-8-8). case QImage::Format_RGBX8888: case QImage::Format_RGBA8888: return TYPE_RGBA_8; case QImage::Format_Grayscale8: return TYPE_GRAY_8; case QImage::Format_Grayscale16: return TYPE_GRAY_16; case QImage::Format_RGBA64: case QImage::Format_RGBX64: return TYPE_RGBA_16; case QImage::Format_BGR888: return TYPE_BGR_8; default: return 0; } } so I think we can add support for rgb8 timeline format at least, in same place where swscale call done in our ffmpeg.C in ffmpeg we have libavfilter/vf_iccdetect.c #include <lcms2.h> const AVFrameSideData *sd; cmsHPROFILE profile; sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size); cmsCloseProfile(profile); Full documentation in pdf form https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf TYPE_RGB_FLT/TYPE_RGBA_FLT exist in /usr/include/lcms2.h so rgba-float should be supportable too. I'll try to write easy detect part for configure first.
I tried to stuff cmsDoTransform into our ffmpeg.C but it does not work :( as in, it does not even come to this newly added block ... does not print colormodel or "cms!" line On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu...
this was answered like this
=== copy ===
hTransform = cmsCreateTransform(hInProfile, TYPE_CMYK_8, hOutProfile, TYPE_ARGB_8, // ARGB is most likely for QImage INTENT_PERCEPTUAL, 0);
uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) uchar *out = outImage->bits();
cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb));
===
official article show bigger switch
https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/
/** * Convert from Qt format to lcms2 format */ static cmsUInt32Number toLcmsFormat(QImage::Format fmt) { switch (fmt) { case QImage::Format_ARGB32: // (0xAARRGGBB) case QImage::Format_RGB32: // (0xffRRGGBB) return TYPE_BGRA_8;
case QImage::Format_RGB888: return TYPE_RGB_8; // 24-bit RGB format (8-8-8).
case QImage::Format_RGBX8888: case QImage::Format_RGBA8888: return TYPE_RGBA_8;
case QImage::Format_Grayscale8: return TYPE_GRAY_8;
case QImage::Format_Grayscale16: return TYPE_GRAY_16;
case QImage::Format_RGBA64: case QImage::Format_RGBX64: return TYPE_RGBA_16;
case QImage::Format_BGR888: return TYPE_BGR_8;
default: return 0;
} }
so I think we can add support for rgb8 timeline format at least, in same place where swscale call done in our ffmpeg.C
in ffmpeg we have
libavfilter/vf_iccdetect.c
#include <lcms2.h> const AVFrameSideData *sd; cmsHPROFILE profile;
sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size);
cmsCloseProfile(profile);
Full documentation in pdf form
https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf
TYPE_RGB_FLT/TYPE_RGBA_FLT exist in /usr/include/lcms2.h
so rgba-float should be supportable too.
I'll try to write easy detect part for configure first.
ah, it "worked" I just need to set "ffmpeg first" (I switched away from it for testing) But I still can't see difference? On Sat, May 2, 2026 at 9:30 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I tried to stuff cmsDoTransform into our ffmpeg.C but it does not work :(
as in, it does not even come to this newly added block ... does not print colormodel or "cms!" line
On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu...
this was answered like this
=== copy ===
hTransform = cmsCreateTransform(hInProfile, TYPE_CMYK_8, hOutProfile, TYPE_ARGB_8, // ARGB is most likely for QImage INTENT_PERCEPTUAL, 0);
uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) uchar *out = outImage->bits();
cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb));
===
official article show bigger switch
https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/
/** * Convert from Qt format to lcms2 format */ static cmsUInt32Number toLcmsFormat(QImage::Format fmt) { switch (fmt) { case QImage::Format_ARGB32: // (0xAARRGGBB) case QImage::Format_RGB32: // (0xffRRGGBB) return TYPE_BGRA_8;
case QImage::Format_RGB888: return TYPE_RGB_8; // 24-bit RGB format (8-8-8).
case QImage::Format_RGBX8888: case QImage::Format_RGBA8888: return TYPE_RGBA_8;
case QImage::Format_Grayscale8: return TYPE_GRAY_8;
case QImage::Format_Grayscale16: return TYPE_GRAY_16;
case QImage::Format_RGBA64: case QImage::Format_RGBX64: return TYPE_RGBA_16;
case QImage::Format_BGR888: return TYPE_BGR_8;
default: return 0;
} }
so I think we can add support for rgb8 timeline format at least, in same place where swscale call done in our ffmpeg.C
in ffmpeg we have
libavfilter/vf_iccdetect.c
#include <lcms2.h> const AVFrameSideData *sd; cmsHPROFILE profile;
sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size);
cmsCloseProfile(profile);
Full documentation in pdf form
https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf
TYPE_RGB_FLT/TYPE_RGBA_FLT exist in /usr/include/lcms2.h
so rgba-float should be supportable too.
I'll try to write easy detect part for configure first.
aww, forgot to check if side data exist ... It crashes if I load file _without_ such side data, so in a sense it detect such files correctly? On Sat, May 2, 2026 at 9:48 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
ah, it "worked"
I just need to set "ffmpeg first" (I switched away from it for testing)
But I still can't see difference?
On Sat, May 2, 2026 at 9:30 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I tried to stuff cmsDoTransform into our ffmpeg.C but it does not work :(
as in, it does not even come to this newly added block ... does not print colormodel or "cms!" line
On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu...
this was answered like this
=== copy ===
hTransform = cmsCreateTransform(hInProfile, TYPE_CMYK_8, hOutProfile, TYPE_ARGB_8, // ARGB is most likely for QImage INTENT_PERCEPTUAL, 0);
uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) uchar *out = outImage->bits();
cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb));
===
official article show bigger switch
https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/
/** * Convert from Qt format to lcms2 format */ static cmsUInt32Number toLcmsFormat(QImage::Format fmt) { switch (fmt) { case QImage::Format_ARGB32: // (0xAARRGGBB) case QImage::Format_RGB32: // (0xffRRGGBB) return TYPE_BGRA_8;
case QImage::Format_RGB888: return TYPE_RGB_8; // 24-bit RGB format (8-8-8).
case QImage::Format_RGBX8888: case QImage::Format_RGBA8888: return TYPE_RGBA_8;
case QImage::Format_Grayscale8: return TYPE_GRAY_8;
case QImage::Format_Grayscale16: return TYPE_GRAY_16;
case QImage::Format_RGBA64: case QImage::Format_RGBX64: return TYPE_RGBA_16;
case QImage::Format_BGR888: return TYPE_BGR_8;
default: return 0;
} }
so I think we can add support for rgb8 timeline format at least, in same place where swscale call done in our ffmpeg.C
in ffmpeg we have
libavfilter/vf_iccdetect.c
#include <lcms2.h> const AVFrameSideData *sd; cmsHPROFILE profile;
sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size);
cmsCloseProfile(profile);
Full documentation in pdf form
https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf
TYPE_RGB_FLT/TYPE_RGBA_FLT exist in /usr/include/lcms2.h
so rgba-float should be supportable too.
I'll try to write easy detect part for configure first.
Ok, I tried to add env. variable for profile but it still does not work ? CIN_CM_PROFILE=/usr/share/color/icc/colord/ProPhotoRGB.icc bin/cin /dev/shm/R2020-P3-color-bars.png as in, it just show same picture! On Sat, May 2, 2026 at 9:59 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
aww, forgot to check if side data exist ... It crashes if I load file _without_ such side data, so in a sense it detect such files correctly?
On Sat, May 2, 2026 at 9:48 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
ah, it "worked"
I just need to set "ffmpeg first" (I switched away from it for testing)
But I still can't see difference?
On Sat, May 2, 2026 at 9:30 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I tried to stuff cmsDoTransform into our ffmpeg.C but it does not work :(
as in, it does not even come to this newly added block ... does not print colormodel or "cms!" line
On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu...
this was answered like this
=== copy ===
hTransform = cmsCreateTransform(hInProfile, TYPE_CMYK_8, hOutProfile, TYPE_ARGB_8, // ARGB is most likely for QImage INTENT_PERCEPTUAL, 0);
uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) uchar *out = outImage->bits();
cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb));
===
official article show bigger switch
https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/
/** * Convert from Qt format to lcms2 format */ static cmsUInt32Number toLcmsFormat(QImage::Format fmt) { switch (fmt) { case QImage::Format_ARGB32: // (0xAARRGGBB) case QImage::Format_RGB32: // (0xffRRGGBB) return TYPE_BGRA_8;
case QImage::Format_RGB888: return TYPE_RGB_8; // 24-bit RGB format (8-8-8).
case QImage::Format_RGBX8888: case QImage::Format_RGBA8888: return TYPE_RGBA_8;
case QImage::Format_Grayscale8: return TYPE_GRAY_8;
case QImage::Format_Grayscale16: return TYPE_GRAY_16;
case QImage::Format_RGBA64: case QImage::Format_RGBX64: return TYPE_RGBA_16;
case QImage::Format_BGR888: return TYPE_BGR_8;
default: return 0;
} }
so I think we can add support for rgb8 timeline format at least, in same place where swscale call done in our ffmpeg.C
in ffmpeg we have
libavfilter/vf_iccdetect.c
#include <lcms2.h> const AVFrameSideData *sd; cmsHPROFILE profile;
sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size);
cmsCloseProfile(profile);
Full documentation in pdf form
https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf
TYPE_RGB_FLT/TYPE_RGBA_FLT exist in /usr/include/lcms2.h
so rgba-float should be supportable too.
I'll try to write easy detect part for configure first.
I think this one works (at rgba8 only for now) at least it shows some difference between srb and prophoto jpegs now and between R2020-P3 png in rgb8 (no cms) and rgba8 (cms) modes On Sat, May 2, 2026 at 11:20 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
Ok, I tried to add env. variable for profile but it still does not work ?
CIN_CM_PROFILE=/usr/share/color/icc/colord/ProPhotoRGB.icc bin/cin /dev/shm/R2020-P3-color-bars.png
as in, it just show same picture!
On Sat, May 2, 2026 at 9:59 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
aww, forgot to check if side data exist ... It crashes if I load file _without_ such side data, so in a sense it detect such files correctly?
On Sat, May 2, 2026 at 9:48 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
ah, it "worked"
I just need to set "ffmpeg first" (I switched away from it for testing)
But I still can't see difference?
On Sat, May 2, 2026 at 9:30 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I tried to stuff cmsDoTransform into our ffmpeg.C but it does not work :(
as in, it does not even come to this newly added block ... does not print colormodel or "cms!" line
On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu...
this was answered like this
=== copy ===
hTransform = cmsCreateTransform(hInProfile, TYPE_CMYK_8, hOutProfile, TYPE_ARGB_8, // ARGB is most likely for QImage INTENT_PERCEPTUAL, 0);
uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) uchar *out = outImage->bits();
cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb));
===
official article show bigger switch
https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/
/** * Convert from Qt format to lcms2 format */ static cmsUInt32Number toLcmsFormat(QImage::Format fmt) { switch (fmt) { case QImage::Format_ARGB32: // (0xAARRGGBB) case QImage::Format_RGB32: // (0xffRRGGBB) return TYPE_BGRA_8;
case QImage::Format_RGB888: return TYPE_RGB_8; // 24-bit RGB format (8-8-8).
case QImage::Format_RGBX8888: case QImage::Format_RGBA8888: return TYPE_RGBA_8;
case QImage::Format_Grayscale8: return TYPE_GRAY_8;
case QImage::Format_Grayscale16: return TYPE_GRAY_16;
case QImage::Format_RGBA64: case QImage::Format_RGBX64: return TYPE_RGBA_16;
case QImage::Format_BGR888: return TYPE_BGR_8;
default: return 0;
} }
so I think we can add support for rgb8 timeline format at least, in same place where swscale call done in our ffmpeg.C
in ffmpeg we have
libavfilter/vf_iccdetect.c
#include <lcms2.h> const AVFrameSideData *sd; cmsHPROFILE profile;
sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size);
cmsCloseProfile(profile);
Full documentation in pdf form
https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf
TYPE_RGB_FLT/TYPE_RGBA_FLT exist in /usr/include/lcms2.h
so rgba-float should be supportable too.
I'll try to write easy detect part for configure first.
So, i think this one adds lcms2 compile guards so should work in addition to another patch 0001-lcms2-configure-support-for-internal-ffmpeg.patch added all 3 as attaches. Usage CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" bin/cin /dev/shm/gradient\ *.jpg without cin_CM_PROFILE there should be no difference in both tracks with it srgb track should have much muted colors (or if you use sRGB profile ProPhoto one must be much brighter.) Works only with rbga8 project profile, ffmpeg input. May not work at playback, but works at rendering and stop frame in compositor. Timeline/miniatures not color manged On Sat, May 2, 2026 at 8:31 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I think this one works (at rgba8 only for now)
at least it shows some difference between srb and prophoto jpegs now
and between R2020-P3 png in rgb8 (no cms) and rgba8 (cms) modes
On Sat, May 2, 2026 at 11:20 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
Ok, I tried to add env. variable for profile but it still does not work ?
CIN_CM_PROFILE=/usr/share/color/icc/colord/ProPhotoRGB.icc bin/cin /dev/shm/R2020-P3-color-bars.png
as in, it just show same picture!
On Sat, May 2, 2026 at 9:59 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
aww, forgot to check if side data exist ... It crashes if I load file _without_ such side data, so in a sense it detect such files correctly?
On Sat, May 2, 2026 at 9:48 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
ah, it "worked"
I just need to set "ffmpeg first" (I switched away from it for testing)
But I still can't see difference?
On Sat, May 2, 2026 at 9:30 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I tried to stuff cmsDoTransform into our ffmpeg.C but it does not work :(
as in, it does not even come to this newly added block ... does not print colormodel or "cms!" line
On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu...
this was answered like this
=== copy ===
hTransform = cmsCreateTransform(hInProfile, TYPE_CMYK_8, hOutProfile, TYPE_ARGB_8, // ARGB is most likely for QImage INTENT_PERCEPTUAL, 0);
uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) uchar *out = outImage->bits();
cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb));
===
official article show bigger switch
https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/
/** * Convert from Qt format to lcms2 format */ static cmsUInt32Number toLcmsFormat(QImage::Format fmt) { switch (fmt) { case QImage::Format_ARGB32: // (0xAARRGGBB) case QImage::Format_RGB32: // (0xffRRGGBB) return TYPE_BGRA_8;
case QImage::Format_RGB888: return TYPE_RGB_8; // 24-bit RGB format (8-8-8).
case QImage::Format_RGBX8888: case QImage::Format_RGBA8888: return TYPE_RGBA_8;
case QImage::Format_Grayscale8: return TYPE_GRAY_8;
case QImage::Format_Grayscale16: return TYPE_GRAY_16;
case QImage::Format_RGBA64: case QImage::Format_RGBX64: return TYPE_RGBA_16;
case QImage::Format_BGR888: return TYPE_BGR_8;
default: return 0;
} }
so I think we can add support for rgb8 timeline format at least, in same place where swscale call done in our ffmpeg.C
in ffmpeg we have
libavfilter/vf_iccdetect.c
#include <lcms2.h> const AVFrameSideData *sd; cmsHPROFILE profile;
sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size);
cmsCloseProfile(profile);
Full documentation in pdf form
https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf
TYPE_RGB_FLT/TYPE_RGBA_FLT exist in /usr/include/lcms2.h
so rgba-float should be supportable too.
I'll try to write easy detect part for configure first.
I tried compiling with lcms2 and running a few tests, but unfortunately I’ve reached the usual point where I get confused and don’t understand anything anymore. When I load the JPEGs or PNGs from “wide-gamut-tests,” the asset displays normally, but in the terminal I see these lines that I don’t know how to interpret. file:/home/paz/wide-gamut-tests/P3-sRGB-color-ring.png err: Operation not permitted file:/home/paz/wide-gamut-tests/R2020-P3-color-ring.png err: Operation not permitted What does “unallowed operation” refer to? What's even more confusing is that I get the same result whether I run cin with or without CIN_CM_PROFILE=... If I use your command line: CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" /home/paz/cinelerra/cinelerra-5.1/bin/cin /home/paz/wide-gamuts-tests/*.jpg Si avvia CinGG ma si apre una finestra di avvertimento con scritto: int MWindow::load_filenames(ArrayList<char*>*, int, int, int): Failed to open /home/paz/wide-gamuts-tests/*.jpg In any case, I'm not quite sure what to do or what to look for. To verify that color management is enabled, should I see the horizontal stripes and the circle in the “color bars” and “color ring” images, or not? Basically, CinGG behaves like GIMP 3 when “color-managed display” is enabled. In CinGG, there’s a slight difference between the same PNG or JPEG image, whereas in GIMP I don’t see any difference. Krita is like GIMP. Kdenlive is similar to CinGG, but I’m not quite sure how it relates to “color-managed.” It displays a message saying it doesn’t support image profiles.
On Mon, May 4, 2026 at 11:49 AM Andrea paz <gamberucci.andrea@gmail.com> wrote:
I tried compiling with lcms2 and running a few tests, but unfortunately I’ve reached the usual point where I get confused and don’t understand anything anymore. When I load the JPEGs or PNGs from “wide-gamut-tests,” the asset displays normally, but in the terminal I see these lines that I don’t know how to interpret.
file:/home/paz/wide-gamut-tests/P3-sRGB-color-ring.png err: Operation not permitted
file:/home/paz/wide-gamut-tests/R2020-P3-color-ring.png err: Operation not permitted
Not sure ... they only appear after my peaches? You can change loglevel to verbose in decode.opts in ffmpeg dubdir of your cingg installation structure and reload.
What does “unallowed operation” refer to?
What's even more confusing is that I get the same result whether I run cin with or without CIN_CM_PROFILE=... If I use your command line:
CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" /home/paz/cinelerra/cinelerra-5.1/bin/cin /home/paz/wide-gamuts-tests/*.jpg
Si avvia CinGG ma si apre una finestra di avvertimento con scritto:
int MWindow::load_filenames(ArrayList<char*>*, int, int, int): Failed to open /home/paz/wide-gamuts-tests/*.jpg
May be there was non-jpeg file? Can you double-check those opens normally in other programs? If you replace *.jpg with *.png does it behave any better (cingg may create a lot of video tracks in this case, one for each file) ?
In any case, I'm not quite sure what to do or what to look for. To verify that color management is enabled, should I see the horizontal stripes and the circle in the “color bars” and “color ring” images, or not?
In theory if all conditions meet (there is embedded profile, there is env. variable for output (to pipeline) icc profile, project set to rgba8) you can see "cms!" line printed to console. I used one of those redtruck_GBR.jpg tests wehere without color management sky and truck are inverted colors. Also jpg with green text "your browser or workflow does not claim any color management" replaced with white text about working color management in Firefox or patched cingg.
Basically, CinGG behaves like GIMP 3 when “color-managed display” is enabled. In CinGG, there’s a slight difference between the same PNG or JPEG image, whereas in GIMP I don’t see any difference. Krita is like GIMP. Kdenlive is similar to CinGG, but I’m not quite sure how it relates to “color-managed.” It displays a message saying it doesn’t support image profiles.
Note that I used TDE with no color management, on X server, obviously. If you have "simple" X session in your login manager you can retry here just for excluding Xwayland specific behavior for a moment.
I ran all the tests in X11. With the patches and `logleve=verbose`, I get this message: [swscaler @ 0x7f1c4c061040] deprecated pixel format used, make sure you did set range correctly With AppImage, i.e., without patches, I see the same behavior. Without `loglevel=verbose`, no messages appear in the terminal. I'm not sure if your patches work on my system. Or maybe the problem is my monitor's color profile (wide-gamut with BT.1886 gamma). Since I can no longer disable or change it (that's the problem that made me switch to Wayland). When I use Redtruck_GBR.jpg in both the AppImage and the CinGG compiled with the patches, I see the blue truck and the green sky. So that proves your patches don't work on my system (KDE). I used the three patches: 0001, 0002, and 0003. Maybe I should also use the lcms2_transform.diff patch? Do I need to use any options in ./configure? I had already added the flags2=icc_profiles tag to decode.opts CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" /home/paz/cinelerra/cinelerra-5.1/bin/cin /home/paz/wide-gamuts-tests/*.jpg still isn't working for me, even after removing all non-JPG files from the folder: same error. Maybe your patches only work when launched from the terminal, and not—as I normally do—from a desktop shortcut to which I've added CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc"?
On Mon, May 4, 2026 at 10:34 PM Andrea paz <gamberucci.andrea@gmail.com> wrote:
I ran all the tests in X11. With the patches and `logleve=verbose`, I get this message: [swscaler @ 0x7f1c4c061040] deprecated pixel format used, make sure you did set range correctly
With AppImage, i.e., without patches, I see the same behavior. Without `loglevel=verbose`, no messages appear in the terminal. I'm not sure if your patches work on my system. Or maybe the problem is my monitor's color profile (wide-gamut with BT.1886 gamma). Since I can no longer disable or change it (that's the problem that made me switch to Wayland).
When I use Redtruck_GBR.jpg in both the AppImage and the CinGG compiled with the patches, I see the blue truck and the green sky. So that proves your patches don't work on my system (KDE). I used the three patches: 0001, 0002, and 0003. Maybe I should also use the lcms2_transform.diff patch? Do I need to use any options in ./configure?
It worked for me without options because I set it to auto Did you regenerate configure with ./sutogen.sh Does global_config contain lcms2 related defines after you ran ./configure? I had already added the flags2=icc_profiles tag to decode.opts
CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" /home/paz/cinelerra/cinelerra-5.1/bin/cin /home/paz/wide-gamuts-tests/*.jpg still isn't working for me, even after removing all non-JPG files from the folder: same error. Maybe your patches only work when launched from the terminal, and not—as I normally do—from a desktop shortcut to which I've added CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc"?
depend on how your launcher (in KDE) works with env. variables. Yes, I just started cin from konsole (TDEs terminal emulator).
On Mon, May 4, 2026 at 10:34 PM Andrea paz <gamberucci.andrea@gmail.com> wrote:
I ran all the tests in X11. With the patches and `logleve=verbose`, I get this message: [swscaler @ 0x7f1c4c061040] deprecated pixel format used, make sure you did set range correctly
With AppImage, i.e., without patches, I see the same behavior. Without `loglevel=verbose`, no messages appear in the terminal. I'm not sure if your patches work on my system. Or maybe the problem is my monitor's color profile (wide-gamut with BT.1886 gamma). Since I can no longer disable or change it (that's the problem that made me switch to Wayland).
When I use Redtruck_GBR.jpg in both the AppImage and the CinGG compiled with the patches, I see the blue truck and the green sky. So that proves your patches don't work on my system (KDE). I used the three patches: 0001, 0002, and 0003. Maybe I should also use the lcms2_transform.diff patch? Do I need to use any options in ./configure? I had already added the flags2=icc_profiles tag to decode.opts
CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" /home/paz/cinelerra/cinelerra-5.1/bin/cin /home/paz/wide-gamuts-tests/*.jpg still isn't working for me, even after removing all non-JPG files from the folder: same error. Maybe your patches only work when launched from the terminal, and not—as I normally do—from a desktop shortcut to which I've added CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc"?
https://pointieststick.com/2022/11/11/this-week-in-kde-better-environment-va... === KMenuEdit and the properties dialog now make it easy for you to set environment variables when opening your apps. This was always possible, but you had to know the secret special syntax (e.g. Exec=env FOO=1 kate); now the UI makes it easy and explicitly supported (Dashon Wells, Frameworks 5.101 and Plasma 5.27. Link 1 and link 2): ==== I guess Arch does have new enough KDE so it all in the menus somewhere ..... I used to have one such command in my launcher history but one electricity surprize shutdown later it disappeared ...
Yeah, sorry, I didn't mention it, but the ./configure command showed that lcms2 was enabled, and there were also many lcms2 entries in the cinlog (and no errors!). So the patch applied without any issues. I've always used the launcher by setting the environment variables in the appropriate field, and it's always worked—for example, with the variable for 16-bit. In this case, however, I used a sh script, which I’m attaching. And that was exactly the problem. By adding the variable to the launcher instead of using the script, lcms works. The “cms” entry appears in the terminal, and redtruck_GBR.jpg is displayed correctly in the compositor. I’ll be running some more tests tomorrow, but for now I just wanted to thank you—not only for your patience with me, but also for the incredible work you’re doing. Adding color features to CinGG was an impossible task (as I often say, Adam told me that Cinelerra wasn’t designed for color). Yet you managed to do it. I don’t know how to thank you.
Andrew-R, assuming that I correctly used only the 3 patches attached on this particular email (dated May 2 11:11 PM - not sure which time zone reflected here, maybe Germany?) I think an additional "ifdef" or something may be needed in ffmpeg.C. I will send just you the log but the error is: g++ `cat x86_64/c_flags` -DMSGQUAL=filecr2 -c filecr2.C -o x86_64/filecr2.o
g++ `cat x86_64/c_flags` -DMSGQUAL=filedv -c filedv.C -o x86_64/filedv.o ffmpeg.C:55:10: fatal error: *lcms2.h: No such file or directory* 55 | #include "lcms2.h" | ^~~~~~~~~ compilation terminated. make[2]: *** [Makefile:600: x86_64/ffmpeg.o] Error 1 make[2]: *** Waiting for unfinished jobs....
On Sat, May 2, 2026 at 1:11 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
So, i think this one adds lcms2 compile guards so should work in addition to another patch
0001-lcms2-configure-support-for-internal-ffmpeg.patch
added all 3 as attaches.
Usage
CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" bin/cin /dev/shm/gradient\ *.jpg
without cin_CM_PROFILE there should be no difference in both tracks
with it srgb track should have much muted colors (or if you use sRGB profile ProPhoto one must be much brighter.)
Works only with rbga8 project profile, ffmpeg input.
May not work at playback, but works at rendering and stop frame in compositor.
Timeline/miniatures not color manged
On Sat, May 2, 2026 at 8:31 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I think this one works (at rgba8 only for now)
at least it shows some difference between srb and prophoto jpegs now
and between R2020-P3 png in rgb8 (no cms) and rgba8 (cms) modes
On Sat, May 2, 2026 at 11:20 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
Ok, I tried to add env. variable for profile but it still does not
work ?
CIN_CM_PROFILE=/usr/share/color/icc/colord/ProPhotoRGB.icc bin/cin /dev/shm/R2020-P3-color-bars.png
as in, it just show same picture!
On Sat, May 2, 2026 at 9:59 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
aww, forgot to check if side data exist ... It crashes if I load file _without_ such side data, so in a sense it detect such files correctly?
On Sat, May 2, 2026 at 9:48 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
ah, it "worked"
I just need to set "ffmpeg first" (I switched away from it for
testing)
But I still can't see difference?
On Sat, May 2, 2026 at 9:30 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I tried to stuff cmsDoTransform into our ffmpeg.C but it does not work :(
as in, it does not even come to this newly added block ... does not print colormodel or "cms!" line
On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote: > >
https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu...
> > this was answered like this > > === copy === > > hTransform = cmsCreateTransform(hInProfile, > TYPE_CMYK_8, > hOutProfile, > TYPE_ARGB_8, // ARGB is most likely for QImage > INTENT_PERCEPTUAL, 0); > > uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) > uchar *out = outImage->bits(); > > cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb)); > > === > > official article show bigger switch > > https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/ > > /** > * Convert from Qt format to lcms2 format > */ > static cmsUInt32Number toLcmsFormat(QImage::Format fmt) > { > switch (fmt) > { > case QImage::Format_ARGB32: // (0xAARRGGBB) > case QImage::Format_RGB32: // (0xffRRGGBB) > return TYPE_BGRA_8; > > case QImage::Format_RGB888: > return TYPE_RGB_8; // 24-bit RGB format (8-8-8). > > case QImage::Format_RGBX8888: > case QImage::Format_RGBA8888: > return TYPE_RGBA_8; > > case QImage::Format_Grayscale8: > return TYPE_GRAY_8; > > case QImage::Format_Grayscale16: > return TYPE_GRAY_16; > > case QImage::Format_RGBA64: > case QImage::Format_RGBX64: > return TYPE_RGBA_16; > > case QImage::Format_BGR888: > return TYPE_BGR_8; > > default: > return 0; > > } > } > > > so I think we can add support for rgb8 timeline format at least, in > same place where swscale call done in our ffmpeg.C > > in ffmpeg we have > > libavfilter/vf_iccdetect.c > > #include <lcms2.h> > const AVFrameSideData *sd; > cmsHPROFILE profile; > > sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); > profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size); > > cmsCloseProfile(profile); > > Full documentation in pdf form > > https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf > > TYPE_RGB_FLT/TYPE_RGBA_FLT exist in > /usr/include/lcms2.h > > so rgba-float should be supportable too. > > I'll try to write easy detect part for configure first.
Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
вт, 5 мая 2026 г., 21:20 Phyllis Smith <phylsmith2017@gmail.com>:
Andrew-R, assuming that I correctly used only the 3 patches attached on this particular email (dated May 2 11:11 PM - not sure which time zone reflected here, maybe Germany?) I think an additional "ifdef" or something may be needed in ffmpeg.C. I will send just you the log but the error is:
g++ `cat x86_64/c_flags` -DMSGQUAL=filecr2 -c filecr2.C -o
x86_64/filecr2.o g++ `cat x86_64/c_flags` -DMSGQUAL=filedv -c filedv.C -o x86_64/filedv.o ffmpeg.C:55:10: fatal error: *lcms2.h: No such file or directory* 55 | #include "lcms2.h" | ^~~~~~~~~ compilation terminated. make[2]: *** [Makefile:600: x86_64/ffmpeg.o] Error 1 make[2]: *** Waiting for unfinished jobs....
Do you have lcms2-dev installed? May be logic to detect its presence in configure.ac failed ....
On Sat, May 2, 2026 at 1:11 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
So, i think this one adds lcms2 compile guards so should work in addition to another patch
0001-lcms2-configure-support-for-internal-ffmpeg.patch
added all 3 as attaches.
Usage
CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" bin/cin /dev/shm/gradient\ *.jpg
without cin_CM_PROFILE there should be no difference in both tracks
with it srgb track should have much muted colors (or if you use sRGB profile ProPhoto one must be much brighter.)
Works only with rbga8 project profile, ffmpeg input.
May not work at playback, but works at rendering and stop frame in compositor.
Timeline/miniatures not color manged
On Sat, May 2, 2026 at 8:31 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I think this one works (at rgba8 only for now)
at least it shows some difference between srb and prophoto jpegs now
and between R2020-P3 png in rgb8 (no cms) and rgba8 (cms) modes
On Sat, May 2, 2026 at 11:20 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
Ok, I tried to add env. variable for profile but it still does not
work ?
CIN_CM_PROFILE=/usr/share/color/icc/colord/ProPhotoRGB.icc bin/cin /dev/shm/R2020-P3-color-bars.png
as in, it just show same picture!
On Sat, May 2, 2026 at 9:59 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
aww, forgot to check if side data exist ... It crashes if I load
file
_without_ such side data, so in a sense it detect such files correctly?
On Sat, May 2, 2026 at 9:48 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
ah, it "worked"
I just need to set "ffmpeg first" (I switched away from it for
testing)
But I still can't see difference?
On Sat, May 2, 2026 at 9:30 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote: > > I tried to stuff cmsDoTransform into our ffmpeg.C > but it does not work :( > > as in, it does not even come to this newly added block ... > does not print colormodel or "cms!" line > > On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu > <randrianasulu@gmail.com> wrote: > > > >
https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu...
> > > > this was answered like this > > > > === copy === > > > > hTransform = cmsCreateTransform(hInProfile, > > TYPE_CMYK_8, > > hOutProfile, > > TYPE_ARGB_8, // ARGB is most likely for QImage > > INTENT_PERCEPTUAL, 0); > > > > uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) > > uchar *out = outImage->bits(); > > > > cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb)); > > > > === > > > > official article show bigger switch > > > > https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/ > > > > /** > > * Convert from Qt format to lcms2 format > > */ > > static cmsUInt32Number toLcmsFormat(QImage::Format fmt) > > { > > switch (fmt) > > { > > case QImage::Format_ARGB32: // (0xAARRGGBB) > > case QImage::Format_RGB32: // (0xffRRGGBB) > > return TYPE_BGRA_8; > > > > case QImage::Format_RGB888: > > return TYPE_RGB_8; // 24-bit RGB format (8-8-8). > > > > case QImage::Format_RGBX8888: > > case QImage::Format_RGBA8888: > > return TYPE_RGBA_8; > > > > case QImage::Format_Grayscale8: > > return TYPE_GRAY_8; > > > > case QImage::Format_Grayscale16: > > return TYPE_GRAY_16; > > > > case QImage::Format_RGBA64: > > case QImage::Format_RGBX64: > > return TYPE_RGBA_16; > > > > case QImage::Format_BGR888: > > return TYPE_BGR_8; > > > > default: > > return 0; > > > > } > > } > > > > > > so I think we can add support for rgb8 timeline format at least, in > > same place where swscale call done in our ffmpeg.C > > > > in ffmpeg we have > > > > libavfilter/vf_iccdetect.c > > > > #include <lcms2.h> > > const AVFrameSideData *sd; > > cmsHPROFILE profile; > > > > sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); > > profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size); > > > > cmsCloseProfile(profile); > > > > Full documentation in pdf form > > > > https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf > > > > TYPE_RGB_FLT/TYPE_RGBA_FLT exist in > > /usr/include/lcms2.h > > > > so rgba-float should be supportable too. > > > > I'll try to write easy detect part for configure first.
Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
Well, yeah but my concern is for older systems using automatic build procedures that have worked as is for a long time with lcms2 installed without lcms2.h by default. In my case, not a problem as I know of the change and will build "--without-lcms2" but it fails on Ubuntu 16, Debian 9.1 32 bit, and Fedora 32 that I tried. Not an issue with Fedora 42 and I expect all recent O/S. I am torn between keeping older systems going or having the color benefits with these patches automatically on builds. Because not many people bother to read the Release Notes and will not know of the required change who use older systems. Is there objections to using "no" instead of "auto" (like colorio) in configure.ac? I can not decide what is best. P.S. Just to verify that of all the patches for this issue, the only ones to apply are:
0001-lcms2-configure-support-for-internal-ffmpeg.patch 0002-Simple-opencolorio-enable-for-ffmpeg-without-testing.patch 0003-Add-very-basic-lcms2-color-management-for-ffmpeg-inp.patch
Is that correct? On Tue, May 5, 2026 at 2:09 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
вт, 5 мая 2026 г., 21:20 Phyllis Smith <phylsmith2017@gmail.com>:
Andrew-R, assuming that I correctly used only the 3 patches attached on this particular email (dated May 2 11:11 PM - not sure which time zone reflected here, maybe Germany?) I think an additional "ifdef" or something may be needed in ffmpeg.C. I will send just you the log but the error is:
g++ `cat x86_64/c_flags` -DMSGQUAL=filecr2 -c filecr2.C -o
x86_64/filecr2.o g++ `cat x86_64/c_flags` -DMSGQUAL=filedv -c filedv.C -o x86_64/filedv.o ffmpeg.C:55:10: fatal error: *lcms2.h: No such file or directory* 55 | #include "lcms2.h" | ^~~~~~~~~ compilation terminated. make[2]: *** [Makefile:600: x86_64/ffmpeg.o] Error 1 make[2]: *** Waiting for unfinished jobs....
Do you have lcms2-dev installed? May be logic to detect its presence in configure.ac failed ....
On Sat, May 2, 2026 at 1:11 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
So, i think this one adds lcms2 compile guards so should work in addition to another patch
0001-lcms2-configure-support-for-internal-ffmpeg.patch
added all 3 as attaches.
Usage
CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" bin/cin /dev/shm/gradient\ *.jpg
without cin_CM_PROFILE there should be no difference in both tracks
with it srgb track should have much muted colors (or if you use sRGB profile ProPhoto one must be much brighter.)
Works only with rbga8 project profile, ffmpeg input.
May not work at playback, but works at rendering and stop frame in compositor.
Timeline/miniatures not color manged
On Sat, May 2, 2026 at 8:31 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I think this one works (at rgba8 only for now)
at least it shows some difference between srb and prophoto jpegs now
and between R2020-P3 png in rgb8 (no cms) and rgba8 (cms) modes
On Sat, May 2, 2026 at 11:20 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
Ok, I tried to add env. variable for profile but it still does not
work ?
CIN_CM_PROFILE=/usr/share/color/icc/colord/ProPhotoRGB.icc bin/cin /dev/shm/R2020-P3-color-bars.png
as in, it just show same picture!
On Sat, May 2, 2026 at 9:59 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
aww, forgot to check if side data exist ... It crashes if I load
file
_without_ such side data, so in a sense it detect such files correctly?
On Sat, May 2, 2026 at 9:48 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote: > > ah, it "worked" > > I just need to set "ffmpeg first" (I switched away from it for testing) > > But I still can't see difference? > > > On Sat, May 2, 2026 at 9:30 AM Andrew Randrianasulu > <randrianasulu@gmail.com> wrote: > > > > I tried to stuff cmsDoTransform into our ffmpeg.C > > but it does not work :( > > > > as in, it does not even come to this newly added block ... > > does not print colormodel or "cms!" line > > > > On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu > > <randrianasulu@gmail.com> wrote: > > > > > > https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu... > > > > > > this was answered like this > > > > > > === copy === > > > > > > hTransform = cmsCreateTransform(hInProfile, > > > TYPE_CMYK_8, > > > hOutProfile, > > > TYPE_ARGB_8, // ARGB is most likely for QImage > > > INTENT_PERCEPTUAL, 0); > > > > > > uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) > > > uchar *out = outImage->bits(); > > > > > > cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb)); > > > > > > === > > > > > > official article show bigger switch > > > > > > https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/ > > > > > > /** > > > * Convert from Qt format to lcms2 format > > > */ > > > static cmsUInt32Number toLcmsFormat(QImage::Format fmt) > > > { > > > switch (fmt) > > > { > > > case QImage::Format_ARGB32: // (0xAARRGGBB) > > > case QImage::Format_RGB32: // (0xffRRGGBB) > > > return TYPE_BGRA_8; > > > > > > case QImage::Format_RGB888: > > > return TYPE_RGB_8; // 24-bit RGB format (8-8-8). > > > > > > case QImage::Format_RGBX8888: > > > case QImage::Format_RGBA8888: > > > return TYPE_RGBA_8; > > > > > > case QImage::Format_Grayscale8: > > > return TYPE_GRAY_8; > > > > > > case QImage::Format_Grayscale16: > > > return TYPE_GRAY_16; > > > > > > case QImage::Format_RGBA64: > > > case QImage::Format_RGBX64: > > > return TYPE_RGBA_16; > > > > > > case QImage::Format_BGR888: > > > return TYPE_BGR_8; > > > > > > default: > > > return 0; > > > > > > } > > > } > > > > > > > > > so I think we can add support for rgb8 timeline format at least, in > > > same place where swscale call done in our ffmpeg.C > > > > > > in ffmpeg we have > > > > > > libavfilter/vf_iccdetect.c > > > > > > #include <lcms2.h> > > > const AVFrameSideData *sd; > > > cmsHPROFILE profile; > > > > > > sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); > > > profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size); > > > > > > cmsCloseProfile(profile); > > > > > > Full documentation in pdf form > > > > > > https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf > > > > > > TYPE_RGB_FLT/TYPE_RGBA_FLT exist in > > > /usr/include/lcms2.h > > > > > > so rgba-float should be supportable too. > > > > > > I'll try to write easy detect part for configure first.
Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
On Wed, May 6, 2026 at 3:22 AM Phyllis Smith <phylsmith2017@gmail.com> wrote:
Well, yeah but my concern is for older systems using automatic build procedures that have worked as is for a long time with lcms2 installed without lcms2.h by default. In my case, not a problem as I know of the change and will build "--without-lcms2" but it fails on Ubuntu 16, Debian 9.1 32 bit, and Fedora 32 that I tried. Not an issue with Fedora 42 and I expect all recent O/S.
I am torn between keeping older systems going or having the color benefits with these patches automatically on builds. Because not many people bother to read the Release Notes and will not know of the required change who use older systems.
Is there objections to using "no" instead of "auto" (like colorio) in configure.ac? I can not decide what is best.
May be we can fix this part? Does it work better if you replace +if test "x$HAVE_LIBLCMS2" != "xyes" -a "x$WANT_LIBLCMS2" = "xyes"; then with +if test "x$HAVE_LIBLCMS2" != "xyes" -a "x$WANT_LIBLCMS2" != "xno"; then in configure.ac part of patch 0001? Or if this fails then yes, just set it to no instead of auto ... sorry, I did not test this case upd: testing on debian 11 with this change, it correctly stops with err. msg about missing lcms2 support, and --without-lcms2 goes past this stage. I can try to modify this block so it just set want_lcms2 to to no automatically if not found, but not sure if manual disable will still work in this case
P.S. Just to verify that of all the patches for this issue, the only ones to apply are:
0001-lcms2-configure-support-for-internal-ffmpeg.patch 0002-Simple-opencolorio-enable-for-ffmpeg-without-testing.patch 0003-Add-very-basic-lcms2-color-management-for-ffmpeg-inp.patch
Is that correct?
On Tue, May 5, 2026 at 2:09 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
вт, 5 мая 2026 г., 21:20 Phyllis Smith <phylsmith2017@gmail.com>:
Andrew-R, assuming that I correctly used only the 3 patches attached on this particular email (dated May 2 11:11 PM - not sure which time zone reflected here, maybe Germany?) I think an additional "ifdef" or something may be needed in ffmpeg.C. I will send just you the log but the error is:
g++ `cat x86_64/c_flags` -DMSGQUAL=filecr2 -c filecr2.C -o x86_64/filecr2.o g++ `cat x86_64/c_flags` -DMSGQUAL=filedv -c filedv.C -o x86_64/filedv.o ffmpeg.C:55:10: fatal error: lcms2.h: No such file or directory 55 | #include "lcms2.h" | ^~~~~~~~~ compilation terminated. make[2]: *** [Makefile:600: x86_64/ffmpeg.o] Error 1 make[2]: *** Waiting for unfinished jobs....
Do you have lcms2-dev installed? May be logic to detect its presence in configure.ac failed ....
On Sat, May 2, 2026 at 1:11 PM Andrew Randrianasulu via Cin <cin@lists.cinelerra-gg.org> wrote:
So, i think this one adds lcms2 compile guards so should work in addition to another patch
0001-lcms2-configure-support-for-internal-ffmpeg.patch
added all 3 as attaches.
Usage
CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" bin/cin /dev/shm/gradient\ *.jpg
without cin_CM_PROFILE there should be no difference in both tracks
with it srgb track should have much muted colors (or if you use sRGB profile ProPhoto one must be much brighter.)
Works only with rbga8 project profile, ffmpeg input.
May not work at playback, but works at rendering and stop frame in compositor.
Timeline/miniatures not color manged
On Sat, May 2, 2026 at 8:31 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I think this one works (at rgba8 only for now)
at least it shows some difference between srb and prophoto jpegs now
and between R2020-P3 png in rgb8 (no cms) and rgba8 (cms) modes
On Sat, May 2, 2026 at 11:20 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
Ok, I tried to add env. variable for profile but it still does not work ?
CIN_CM_PROFILE=/usr/share/color/icc/colord/ProPhotoRGB.icc bin/cin /dev/shm/R2020-P3-color-bars.png
as in, it just show same picture!
On Sat, May 2, 2026 at 9:59 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote: > > aww, forgot to check if side data exist ... It crashes if I load file > _without_ such side data, so in a sense it detect such files > correctly? > > > On Sat, May 2, 2026 at 9:48 AM Andrew Randrianasulu > <randrianasulu@gmail.com> wrote: > > > > ah, it "worked" > > > > I just need to set "ffmpeg first" (I switched away from it for testing) > > > > But I still can't see difference? > > > > > > On Sat, May 2, 2026 at 9:30 AM Andrew Randrianasulu > > <randrianasulu@gmail.com> wrote: > > > > > > I tried to stuff cmsDoTransform into our ffmpeg.C > > > but it does not work :( > > > > > > as in, it does not even come to this newly added block ... > > > does not print colormodel or "cms!" line > > > > > > On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu > > > <randrianasulu@gmail.com> wrote: > > > > > > > > https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu... > > > > > > > > this was answered like this > > > > > > > > === copy === > > > > > > > > hTransform = cmsCreateTransform(hInProfile, > > > > TYPE_CMYK_8, > > > > hOutProfile, > > > > TYPE_ARGB_8, // ARGB is most likely for QImage > > > > INTENT_PERCEPTUAL, 0); > > > > > > > > uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) > > > > uchar *out = outImage->bits(); > > > > > > > > cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb)); > > > > > > > > === > > > > > > > > official article show bigger switch > > > > > > > > https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/ > > > > > > > > /** > > > > * Convert from Qt format to lcms2 format > > > > */ > > > > static cmsUInt32Number toLcmsFormat(QImage::Format fmt) > > > > { > > > > switch (fmt) > > > > { > > > > case QImage::Format_ARGB32: // (0xAARRGGBB) > > > > case QImage::Format_RGB32: // (0xffRRGGBB) > > > > return TYPE_BGRA_8; > > > > > > > > case QImage::Format_RGB888: > > > > return TYPE_RGB_8; // 24-bit RGB format (8-8-8). > > > > > > > > case QImage::Format_RGBX8888: > > > > case QImage::Format_RGBA8888: > > > > return TYPE_RGBA_8; > > > > > > > > case QImage::Format_Grayscale8: > > > > return TYPE_GRAY_8; > > > > > > > > case QImage::Format_Grayscale16: > > > > return TYPE_GRAY_16; > > > > > > > > case QImage::Format_RGBA64: > > > > case QImage::Format_RGBX64: > > > > return TYPE_RGBA_16; > > > > > > > > case QImage::Format_BGR888: > > > > return TYPE_BGR_8; > > > > > > > > default: > > > > return 0; > > > > > > > > } > > > > } > > > > > > > > > > > > so I think we can add support for rgb8 timeline format at least, in > > > > same place where swscale call done in our ffmpeg.C > > > > > > > > in ffmpeg we have > > > > > > > > libavfilter/vf_iccdetect.c > > > > > > > > #include <lcms2.h> > > > > const AVFrameSideData *sd; > > > > cmsHPROFILE profile; > > > > > > > > sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); > > > > profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size); > > > > > > > > cmsCloseProfile(profile); > > > > > > > > Full documentation in pdf form > > > > > > > > https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf > > > > > > > > TYPE_RGB_FLT/TYPE_RGBA_FLT exist in > > > > /usr/include/lcms2.h > > > > > > > > so rgba-float should be supportable too. > > > > > > > > I'll try to write easy detect part for configure first.
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
On Wed, May 6, 2026 at 3:52 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
On Wed, May 6, 2026 at 3:22 AM Phyllis Smith <phylsmith2017@gmail.com> wrote:
Well, yeah but my concern is for older systems using automatic build procedures that have worked as is for a long time with lcms2 installed without lcms2.h by default. In my case, not a problem as I know of the change and will build "--without-lcms2" but it fails on Ubuntu 16, Debian 9.1 32 bit, and Fedora 32 that I tried. Not an issue with Fedora 42 and I expect all recent O/S.
I am torn between keeping older systems going or having the color benefits with these patches automatically on builds. Because not many people bother to read the Release Notes and will not know of the required change who use older systems.
Is there objections to using "no" instead of "auto" (like colorio) in configure.ac? I can not decide what is best.
May be we can fix this part?
Does it work better if you replace
+if test "x$HAVE_LIBLCMS2" != "xyes" -a "x$WANT_LIBLCMS2" = "xyes"; then
with
+if test "x$HAVE_LIBLCMS2" != "xyes" -a "x$WANT_LIBLCMS2" != "xno"; then
in configure.ac part of patch 0001?
Or if this fails then yes, just set it to no instead of auto ...
sorry, I did not test this case
upd: testing on debian 11 with this change, it correctly stops with err. msg about missing lcms2 support, and --without-lcms2 goes past this stage.
I can try to modify this block so it just set want_lcms2 to to no automatically if not found, but not sure if manual disable will still work in this case
Try attached patch on top of those 3 - should stay enabled if found, disable otherwise --without-lcms2 also should work
P.S. Just to verify that of all the patches for this issue, the only ones to apply are:
0001-lcms2-configure-support-for-internal-ffmpeg.patch 0002-Simple-opencolorio-enable-for-ffmpeg-without-testing.patch 0003-Add-very-basic-lcms2-color-management-for-ffmpeg-inp.patch
Is that correct?
On Tue, May 5, 2026 at 2:09 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
вт, 5 мая 2026 г., 21:20 Phyllis Smith <phylsmith2017@gmail.com>:
Andrew-R, assuming that I correctly used only the 3 patches attached on this particular email (dated May 2 11:11 PM - not sure which time zone reflected here, maybe Germany?) I think an additional "ifdef" or something may be needed in ffmpeg.C. I will send just you the log but the error is:
g++ `cat x86_64/c_flags` -DMSGQUAL=filecr2 -c filecr2.C -o x86_64/filecr2.o g++ `cat x86_64/c_flags` -DMSGQUAL=filedv -c filedv.C -o x86_64/filedv.o ffmpeg.C:55:10: fatal error: lcms2.h: No such file or directory 55 | #include "lcms2.h" | ^~~~~~~~~ compilation terminated. make[2]: *** [Makefile:600: x86_64/ffmpeg.o] Error 1 make[2]: *** Waiting for unfinished jobs....
Do you have lcms2-dev installed? May be logic to detect its presence in configure.ac failed ....
On Sat, May 2, 2026 at 1:11 PM Andrew Randrianasulu via Cin <cin@lists.cinelerra-gg.org> wrote:
So, i think this one adds lcms2 compile guards so should work in addition to another patch
0001-lcms2-configure-support-for-internal-ffmpeg.patch
added all 3 as attaches.
Usage
CIN_CM_PROFILE="/usr/share/color/icc/colord/WideGamutRGB.icc" bin/cin /dev/shm/gradient\ *.jpg
without cin_CM_PROFILE there should be no difference in both tracks
with it srgb track should have much muted colors (or if you use sRGB profile ProPhoto one must be much brighter.)
Works only with rbga8 project profile, ffmpeg input.
May not work at playback, but works at rendering and stop frame in compositor.
Timeline/miniatures not color manged
On Sat, May 2, 2026 at 8:31 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
I think this one works (at rgba8 only for now)
at least it shows some difference between srb and prophoto jpegs now
and between R2020-P3 png in rgb8 (no cms) and rgba8 (cms) modes
On Sat, May 2, 2026 at 11:20 AM Andrew Randrianasulu <randrianasulu@gmail.com> wrote: > > Ok, I tried to add env. variable for profile but it still does not work ? > > CIN_CM_PROFILE=/usr/share/color/icc/colord/ProPhotoRGB.icc bin/cin > /dev/shm/R2020-P3-color-bars.png > > as in, it just show same picture! > > > On Sat, May 2, 2026 at 9:59 AM Andrew Randrianasulu > <randrianasulu@gmail.com> wrote: > > > > aww, forgot to check if side data exist ... It crashes if I load file > > _without_ such side data, so in a sense it detect such files > > correctly? > > > > > > On Sat, May 2, 2026 at 9:48 AM Andrew Randrianasulu > > <randrianasulu@gmail.com> wrote: > > > > > > ah, it "worked" > > > > > > I just need to set "ffmpeg first" (I switched away from it for testing) > > > > > > But I still can't see difference? > > > > > > > > > On Sat, May 2, 2026 at 9:30 AM Andrew Randrianasulu > > > <randrianasulu@gmail.com> wrote: > > > > > > > > I tried to stuff cmsDoTransform into our ffmpeg.C > > > > but it does not work :( > > > > > > > > as in, it does not even come to this newly added block ... > > > > does not print colormodel or "cms!" line > > > > > > > > On Fri, May 1, 2026 at 11:07 AM Andrew Randrianasulu > > > > <randrianasulu@gmail.com> wrote: > > > > > > > > > > https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-throu... > > > > > > > > > > this was answered like this > > > > > > > > > > === copy === > > > > > > > > > > hTransform = cmsCreateTransform(hInProfile, > > > > > TYPE_CMYK_8, > > > > > hOutProfile, > > > > > TYPE_ARGB_8, // ARGB is most likely for QImage > > > > > INTENT_PERCEPTUAL, 0); > > > > > > > > > > uchar *in = outImage->bits(); // bits() is equivalent to scanLine(0) > > > > > uchar *out = outImage->bits(); > > > > > > > > > > cmsDoTransform(hTransform, in, out, outImage->byteCount() / sizeof(QRgb)); > > > > > > > > > > === > > > > > > > > > > official article show bigger switch > > > > > > > > > > https://littlecms.com/blog/2020/12/09/using-lcms2-on-qt/ > > > > > > > > > > /** > > > > > * Convert from Qt format to lcms2 format > > > > > */ > > > > > static cmsUInt32Number toLcmsFormat(QImage::Format fmt) > > > > > { > > > > > switch (fmt) > > > > > { > > > > > case QImage::Format_ARGB32: // (0xAARRGGBB) > > > > > case QImage::Format_RGB32: // (0xffRRGGBB) > > > > > return TYPE_BGRA_8; > > > > > > > > > > case QImage::Format_RGB888: > > > > > return TYPE_RGB_8; // 24-bit RGB format (8-8-8). > > > > > > > > > > case QImage::Format_RGBX8888: > > > > > case QImage::Format_RGBA8888: > > > > > return TYPE_RGBA_8; > > > > > > > > > > case QImage::Format_Grayscale8: > > > > > return TYPE_GRAY_8; > > > > > > > > > > case QImage::Format_Grayscale16: > > > > > return TYPE_GRAY_16; > > > > > > > > > > case QImage::Format_RGBA64: > > > > > case QImage::Format_RGBX64: > > > > > return TYPE_RGBA_16; > > > > > > > > > > case QImage::Format_BGR888: > > > > > return TYPE_BGR_8; > > > > > > > > > > default: > > > > > return 0; > > > > > > > > > > } > > > > > } > > > > > > > > > > > > > > > so I think we can add support for rgb8 timeline format at least, in > > > > > same place where swscale call done in our ffmpeg.C > > > > > > > > > > in ffmpeg we have > > > > > > > > > > libavfilter/vf_iccdetect.c > > > > > > > > > > #include <lcms2.h> > > > > > const AVFrameSideData *sd; > > > > > cmsHPROFILE profile; > > > > > > > > > > sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE); > > > > > profile = cmsOpenProfileFromMemTHR(s->icc.ctx, sd->data, sd->size); > > > > > > > > > > cmsCloseProfile(profile); > > > > > > > > > > Full documentation in pdf form > > > > > > > > > > https://www.littlecms.com/LittleCMS2.18%20tutorial.pdf > > > > > > > > > > TYPE_RGB_FLT/TYPE_RGBA_FLT exist in > > > > > /usr/include/lcms2.h > > > > > > > > > > so rgba-float should be supportable too. > > > > > > > > > > I'll try to write easy detect part for configure first.
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
I ran a few rendering tests using a patched version of CinGG and AppImage (unpatched). I used two presets: h265-med.mp4 e H265-12bit.mp4. The presets used do not show any issues with the patched CinGG. There is a significant drop in fps; for the h265-med.mp4 preset, it drops from 105 fps to 16 fps. For the h265-12bit.mp4 preset, it drops from 71 fps to 14 fps. The rendered video displays the correct colors that the patches already showed in the Compositor. These presets (and the rendering file) include the “colorspace,” “trc,” and “primaries” parameters. However, I believe they only affect the metadata. Is there a way to tell if the color space of the final file has actually changed, beyond the metadata reported by ffprobe, MediaInfo, etc.? So far, I’ve only run tests in X11; I’ll try Wayland as well. One thing to understand is how patches affect the temporary directory and, consequently, how they affect rendering (if they do). NOTE: mpv no longer works for me in X11 (with gpu-next) but it works in Wayland. I’m afraid that X11 apps will face more and more issues in the future.
On Wed, May 6, 2026 at 2:29 PM Andrea paz <gamberucci.andrea@gmail.com> wrote:
I ran a few rendering tests using a patched version of CinGG and AppImage (unpatched). I used two presets: h265-med.mp4 e H265-12bit.mp4. The presets used do not show any issues with the patched CinGG. There is a significant drop in fps; for the h265-med.mp4 preset, it drops from 105 fps to 16 fps. For the h265-12bit.mp4 preset, it drops from 71 fps to 14 fps.
Yeah, software color correction is slow .... The rendered video displays the correct colors that the patches already showed in the Compositor. These presets (and the rendering file) include the “colorspace,” “trc,” and “primaries” parameters. However, I believe they only affect the metadata. Is there a way to tell if the color space of the final file has actually changed, beyond the metadata reported by ffprobe, MediaInfo, etc.? Those patches do not add icc profile into final rendered file, but may be you can "inject" it with MP4Box from gpac ? exiftool nowadays also can work with some video files
So far, I’ve only run tests in X11; I’ll try Wayland as well. One thing to understand is how patches affect the temporary directory and, consequently, how they affect rendering (if they do).
If by temporary directory you mean background render - it remains uncorrected. You can try few other profiles (qt/mov with various codecs, mpeg2/4 via ffmpeg ...) but my understanding it should render input images/video corrected according to their embedded profile and one you selected via CIN_CM_PROFILE. I guess it will slow down even more as you add more tracks for something like split-screen? At playback (not pause) it will remain speedy, but moving picture will remain not color corrected (I think it already a bit different in motion as opposed to paused state, already for speed reason). Basically I envision usage of this feature mostly for slideshows from pre color-corrected images, and may be rendering those rare video files with embedded profile (mostly from macos ?). Usual "video" colorimetry remain the same. I yet to find way to "flatten" dynamic range of HDR vid without sacrificing wide color gamut. From historical perspective (color correction appear in Photoshop 5.0 in 1998) I think at least some icc profiles definitely were useful even on 8bit per channel displays, bu yes, fully seeing all those wide colors probably required 30 bpp / 10 bpc mode from graphical system, and we do not do this. I am not sure how lcms2 converts images with profiles internally - via high-precision buffer? For now I set both input and output buffers to rgba8 (so i guess it should match what GIMP 2.10 does by default, and also geequie image viewer). I played around with rgba-float modes but never saw them directly engaged on pause - so may be for 8bit input it was going via staged buffer , so my examination of ->format filed of vframe structure did not catch this ...) may be ffmpeg's OCIO filter will give us better video results if we ever learn how to use it ?
NOTE: mpv no longer works for me in X11 (with gpu-next) but it works in Wayland. I’m afraid that X11 apps will face more and more issues in the future.
Hopefully it just temporary (gpu-next indeed needed for using embedded color profile at playback - cingg does not do this because 1) mode I hacked first not used for x11/x11 direct/ogl playback 2) as your rendered test (at FHD resolution?) showed slowdown will be massive ...)
Thanks for the explanation. The OpenColorIO patch doesn't work for me. During the ./configure phase, it says it doesn't recognize “--enable-opencolorio” (not even with “--with-...”).
One thing to understand is how patches affect the temporary directory and, consequently, how they affect rendering (if they do).
If by temporary directory you mean background render - it remains uncorrected.
That was a translation error; my apologies. I meant “Temporary,” that is, the frame(buffer?) CinGG is working on.
On Wed, May 6, 2026 at 3:49 PM Andrea paz <gamberucci.andrea@gmail.com> wrote:
One thing to understand is how patches affect the temporary directory and, consequently, how they affect rendering (if they do).
If by temporary directory you mean background render - it remains uncorrected.
That was a translation error; my apologies. I meant “Temporary,” that is, the frame(buffer?) CinGG is working on.
Ah. I located those lcms2 calls in function that decodes ffmpeg-supplied avframe into our vframe. So from that point on our working buffer must contain color-corrected values (because profile comes as side data from libavformat I thought it was logical place to use it) In theory native png/jpeg/tiff readers/writers can grow same ability to use lcms2, but so far I am not sure if libtiff/png/jpeg can extract profile on its own or they need libexif.
On Wed, May 6, 2026 at 3:33 PM Andrea paz <gamberucci.andrea@gmail.com> wrote:
Thanks for the explanation.
The OpenColorIO patch doesn't work for me. During the ./configure phase, it says it doesn't recognize “--enable-opencolorio” (not even with “--with-...”).
for me it exist ./configure --with-opencolorio [snip] using: with-libopencolorio [snip] be sure you have 0002-Simple-opencolorio-enable-for-ffmpeg-without-testing.patch applied
Andrew, yes that works perfectly on Fedora 32 (old) and Fedora 42 (new) as does --without-lcms2. Sorry to bother you with trivial matter. Andrea, wow what a slow fps but for certain cases it may be worthwhile.
Try attached patch on top of those 3 - should stay enabled if found, disable otherwise
--without-lcms2
also should work
P.S. Just to verify that of all the patches for this issue, the only
ones to apply are:
0001-lcms2-configure-support-for-internal-ffmpeg.patch 0002-Simple-opencolorio-enable-for-ffmpeg-without-testing.patch 0003-Add-very-basic-lcms2-color-management-for-ffmpeg-inp.patch
Is that correct?
I checked Andrew's patches into GIT and will check to see that Andrey's builds compiled too. 0001-lcms2-configure-support-for-internal-ffmpeg.patch 0002-Simple-opencolorio-enable-for-ffmpeg-without-testing.patch 0003-Add-very-basic-lcms2-color-management-for-ffmpeg-inp.patch 0004-fix-lcms2-so-it-auto-sets-to-no-if-not-found.patch
I can try to modify this block so it just set want_lcms2 to to no
automatically if not found, but not sure if manual disable will still work in this case
Try attached patch on top of those 3 - should stay enabled if found, disable otherwise
--without-lcms2
also should work
0001-lcms2-configure-support-for-internal-ffmpeg.patch 0002-Simple-opencolorio-enable-for-ffmpeg-without-testing.patch 0003-Add-very-basic-lcms2-color-management-for-ffmpeg-inp.patch 0004-fix-lcms2-so-it-auto-sets-to-no-if-not-found.patch
participants (3)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith