- Cin - Cinelerra-GG Mailing Lists

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

17 Aug '22

чт, 4 авг. 2022 г., 09:28 Andrea paz <gamberucci.andrea(a)gmail.com>: > Thank you for the explanations. > I am trying to write a color section for the CGG manual. > I have a doubt: a long time ago GG said that on the > timeline/compositor we always see an sRGB output: > > "CinGG, works internally at 32 bits in RGB, but the output in timeline > is sRGB, and performs a first conversion from YUV of the original file > to RGB with the scaler (matrix function, not primaries or transfer > characteristic function), using its internal settings." > > Does this mean that it is useless to have wide-gamut monitors? And > that it is useless to have ICCs or LUTs unless they are limited to > sRGB only? I think some ffmpeg plugins work internally in rgba-float, so correction happens with high precision, just display truncate/dither image. So yes, not truely 'what you see is what you get' {as far as I understand all image processing happens in linear space ? Because converting back and forth at each effect sounds wasteful on cpu ...} I wonder if mpv can read those yuv4mpeg raw streams with color transfer info? May be you can render to pipe and add mpv as gl accelerated and color-corrected external player? But I think fixing display stage will be as 'simple' as using specialised color-corrected rgba-float-> 10bit rgb (or may be dithered/tonemapped 8bit rgb) function, as long as display driver support 30 bit color. I commented in few bugs in the past: https://www.cinelerra-gg.org/bugtracker/view.php?id=297 https://www.cinelerra-gg.org/bugtracker/view.php?id=294 https://www.cinelerra-gg.org/bugtracker/view.php?id=238 If so, it would be extremely limiting for color correction > in CGG. > My other doubt: what is the purpose of the "YUV color space" in > Preferences, just for encoding? I think it also used indirectly via FFVideoConvert::convert_vframe_picture in convert_cmodel function, in turn used by FFVideoStream::load all those in cinelerra/ffmpeg.C Any use of YUV type color spaces > should be discouraged since the signal on the screen is always sRGB. > Well, there is Xv (yuv) output, and encoded video tend to be variation of subsampled yuv (because it takes less space this way) >

5 10

Cingg crash with too low 'ulimit -n'?
by Andrew Randrianasulu 13 Aug '22

13 Aug '22

I found this forum bugreport concerned Cingg 64 bit x86 Appimage for Debian 11 https://www.linux.org.ru/forum/multimedia/16944076?lastmod=1660280725246 Answer was found by reporter, simply setting ulimit -n 4096 Fixed crash on media load .... On my termux 'ulimit -a' reports among other things: open files (-n) 32768

2 3

little patch for ffmpeg 5.1 plugins
by Andrew Randrianasulu 11 Aug '22

11 Aug '22

Some new plugins in 5.0/5.1 does not work for us ..

3 7

Mplayer2 compilation
by Andrew Randrianasulu 10 Aug '22

10 Aug '22

So, I tried to test my suggestion and try mplayer2's gl3 output (with icc / lcms2 support) I run into obvious barrier of ffmpeg API changes. For easy install I just cloned mplayer2 code from github first git clone https://github.com/astiob/mplayer2.git Then downloaded ffmpeg 2.3.6 tar.bz2 unpacked and configured it on 32 bit system like this # ./configure --disable-debug --disable-asm --disable-doc --enable-avresample May be you can leave asm enabled on 64 bit x86-64 system, for me it failed in h264 header. Then I installed this ffmpeg to default /usr/local prefix Then I configured mplayer2 without sdl: ./configure --disable-sdl And then I run into problem ...for some reason any ffmpeg decoded video was failing to init vo .. even null vo! I finally guessed there was missing {} pair ... After patching mplayer2 sources with attached patch I finally got output! I also slightly enlarged help text array, so -vo gl3:help will not truncated in the middle ... Note, by default mplayer2 binary still named mplayer, so please do not install this mplayer over system provided one, just run it from its source dir

2 1

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

07 Aug '22

сб, 6 авг. 2022 г., 16:16 Einar Rünkaru <einarrunkaru(a)gmail.com>: > > > On 06/08/2022 07:41, Andrew Randrianasulu wrote: > > > > > > пт, 5 авг. 2022 г., 20:05 Einar Rünkaru <einarrunkaru(a)gmail.com > > <mailto:[email protected]>>: > > > > > > > > On 05/08/2022 08:08, Andrew Randrianasulu wrote: > > > > > > > > > чт, 4 авг. 2022 г., 14:36 Andrew Randrianasulu > > <randrianasulu(a)gmail.com <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected] > >>>: > > > > > > > > https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html > > <https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html> > > > > > < > 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 ) > > Values can overflow or underflow inside certanin conversion. The output > of this conversion should be inside margins of this format. > > > > > > > > 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. > > > > --- > > > Of course when the size of pixel in bytes does not change. This is the > most effective solution. > > > > > > > > > > I also was reading ninedegreesbelow.com > > <http://ninedegreesbelow.com> <http://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> > > > > > > > < > 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> > > > <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.... > > > No, the links in the ticket did not open. Without these it was very hard > to understand what the problem was > > > > 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 ... > > The icc handlig has to be done when the execution reaches this place. > > > > I guess ffmpeg png reader also was dropping icc profile info until very > > recently .... > > Yes - this was ignored. > > > > > > > > > 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? > > Icc profile should be added as a new parameter. You cant reuse > get_row_pointers() for it. > Yes, I was talking about image buffer to pass to transform function .... > The right place for adding icc profile is color conversion routines. > Caller tell what profile should be used (no profile, some predefined or > some custom profile). > > > > > 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 ... > > Asset should not hold the profile. Profile is inside the original file, > in decoder parameters or in encoder parameters. > Ok .... > > > > > > > > > > > > > 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 ) > > > Yes, as I said above. > > Einar >

1 0

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:[email protected]>>: > > > > 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 03 Aug '22

03 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/[email protected]/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/[email protected]/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