Again on plugins in floating point (HDR)
I tried to make other changes to the plugins for Color Correction to be able to make it also see out-of-range (HDR) values and be able to change them. All of this involves floating point calculation. I tried changing the range of the following plugins: Alpha; Color3Way; ColorBalance; Gradient; Histogram Bezier e Overlay. If interested, I can report attempts to modify the code, but I got good results only with Color3Way. More in detail: Alpha: My modifications ruin the plugin. Probably widening the range 0 - 1.0 leads the algorithms to wrong results. However, I think the original plugin works in floating point. ColorBalance: From my tests I did not notice any difference with the unmodified plugin (I used an appimage). I am under the impression that this plugin already works in floating point and does not need modification. Gradient: Here again I find no difference with the original plugin. Again, I have the impression that the plugin already works in floating point. Overlay (shared effect): I don't notice any difference with the original plugin. Histogram Bezier: I tried extending the range similarly to Histogram (which works well in HDR, after modification). In this case I see no change. The code is much more complex and it is probably not enough to delete the CLAMP. The change I made is to the file "bistogram.C" line 361 I changed the value of 1.0 to 10.0. I also tried editing the file bistogramconfig.C line 110 e 111 I changed the value of 1.0 to 10.0. line 229 I changed the value of 1 to 10. I put these details because the plugin is very important for CC and I would love it if someone more experienced than me could make it work on out-of-range data as well. Besides, the plugin is not only a histogram but also uses the very important "Curves". For the Videoscope plugin I could not make changes because the code is too complicated for my skills; similarly to Histogram Bezier. Finally I describe Color3Way, in which the modification worked. In the original plugin the color wheels already seems to work in floating point, but not the V bar of brightness values (which are clipped). With the modification the V bar also works on out-of-range data. The modification is as follows: File "color3way.C": line 281 I changed the value of 1.0 to 100.0. line 284 I changed the value of 1.0 to 100.0 (I have also tried other values, e.g., 10.0, and the clamp always works up to those values). The floating point calculation works for both the saturation bar and the V bar. With the tests done so far, I have had no problems or errors/warnings on the terminal. I did the tests with exr images and then enabled the internal CinGG engine (but in the tests it also works with "ffmpeg first"). I set the color model to RGBA-FLOAT (inescapable: with integer 8-bit models you cannot have HDR) and the color range to 2020 NCL (but it works with all possible settings, not relevant). The graphics driver is X11 because with X11-OpenGL it does not work. Used patches: 0001-TEST-Simpler-unlimited-float-overlay.patch 0002-Allow-negative-numbers-in-overlayer.patch noclamp_in_histogram.diff Manual changes in color3way.C I am happy with the success with Color3Way (as with Histogram) because I believe it will become increasingly important to work on HDR video in the future. On the other hand, I regret not having success with Curves (Histogram Bezier) because it is an essential plugin for CC.
пт, 1 дек. 2023 г., 18:59 Andrea paz via Cin <[email protected]>:
I tried to make other changes to the plugins for Color Correction to be able to make it also see out-of-range (HDR) values and be able to change them. All of this involves floating point calculation. I tried changing the range of the following plugins: Alpha; Color3Way; ColorBalance; Gradient; Histogram Bezier e Overlay. If interested, I can report attempts to modify the code, but I got good results only with Color3Way. More in detail: Alpha: My modifications ruin the plugin. Probably widening the range 0 - 1.0 leads the algorithms to wrong results. However, I think the original plugin works in floating point. ColorBalance: From my tests I did not notice any difference with the unmodified plugin (I used an appimage). I am under the impression that this plugin already works in floating point and does not need modification. Gradient: Here again I find no difference with the original plugin. Again, I have the impression that the plugin already works in floating point. Overlay (shared effect): I don't notice any difference with the original plugin. Histogram Bezier: I tried extending the range similarly to Histogram (which works well in HDR, after modification). In this case I see no change. The code is much more complex and it is probably not enough to delete the CLAMP. The change I made is to the file "bistogram.C" line 361 I changed the value of 1.0 to 10.0. I also tried editing the file bistogramconfig.C line 110 e 111 I changed the value of 1.0 to 10.0. line 229 I changed the value of 1 to 10. I put these details because the plugin is very important for CC and I would love it if someone more experienced than me could make it work on out-of-range data as well. Besides, the plugin is not only a histogram but also uses the very important "Curves". For the Videoscope plugin I could not make changes because the code is too complicated for my skills; similarly to Histogram Bezier.
Finally I describe Color3Way, in which the modification worked. In the original plugin the color wheels already seems to work in floating point, but not the V bar of brightness values (which are clipped). With the modification the V bar also works on out-of-range data. The modification is as follows: File "color3way.C": line 281 I changed the value of 1.0 to 100.0. line 284 I changed the value of 1.0 to 100.0 (I have also tried other values, e.g., 10.0, and the clamp always works up to those values). The floating point calculation works for both the saturation bar and the V bar. With the tests done so far, I have had no problems or errors/warnings on the terminal.
I did the tests with exr images and then enabled the internal CinGG engine (but in the tests it also works with "ffmpeg first"). I set the color model to RGBA-FLOAT (inescapable: with integer 8-bit models you cannot have HDR) and the color range to 2020 NCL (but it works with all possible settings, not relevant). The graphics driver is X11 because with X11-OpenGL it does not work. Used patches: 0001-TEST-Simpler-unlimited-float-overlay.patch 0002-Allow-negative-numbers-in-overlayer.patch noclamp_in_histogram.diff Manual changes in color3way.C
I am happy with the success with Color3Way (as with Histogram) because I believe it will become increasingly important to work on HDR video in the future. On the other hand, I regret not having success with Curves (Histogram Bezier) because it is an essential plugin for CC.
Thanks for experiments! I wonder if anyone who worked on colour correction plugins in cinelerra still can be contacted? I do not feel very comfortable in this area, because some advanced usage of plugins/modes/rerouting already bite us earlier .... --
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Thanks Andrew; you and I have already talked about this at length, I hope there is someone knowledgeable enough to go through the Histogram Bezier code to find out how to overcome the "0 - 1.0" range. Another important (but probably even more complex) thing would be to be able to get your patches to work for the X11-OpenGL driver as well, which I think is the most widely used. Speaking of patches, can I ask you the favor of creating a patch that encapsulates the changes to histogram.C and color3way.C? A patch to be installed with "git am ..." (with a .patch extension). I am doing a lot of builds and it is tedious for me to edit the code manually. Finally, a consideration. Without your patches the RGBA-FLOAT color model is almost useless with plugins because it allows unclipped calculations only for Gamma and Blue Banana. With your patches almost all plugins work in floating point (even Videoscope, without the "smooth" option); only HistEQ and Histogram Bezier remain excluded. So I think your patches are an important addition to CinGG. Do you think it's better to try to make an appimage with your patches so that others can test them, or can we put them directly into git, since I've done a lot of testing by now without the slightest problem? Phyllis, what do you think? IgorBeg, Terje, Pierre and everyone else; what do you think?
пт, 1 дек. 2023 г., 23:59 Andrea paz <[email protected]>:
Thanks Andrew; you and I have already talked about this at length, I hope there is someone knowledgeable enough to go through the Histogram Bezier code to find out how to overcome the "0 - 1.0" range. Another important (but probably even more complex) thing would be to be able to get your patches to work for the X11-OpenGL driver as well, which I think is the most widely used.
Speaking of patches, can I ask you the favor of creating a patch that encapsulates the changes to histogram.C and color3way.C?
Well, I think you can do it yourself? git add plugins/color3way/color3way.C git add plugins/histogram/histogram.C git commit (it may ask you for name/email - just follow on-screen instructions - copy/paste commands setting name and email) then you might also check that EDITOR variable contain your favourite editor. I set it to mcedit, as ex-DOS user ( I can quit from vi, but this is about as much as I know!) After you commited changes this way you will see them in 'git log' So you can git format-patch {-o dirname } long_string_git_commit A patch to be
installed with "git am ..." (with a .patch extension). I am doing a lot of builds and it is tedious for me to edit the code manually.
Finally, a consideration. Without your patches the RGBA-FLOAT color model is almost useless with plugins because it allows unclipped calculations only for Gamma and Blue Banana. With your patches almost all plugins work in floating point (even Videoscope, without the "smooth" option); only HistEQ and Histogram Bezier remain excluded. So I think your patches are an important addition to CinGG. Do you think it's better to try to make an appimage with your patches so that others can test them, or can we put them directly into git, since I've done a lot of testing by now without the slightest problem?
I do not know how situation with free space on server going - may be we can replace previous test appimage with this new suggested one? I'll leave decision.to Sam and Phyllis .....
Phyllis, what do you think? IgorBeg, Terje, Pierre and everyone else; what do you think?
Sorry, I didn't have time to test anything and I don't know if I can see something on my screen because it is set/calibrated to sRGB only. I think the question could be,... would the changes for clipping in the plugins'code would be compatible with our old projects? IgorBeg Il 01/12/2023 21:59, Andrea paz via Cin ha scritto:
Thanks Andrew; you and I have already talked about this at length, I hope there is someone knowledgeable enough to go through the Histogram Bezier code to find out how to overcome the "0 - 1.0" range. Another important (but probably even more complex) thing would be to be able to get your patches to work for the X11-OpenGL driver as well, which I think is the most widely used.
Speaking of patches, can I ask you the favor of creating a patch that encapsulates the changes to histogram.C and color3way.C? A patch to be installed with "git am ..." (with a .patch extension). I am doing a lot of builds and it is tedious for me to edit the code manually.
Finally, a consideration. Without your patches the RGBA-FLOAT color model is almost useless with plugins because it allows unclipped calculations only for Gamma and Blue Banana. With your patches almost all plugins work in floating point (even Videoscope, without the "smooth" option); only HistEQ and Histogram Bezier remain excluded. So I think your patches are an important addition to CinGG. Do you think it's better to try to make an appimage with your patches so that others can test them, or can we put them directly into git, since I've done a lot of testing by now without the slightest problem?
Phyllis, what do you think? IgorBeg, Terje, Pierre and everyone else; what do you think?
вс, 3 дек. 2023 г., 11:41 Igor BEGHETTO via Cin <[email protected]
:
Sorry, I didn't have time to test anything and I don't know if I can see something on my screen because it is set/calibrated to sRGB only. I think the question could be,... would the changes for clipping in the plugins'code would be compatible with our old projects?
Well, I think it willbe hard to answer this without actual testing? I guess old projects ( I hope those changes only affect rgb(a) float projects) were build around this limitation in some way - because visual result of clipping is pure white area - something you hardly can miss. Now, more complex layer modes definitely should be affected - but not sure yet how normalization happened on video encode (where encoder await 8-10 bit per channel integer data). So, only testing might tell .... But in general current situation is not pretty, input information can be lost irreversibly (even if only for exr/tiff) and internal calculations easily can go into "everything is unrecoverably white" territory ... {sure, you can just undo all effects, no input media is affected, but this is IMO bad surprize for anyone who come to cin-gg especially for floating-point workflow. I guess it was just simplest/most speedy solution, that can be done at each pixel individually, instead of de/re-normalizing whole array, too bad it was discovered that late ....} I think there is possibility to creatively use even this - but I think we at very least should provide patches and big enough warning in project section of manual. IgorBeg
Il 01/12/2023 21:59, Andrea paz via Cin ha scritto:
Thanks Andrew; you and I have already talked about this at length, I hope there is someone knowledgeable enough to go through the Histogram Bezier code to find out how to overcome the "0 - 1.0" range. Another important (but probably even more complex) thing would be to be able to get your patches to work for the X11-OpenGL driver as well, which I think is the most widely used.
Speaking of patches, can I ask you the favor of creating a patch that encapsulates the changes to histogram.C and color3way.C? A patch to be installed with "git am ..." (with a .patch extension). I am doing a lot of builds and it is tedious for me to edit the code manually.
Finally, a consideration. Without your patches the RGBA-FLOAT color model is almost useless with plugins because it allows unclipped calculations only for Gamma and Blue Banana. With your patches almost all plugins work in floating point (even Videoscope, without the "smooth" option); only HistEQ and Histogram Bezier remain excluded. So I think your patches are an important addition to CinGG. Do you think it's better to try to make an appimage with your patches so that others can test them, or can we put them directly into git, since I've done a lot of testing by now without the slightest problem?
Phyllis, what do you think? IgorBeg, Terje, Pierre and everyone else; what do you think? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Hi Andrea, I haven't really used Cinelerra-GG or made video in over a year; I'm caught up with other things. I just have time to read the discussions on the list because I find them interesting and hope one day to get back to a more concrete use of Cinellerra-GG. All this to say that I don't think I'm in a good position to make a useful contribution to your questioning, which seems to me to be very important. The only thing I'd like to mention is that for a long time I've been wondering why the VideoScope Waveform doesn't show image levels that exceed 100%. Is it because these levels don't exist? Le 23-12-01 à 15 h 59, Andrea paz via Cin a écrit :
Finally, a consideration. Without your patches the RGBA-FLOAT color model is almost useless with plugins because it allows unclipped calculations only for Gamma and Blue Banana. With your patches almost all plugins work in floating point (even Videoscope, without the "smooth" option); only HistEQ and Histogram Bezier remain excluded. So I think your patches are an important addition to CinGG. Do you think it's better to try to make an appimage with your patches so that others can test them, or can we put them directly into git, since I've done a lot of testing by now without the slightest problem?
Phyllis, what do you think? IgorBeg, Terje, Pierre and everyone else; what do you think?
Hi Andrea, I haven't really used Cinelerra-GG or made video in over a year; I'm caught up with other things. I just have time to read the discussions on the list because I find them interesting and hope one day to get back to a more concrete use of Cinellerra-GG. All this to say that I don't think I'm in a good position to make a useful contribution to your questioning, which seems to me to be very important. The only thing I'd like to mention is that for a long time I've been wondering why the VideoScope Waveform doesn't show image levels that exceed 100%. Is it because these levels don't exist? Le 23-12-01 à 15 h 59, Andrea paz via Cin a écrit :
Finally, a consideration. Without your patches the RGBA-FLOAT color model is almost useless with plugins because it allows unclipped calculations only for Gamma and Blue Banana. With your patches almost all plugins work in floating point (even Videoscope, without the "smooth" option); only HistEQ and Histogram Bezier remain excluded. So I think your patches are an important addition to CinGG. Do you think it's better to try to make an appimage with your patches so that others can test them, or can we put them directly into git, since I've done a lot of testing by now without the slightest problem?
Phyllis, what do you think? IgorBeg, Terje, Pierre and everyone else; what do you think?
The only thing I'd like to mention is that for a long time I've been wondering why the VideoScope Waveform doesn't show image levels that exceed 100%. Is it because these levels don't exist?
Yes, on this aspect I have done many tests. Without Andrew's patches the scopes always show clipping 0 - 100%. With Andrew's patches, RGBA-FLOAT color model and X11 graphics driver; the scopes also show out-of-range values. The display stops at -10% or +110% but there is no clip, in fact by varying the brightness all out-of-range values become visible, even over 110%. The only caveat is to disable the "smooth" option which always causes clipping. One problematic consequence is the vectorscope also showing values outside the circle making its reading difficult, if not incorrect. https://streamable.com/obd7rv Consider that I used exr images from tests that have brightness values as high as 100 and above (compared to the usual 0 - 1.0 range); which is not realistic. I think the strange colors you see in the video are due to these excessive values; however, they could be an indication of some problem of CinGG to handle HDR.
@Andrew Thanks, with your instructions I was able to make the patch which I attach (along with yours) for those who want to test. I tried to build the appimage with the patches following the instructions in the manual, but I get to the following error: ./bld_appimage.sh: row 85: tools/makeappimage: No such file or directory I downloaded appimagetool-x86_64.AppImage from git and put it in .../cinelerra-5.1/tools giving it executables permissions. Inside the /tools folder that also a makeappappimagetool subfolder; I tried copying appimagetool-x86_64.AppImage here as well with the same results. I tried running the script tools/makeappimagetool/./bld.sh but I get an error. I attach the log. I can't figure out where I'm wrong.
пн, 4 дек. 2023 г., 16:39 Andrea paz via Cin <[email protected]>:
@Andrew Thanks, with your instructions I was able to make the patch which I attach (along with yours) for those who want to test.
I tried to build the appimage with the patches following the instructions in the manual, but I get to the following error:
./bld_appimage.sh: row 85: tools/makeappimage: No such file or directory
I downloaded appimagetool-x86_64.AppImage from git and put it in .../cinelerra-5.1/tools giving it executables permissions. Inside the /tools folder that also a makeappappimagetool subfolder; I tried copying appimagetool-x86_64.AppImage here as well with the same results.
I tried running the script tools/makeappimagetool/./bld.sh but I get an error. I attach the log.
I can't figure out where I'm wrong.
may be not you? https://github.com/linuxdeploy/linuxdeploy/issues/254 try to apply fix mentioned there ? --
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Thanks to Andrew's patch I was able to create an AppImage that has no clipping when using RGBA-FLOAT in X11. I thought of uploading it to Dropbox (I apologize for the security, if you want and request me I will try to upload it to transfer.sh). If you want to test it you are free to download it. One caveat: I created it on my Arch Linux, which is a Rolling, and I don't know if this leads to problems with the appimage working on other distros. It doesn't give me any problems on Arch. https://www.dropbox.com/scl/fi/eku6sto8nxapws4qxjri8/cin-HDR.AppImage?rlkey=...
Was working on this the past week and want to report back that I was able to get good results using hdr.tar file from Andrew and following Andrea's testing. But I still want to do more testing because I could not get the small_empty_room_1_4k.exr example to give me the same kind of results as Andrea displayed in his mp4 demo. And I do not know how to test the patch provided by Andrew for overlayframe.h. I am wondering if for now, if it would be sufficient to only apply the color3way and histogram patches and not the overlayframe.h patch (I did test color3way once without overlayframe.h patch and it seemed to work the same) because overlayframe.h is included in quite a few routines. I do need to do more tests also, because when testing using HDR_111_Parking_Lot_2.zip file, HDR_111_Parking_Lot_2_Ref.hdr, my laptop completely powered off 3 times when I cranked the Value all the way to the right in Histogram. However, this laptop has a bad memory bank so I suspect that was the cause. More later. Thanks to Andrew's patch I was able to create an AppImage that has no
clipping when using RGBA-FLOAT in X11. I thought of uploading it to Dropbox (I apologize for the security, if you want and request me I will try to upload it to transfer.sh). If you want to test it you are free to download it. One caveat: I created it on my Arch Linux, which is a Rolling, and I don't know if this leads to problems with the appimage working on other distros. It doesn't give me any problems on Arch.
https://www.dropbox.com/scl/fi/eku6sto8nxapws4qxjri8/cin-HDR.AppImage?rlkey=...
вт, 19 дек. 2023 г., 04:59 Phyllis Smith <[email protected]>:
Was working on this the past week and want to report back that I was able to get good results using hdr.tar file from Andrew and following Andrea's testing. But I still want to do more testing because I could not get the small_empty_room_1_4k.exr example to give me the same kind of results as Andrea displayed in his mp4 demo.
Be sure to set output driver to x11 from x11-opengl ?
And I do not know how to test the patch provided by Andrew for overlayframe.h.
well, if you put two similar video tracks (each having areas where component values go above 0.5f, so in summation they will be above 1.0f) on top of each other and set overlay mode to addition - you should get over 1.0f values in compositor ...... And I think if you render with internal EXR engine you will see on reload or via oiiotool that values in output file surely above 1.0f. I am wondering if for now, if it would be sufficient to only apply the
color3way and histogram patches and not the overlayframe.h patch (I did test color3way once without overlayframe.h patch and it seemed to work the same) because overlayframe.h is included in quite a few routines. I do need to do more tests also, because when testing using HDR_111_Parking_Lot_2.zip file, HDR_111_Parking_Lot_2_Ref.hdr, my laptop completely powered off 3 times when I cranked the Value all the way to the right in Histogram. However, this laptop has a bad memory bank so I suspect that was the cause.
Well, I wish you best luck in fixing that!
More later.
Thanks to Andrew's patch I was able to create an AppImage that has no
clipping when using RGBA-FLOAT in X11. I thought of uploading it to Dropbox (I apologize for the security, if you want and request me I will try to upload it to transfer.sh). If you want to test it you are free to download it. One caveat: I created it on my Arch Linux, which is a Rolling, and I don't know if this leads to problems with the appimage working on other distros. It doesn't give me any problems on Arch.
https://www.dropbox.com/scl/fi/eku6sto8nxapws4qxjri8/cin-HDR.AppImage?rlkey=...
In addition to what Andrew suggested, the easiest way to check whether CinGG reads data above 0 - 1.0f is to use the eyedropper. On the white parts of the image, if you have the clip you will always read the fixed value 1.0. If CinGG also supports HDR data you will read values above 1.0f, even though we still only see a pure white in the compositor. Another way is to open scopes and disable the "smooth" option. We will see the values go beyond the 0 - 100 range.
Loading an actual HDR file on Debian 9.1-32-bit hangs when I just drag Color3way, Histogram, OR any of the other similar video plugins over. So it is not a problem specific to the patches in Color3way or Histogram but something in the plugin code. HistEq and Histogram Bezier also hang and there was no mod in them. However, AgingTV worked! Error is: dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit It does not crash, just stops doing anything. I forgot to test on Ubuntu 16. There are multiple operating systems on a single desktop computer so I have to take 1 O/S down in order to boot the other one. Not a whole lot working right for me today. ( still have to test via the following suggestion). On Tue, Dec 19, 2023 at 2:27 AM Andrea paz <[email protected]> wrote:
In addition to what Andrew suggested, the easiest way to check whether CinGG reads data above 0 - 1.0f is to use the eyedropper. On the white parts of the image, if you have the clip you will always read the fixed value 1.0. If CinGG also supports HDR data you will read values above 1.0f, even though we still only see a pure white in the compositor. Another way is to open scopes and disable the "smooth" option. We will see the values go beyond the 0 - 100 range.
пт, 22 дек. 2023 г., 02:47 Phyllis Smith <[email protected]>:
Loading an actual HDR file on Debian 9.1-32-bit hangs when I just drag Color3way, Histogram, OR any of the other similar video plugins over. So it is not a problem specific to the patches in Color3way or Histogram but something in the plugin code. HistEq and Histogram Bezier also hang and there was no mod in them. However, AgingTV worked! Error is:
dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit dbg_add, dup 00000000ffffffff 10DirectUnit 10DirectUnit
well, strange. I only have Slackware 32bit build from Oct,1 and I can drag plugins over exr file just fine .... But Slackware has new (gcc 11.2.0) compiler. On the other hand, it seems HistEq plugin does not work in rgba-float giving all black image .... More we test .... :) :( more bugs/strangeness surface!
It does not crash, just stops doing anything. I forgot to test on Ubuntu 16. There are multiple operating systems on a single desktop computer so I have to take 1 O/S down in order to boot the other one.
Not a whole lot working right for me today.
( still have to test via the following suggestion).
On Tue, Dec 19, 2023 at 2:27 AM Andrea paz <[email protected]> wrote:
In addition to what Andrew suggested, the easiest way to check whether CinGG reads data above 0 - 1.0f is to use the eyedropper. On the white parts of the image, if you have the clip you will always read the fixed value 1.0. If CinGG also supports HDR data you will read values above 1.0f, even though we still only see a pure white in the compositor. Another way is to open scopes and disable the "smooth" option. We will see the values go beyond the 0 - 100 range.
Checked into GIT based on the considerable testing by Andrea as noted below. Finally, a consideration. Without your patches the RGBA-FLOAT color
model is almost useless with plugins because it allows unclipped calculations only for Gamma and Blue Banana. With your patches almost all plugins work in floating point (even Videoscope, without the "smooth" option); only HistEQ and Histogram Bezier remain excluded. So I think your patches are an important addition to CinGG. Do you think it's better to try to make an appimage with your patches so that others can test them, or can we put them directly into git, since I've done a lot of testing by now without the slightest problem?
Phyllis, what do you think?
I think the addition is good and hopefully will not cause any unforeseen issues. I did test a little just to see what the results would be.
Andrea, could you check this statement for correctness and fix it and/or add to it for Color3way and Histogram for the Manual? I would like to add it to the bottom of that Plugin in Plugins.tex if you approve it. Should the statement be the same for each of them or should there be some difference? Thank you in advance, Phyllis On Fri, Dec 1, 2023 at 8:59 AM Andrea paz via Cin < [email protected]> wrote:
I tried to make other changes to the plugins for Color Correction to be able to make it also see out-of-range (HDR) values and be able to change them.
Oops, forgot to add the statement. When using the X11 graphics driver, this plugin allows for greater than 1 values to accomodate HDR. The display will stop at -10\% or +110\%, but there is no clipping. By varying the brightness all out-of-range values become visible, even over 110\%. However for Videoscope, you must disable the "smooth" option which always causes clipping. The color model should be set to RGBA-FLOAT (because you cannot have HDR with integer 8-bit models). This does not work when using X11-OpenGL at this time. On Sun, Jan 21, 2024 at 1:24 PM Phyllis Smith <[email protected]> wrote:
Andrea, could you check this statement for correctness and fix it and/or add to it for Color3way and Histogram for the Manual? I would like to add it to the bottom of that Plugin in Plugins.tex if you approve it. Should the statement be the same for each of them or should there be some difference? Thank you in advance, Phyllis
On Fri, Dec 1, 2023 at 8:59 AM Andrea paz via Cin < [email protected]> wrote:
I tried to make other changes to the plugins for Color Correction to be able to make it also see out-of-range (HDR) values and be able to change them.
I no longer remembered that the floating-point patches were put into git. I adjusted and added the statement to the two plugins. See if they fit. I attach plugins.tex
What about Histogram? where you changed/tested CLAMP as shown below? if( !EQUIV(config.gamma[mode], 0) ) { output = pow(output, 1.0 / config.gamma[mode]); - CLAMP(output, 0, 1.0); *+ CLAMP(output, 0, 100.0);* } If you make another change, just send me the changed paragraph instead of the entire Plugins.tex file. On Sun, Jan 21, 2024 at 3:08 PM Andrea paz <[email protected]> wrote:
I no longer remembered that the floating-point patches were put into git. I adjusted and added the statement to the two plugins. See if they fit. I attach plugins.tex
Sorry for the forgetting and the delay. In manual, Histogram plugin, in the first paragraph under the figure 10.46, change to: The Histogram is always performed in floating point RGB regardless of the project color space, but with clipping at 1.0. When using the X11 graphics driver and RGBA-FLOAT color model, Histogram allows you to display greater than (0 - 1.0f) values to accomodate HDR. This does not work when using X11-OpenGL because it is an 8-bit limited driver. The display will stop at +110\%, but there is no clipping. By lowering the brightness all out-of-range values become visible, even those initially above 110\%. The histogram has two sets of transfer parameters: the \textit{input transfer} and the \textit{output transfer}... Note1: the start of the second paragraph I put in to show the space between the two paragraphs, but it remained unchanged in content. Note2: In Color3way and Videoscope, can you change (0 - 1.0) in (0 - 1.0f)?
Checked manual changes into GIT as Andrea provided. Also, added libsvtav1 as option to build in Developer.tex. In manual, Histogram plugin, in the first paragraph under the figure
10.46, change to: ... The histogram has two sets of transfer parameters: the \textit{input transfer} and the \textit{output transfer}... ... Note2: In Color3way and Videoscope, can you change (0 - 1.0) in (0 - 1.0f)?
participants (5)
-
Andrea paz -
Andrew Randrianasulu -
Igor BEGHETTO -
Phyllis Smith -
Pierre autourduglobe