View Full Version : GamMac v1.10 - 15 June 2018
videoFred
10th March 2017, 12:21
I got it working Bernardd!
I'm using it with AvsPmod so it's easy to change parameters.
I have no time now, but later I will compare the results with the GamMac results.
Perhaps we should start a new thread about your script only?
I do not want to hijack this thread.
Fred.
Bernardd
10th March 2017, 20:24
Fred,
I suggest you use the RGBAdapt v0.3 plugin 17 June 2015 thread, because my script exists through this plugin.
This of course, if my script writing teacher, Mr. StainlessS, agrees.
Bernard
StainlessS
10th March 2017, 21:19
Bernardd, it would have been a good idea right from the start to have your own thread for your awb.
Mobile
EDIT: It does deserve it.
StainlessS
14th March 2017, 14:15
OK, no real consistent way I can think of to detect if eg RED in fireplace kids romp suits is due to color cast or because its supposed to be red,
(red min is not reliable detection compared to grn, blu, min).
The GamMac 'thing', is intended to detect and correct color cast and so will produce color shift by intention.
Playing with Th can perhaps improve results some (Th of default 0.04%, intended to ignore a few noise pixels).
Setting Th, to value of 0.0 (not ignoring of a few noise pixels, detect real min,max pixels in image), to avoid over contrast'ed result.
Setting Th, to value of -1.0, sets input min=0, max=255, ie no input scaling, full input range.
Perhaps default Th should be 0.0 to detect real min,max pixel values, make user select Th to ignore when required
(what say you Fred ?, Th=0.0 is least destructive).
Here some results with non default Th.
Th= -1.0 (All 3 Scale results identical due to full range input 0->255)
https://s20.postimg.cc/51kbaej5p/Th-1_zpshd9uspff.png (https://postimg.cc/image/vze8c53sp/)
Th=0.0 (Scale=1 looking best to me, best color shift, perhaps better still with omin=0, and omax=255, bit more contrast)
https://s20.postimg.cc/s4au9kkn1/Th0_zpsqcfnrx83.png (https://postimg.cc/image/4q2uxn2pl/)
Th=-1.0 (All 3 Scale results identical due to full range input 0->255)
https://s20.postimg.cc/4rcsr24jh/Kids-_Th-1_zpslxy4mgx3.png (https://postimg.cc/image/afj3hy8vt/)
Th=0.0 (IN: is the min and max RAW: input, of any channel, for Scale=0 and 1)
https://s20.postimg.cc/ubf2xhpx9/Kids-_Th0_zps6dbsc71c.png (https://postimg.cc/image/433y845tl/)
NOTE, where Th= -1.0, all output results same (Scale dont matter), input range is 0->255, however outputs are in above case
range omin(5) -> omax(250) to allow headroom for tweak.
EDIT: Note, the fireplace image, the source fireplace seems a little pink to me (so do the kids faces).
EDIT: Above are by no means perfect, but suggest maybe that Th=0.0 should be default.
The R,G and B Mul args have not been used above, but could provide further correction where needed.
EDIT: All above using non default LockChan= -2, ie Scaled Channel Average (as in John Meyer's post).
EDIT: John, are you really capping in YUV 411, as per sample AVI (would not RGB be better, or was 411 just for post) ?
Magik Mark
8th April 2017, 05:57
Not sure if this has been answered. Can I use this in staxrip? Planning to experiment this with HD videos and see if I could still improve the image
Sent from my iPhone using Tapatalk
StainlessS
8th April 2017, 13:19
Can I use this in staxrip?
It is just an Avisynth plugin filter, assuming staxrip can use Avisynth filters, then I dont see any problem.
Sorry, no idea, never used StaxRip myself, perhaps someone else could give better answer.
Groucho2004
8th April 2017, 13:41
Sorry, no idea, never used StaxRip myself, perhaps someone else could give better answer.
I have not used it either but I do know that it uses 64 bit Avisynth only which means no, you can't use this filter with staxrip.
Magik Mark
8th April 2017, 14:23
Is it possible to recompile a 64bit version?
Thanks
StainlessS
8th April 2017, 14:34
I'll give it a go, but your gonna have to be the tester (I'm on XP32).
Magik Mark
8th April 2017, 15:01
Thanks guys [emoji106]
Sent from my iPhone using Tapatalk
Groucho2004
8th April 2017, 15:20
Is it possible to recompile a 64bit version?
Here it is (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0) (modified source included).
Necessary source modifications:
- Latest AVS+ headers
- Entry point updated to AvisynthPluginInit3.
StainlessS
8th April 2017, 16:14
Cheers Grouchy, having trouble re-installing Platform SDK, (64bit was not installed, and keeps telling me it cant find some readme type html, then gives up with error,
the file it cant find is exactly where is says it looked so error is a mystery).
Magik Mark
9th April 2017, 00:20
Thanks for the 64bit!
I will be doing some experiment on HD sources. Just would like to clarify the ff:
1. Convert video first to RGB. Is it RGB24 or RGB 32?
2. Run GamMac
3. Convert back to YV12
Am I right?
StainlessS
9th April 2017, 00:56
Yes, GamMac works only in RGB (either flavour), and back to YV12, if that is what you require.
Magik Mark
9th April 2017, 05:21
Thanks a lot [emoji106]
Sent from my iPhone using Tapatalk
Magik Mark
11th April 2017, 00:22
Works very well and fast in staxrip. Experimented with HD videos with "green and red push", it almost cleared them away.
Is there a way to minimize the "clearing" of color cast? Movies like the matrix is intentionally greenish. However, it improves shadow detail significantly
StainlessS
11th April 2017, 01:24
Is there a way to minimize the "clearing" of color cast? Movies like the matrix is intentionally greenish.
Yep, dont use it.
The whole purpose is to correct those that are eg un-intentionally greenish, why would you be using it on non faded clips ?
Magik Mark
11th April 2017, 02:31
Well, it also improve shadow details
Sent from my iPhone using Tapatalk
StainlessS
11th April 2017, 19:03
You would get better results using some plug intended for your requirement, eg AutoLevels [EDIT: AutoAdjust] ,
HdrAgc, SmoothAdjust, or similar.
videoFred
12th April 2017, 12:19
I have done some more testings lately.
To avoid over-adjusting on problematic scenes like complete black frames, scenes with blue sky etc, I'm using a special prepared detect clip.
Here I added some pure black and pure white pixels to the detect clip. Size from the squares can be set with AvsPmod sliders.
http://www.super-8.be/Doom/GamMac_New_detect_01.jpg
http://www.super-8.be/Doom/GamMac_New_detect_02.jpg
This works very well to "soften" the Gammac adjusting on dark and/or complete black frames. And also on frames with a lot of pixels with the same color.
But when it comes to color corrections, we must use another trick. :D
This code will calculate the average color from a frame, and then invert it:
Average = baseclip.ScriptClip(""" u=round(AverageChromaU()) v=round(AverageChromaV()) BlankClip(last, color_yuv=65536*128 + 256*u + v) """).invert()
If we now make a square from it and add it to the detect clip, we get this:
http://www.super-8.be/Doom/GamMac_New_detect_05.jpg
As you see, colors are now correct and GamMac is still adusting contrast very well. With correct size settings, the colored square can stay on the detect clip on an entire clip,
even on not problematic scenes. Then the effect is negligible.
Some more examples:
http://www.super-8.be/Doom/GamMac_New_detect_03.jpg
http://www.super-8.be/Doom/GamMac_New_detect_04.jpg
And last but not least Johns legendaric fireplace frame:;)
http://www.super-8.be/Doom/GamMac_New_detect_06.jpg
As you see I'm using ScriptClip for calculating the average color. But unfortunately ScriptClip is not working in Avisynth+ when in MT mode. Do we have an alternative for ScriptClip?
Fred.
StainlessS
12th April 2017, 14:41
Average = baseclip.ScriptClip(""" u=round(AverageChromaU()) v=round(AverageChromaV()) BlankClip(last, color_yuv=65536*128 + 256*u + v) """).invert()
So both input and output are YUV, and also output same size as BaseClip ? (GamMac is RGB only).
I'll see what I can come up with, I'll leave any Invert() and resize to other filters.
EDIT: Standard 8 bit in/out only, also not gonna do a v2.5 plug, 2.6 only.
StainlessS
12th April 2017, 16:52
FredAverage, (not to be confused with RedAverage).
Avisynth v2.6 only plugin.
ColorSpace, YV12, YV16, and YV24 only.
Return clip U and V will be channel averages. Result luma Y will depend upon Y arg.
FredAverage(clip c, int "Y")
Y, Default -1 == sampled average. Otherwise (0 -> 255) Luma Y set to given Y.
Returns clip same colorspace and size as input.
EDIT: Oops, should have mentioned that U and V are sampled averages. BLUE text added.
EDIT: source code
/*
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
// FredAverage v 0.0
#include "Compiler.h"
#include <windows.h>
#include <stdio.h>
#include "avisynth.h"
class FredAverage : public GenericVideoFilter {
const int Luma;
public:
FredAverage(PClip _child,int _luma,IScriptEnvironment* env) : GenericVideoFilter(_child), Luma(_luma) {}
~FredAverage(){}
PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env);
};
PVideoFrame __stdcall FredAverage::GetFrame(int n, IScriptEnvironment* env) {
n = (n<0) ? 0 : (n>= vi.num_frames) ? vi.num_frames - 1 : n; // range limit n
PVideoFrame src = child->GetFrame(n, env);
int x,y;
int setY = Luma;
if(setY < 0) {
const int spitch = src->GetPitch(PLANAR_Y);
const int sheight = src->GetHeight(PLANAR_Y);
const int srowsize = src->GetRowSize(PLANAR_Y);
const BYTE * srcp = src->GetReadPtr(PLANAR_Y);
__int64 acc = 0;
unsigned int sum = 0;
for(y=sheight;--y>=0;) { // sum y
for(x=srowsize;--x>=0;) {
sum += srcp[x];
}
if(sum & 0x80000000) { acc += sum; sum=0; }
srcp += spitch;
}
acc += sum;
int ysamples = srowsize * sheight;
setY = int(double(acc) / ysamples + 0.5); // y average
}
const int spitchUV = src->GetPitch(PLANAR_U);
const int sheightUV = src->GetHeight(PLANAR_U);
const int srowsizeUV = src->GetRowSize(PLANAR_U);
const BYTE * srcpU = src->GetReadPtr(PLANAR_U);
const BYTE * srcpV = src->GetReadPtr(PLANAR_V);
__int64 accU = 0,accV = 0;
unsigned int sumU = 0,sumV = 0;
for(y=sheightUV;--y>=0;) { // sum u and v
for(x=srowsizeUV;--x>=0;) {
sumU += srcpU[x];
sumV += srcpV[x];
}
if(sumU & 0x80000000) { accU += sumU; sumU=0; }
if(sumV & 0x80000000) { accV += sumV; sumV=0; }
srcpU += spitchUV;
srcpV += spitchUV;
}
accU += sumU;
accV += sumV;
int samples = srowsizeUV * sheightUV;
int aveU = int(double(accU) / samples + 0.5); // u an v averages
int aveV = int(double(accV) / samples + 0.5);
//
PVideoFrame dst = env->NewVideoFrame(vi);
const int dpitch = dst->GetPitch(PLANAR_Y);
const int dheight = dst->GetHeight(PLANAR_Y);
const int drowsize = dst->GetRowSize(PLANAR_Y);
BYTE * dstp = dst->GetWritePtr(PLANAR_Y);
for(y=dheight;--y>=0;) { // set return clip luma to setY (tested average or user set)
for(x=drowsize;--x>=0;) {
dstp[x] = setY;
}
dstp += dpitch;
}
const int dpitchUV = dst->GetPitch(PLANAR_U);
const int dheightUV = dst->GetHeight(PLANAR_U);
const int drowsizeUV= dst->GetRowSize(PLANAR_U);
BYTE * dstpU = dst->GetWritePtr(PLANAR_U);
BYTE * dstpV = dst->GetWritePtr(PLANAR_V);
for(y=dheightUV;--y>=0;) { // set return clip U and V to rounded average of source.
for(x=drowsizeUV;--x>=0;) {
dstpU[x] = aveU;
dstpV[x] = aveV;
}
dstpU += dpitchUV;
dstpV += dpitchUV;
}
//
return dst;
}
AVSValue __cdecl Create_FredAverage(AVSValue args, void* user_data, IScriptEnvironment* env) {
PClip child = args[0].AsClip();
const VideoInfo &vi = child->GetVideoInfo();
if(!(vi.IsYV12() || vi.IsYV16() || vi.IsYV24())) env->ThrowError("FredAverage: YV12, YV16 and YV24 Only");
if(vi.width==0) env->ThrowError("FredAverage: Clip has no video\n");
int y=args[1].AsInt(-1); // WAS int y=args[0].AsInt(-1);
if(y < -1 || y> 255) env->ThrowError("FredAverage: Illegal Y arg(%d)\n",y);
return new FredAverage(child,y,env);
}
/* New 2.6 requirement!!! */
// Declare and initialise server pointers static storage.
const AVS_Linkage *AVS_linkage = 0;
/* New 2.6 requirement!!! */
// DLL entry point called from LoadPlugin() to setup a user plugin.
extern "C" __declspec(dllexport) const char* __stdcall
AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {
/* New 2.6 requirment!!! */
// Save the server pointers.
AVS_linkage = vectors;
env->AddFunction("FredAverage", "c[y]i", Create_FredAverage, 0);
return "`FredAverage' FredAverage plugin";
// A freeform name of the plugin.
}
EDIT: Attachment removed. Fixed in BLUE.
videoFred
12th April 2017, 18:58
So both input and output are YUV, and also output same size as BaseClip ? (GamMac is RGB only).
Of cource I change color space from input and detect clip to RGB before running GamMac. BaseClip is the cropped source clip as you can see in the examples. But GamMac is applied on the full size source clip.
Fred.
videoFred
12th April 2017, 19:03
FredAverage
;) Thank you very much Sir StainlessS!
Fred.
StainlessS
12th April 2017, 19:17
Fred, I made y=-1, the default to be more generally useful.
Mobile.
videoFred
12th April 2017, 19:37
Fred, I made y=-1, the default to be more generally useful.
Mobile.
It works fine in default StainlessS!
I have played with Y but I see no difference?
Fred.
StainlessS
12th April 2017, 19:52
If you set y to eg 16, then should be pretty much black result of FredAverage, but with illegal yuv combinations.
(Unless bugged).
Mobile.
Edit: OK I understand that you mean for gamac use it still works like y= 128.
StainlessS
12th April 2017, 20:24
Fred, would rgb average be preferable, instead, with/without built in invert ?
videoFred
12th April 2017, 22:07
Fred, would rgb average be preferable, instead, with/without built in invert ?
I do not know... But perhaps RGB average would be more accurate because we are working in RGB for GamMac anyhow? Build in invert would be nice too.
Fred.
StainlessS
14th April 2017, 00:42
Fred, have posted FredAverage(), as new plugin here:- https://forum.doom9.org/showthread.php?t=174520
Unfortunately, original version v0.0 was broken, removed (used args[0].AsInt(-1) instead of args[1].AsInt(-1), ie accessed clip instead of 'Y' arg).
Guess I was in too big a hurry to catch my bus ( sorry :( ).
Anyways, original attachment removed, but left [EDIT: fixed] source in-situ, perhaps of some use.
New version linked, copes with All v2.6 standard colorspaces.
videoFred
14th April 2017, 09:31
Thank you StainlessS! :thanks:
I will ask the Belgian Monks to brew a special beer for you :D
Fred.
CkJ
14th April 2017, 15:24
Original
https://i.imgbox.com/R2IZvxV2.png
Gammac
https://i.imgbox.com/pJHB7GDp.png
Gammac with FredAverage detect clip
https://i.imgbox.com/xp7I6Zav.png
I still get some chroma bugs. Is there any way to fix it? :thanks:
StainlessS
15th April 2017, 03:20
My attempt was no better than yours.
Here some of GamMac demo settings
Imagesource("Original.png",end=0)
ConvertToRGB24.KillAudio
O=Last
DC=Last
# Test DC can be different size
#DC=DC.Blur(1.0).BilinearResize(320,240) # Detection Clip Can be different size(uses source clip if dc not supplied, Denoised or whatever)
LockChan = 1 # Chan for lock to Ave, 0=R, 1=G, 2=B
# -1 = Use LockVal below.
# -2 = LockVal=(RedAve+GrnAve+BluAve)/3.0 for LockVal.
# -3 = LockVal=Median(RedAve,GrnAve,BluAve)
Scale=0
RedMul = 1.0 # Required Ave multiplier for Red Channel, applied when requesting GuessGamma(reqAve*RedMul), Even applied when LockChan=-1.
GrnMul = 1.0 # Same for Green channel. GrnMul even applies when LockChan is Green Channel, etc for chans.
BluMul = 1.0 # Same for Blue channel. Allows tinkering/fine tuning.
Th = 0.0
LockVal = 128.0 # Only valid if LockChan == -1
RngLim = 11
GamMax = 10.0
Show = True # Metrics
Verb = 5 # Verbocity FULL
SHOWCOORDS=true # Show DC detect clip instead of original
x =5 # Coords (for dc Detection Clip)
y =5
w=-5
h=-5
SZ=196
DBLK=DC.Crop(x,y,w,h).FredAverage(true).BilinearResize(SZ,SZ)
DC=DC.Overlay(DBLK,x=(Dc.Width-DBLK.Width)/2+48,y=(Dc.Height-DBLK.Height)/2+64)
omin=0 # Output channels minimum
omax=255 # Output channels maximum
https://s20.postimg.org/ktfbxg48t/Mod_zpssgegfu57.png (https://postimg.org/image/cb5vt3xq1/)
For the grassy/seaweed bits, looks to me like maybe YUV quantizer has thrown away a lot of the detail and when removing color cast, you are left
with a chroma blob. Nasty red halo too around the figure.
No idea what to do with it.
CkJ
15th April 2017, 11:22
Hi StainlessS,
I would like to use GamMac for non old 8mm films. I realized that gammac give me a better result than original if fredaverage(invert=false) detect is blue. So how can I apply GamMac only when fredaverage(invert=false) detect is blue? :thanks:
Original
https://i.imgbox.com/lXTAijjP.png
https://i.imgbox.com/D6D2Kmsn.png
https://i.imgbox.com/OCXy3haY.png
FredAverage(invert=false)
https://i.imgbox.com/zhiGSR2v.png
https://i.imgbox.com/wn4t3cnZ.png
https://i.imgbox.com/pRkOGTCj.png
GamMac
https://i.imgbox.com/pHXk5lYT.png
https://i.imgbox.com/aU1B2YD9.png
https://i.imgbox.com/Y8OvVAVW.png
StainlessS
15th April 2017, 12:17
The whole purpose of the FredAverage() plug is to inhibit GamMac() a little, and so must have Invert=true to work.
The Default of Invert=false is because that seems to be more generally useful (not for GamMac).
With Invert=false, it would probably have little effect, GamMac works already on the frame averages, and that is what FredAverage gives as result, so, probably waste of time doing that. GamMac with FredAverage(invert=false), is useless.
EDIT: You could probably replace ALMOST all of the detect clip with FredAverage(Invert=False) and find very little difference,
so long as there were some R, G, and B minimums and maximums that were close to those in the original dclip.
FredAverage(Invert=true), is actually a very good solution to provide FeedBack into the loop, to dampen
the GamMac effect, it is easily controllable via user sizing of FredAverage clip, (with maybe sliders in AvsPMod), and feedback
changes with every frame, to do similar via some additional args to GamMac would be tricky and a lot less easy to use than
Fred's solution (nice one Fred) .
CkJ
15th April 2017, 13:01
You're right, FredAverage(invert=false) is useless for GamMac. But my original meaning is not say about that. I meant if I can use FredAverage as a ConditionalFilter to apply GamMac when needed or not. If yes then how to do? :)
StainlessS
15th April 2017, 13:17
Nope, it dont do that, it just provides a clip with frame average color (or inverted), no other functionality.
No idea how you would implement some magical conditional filter that knows when a frame looks wrong.
EDIT: And your frames looked just fine to me, looked like the blueness was intentional for atmosphere .
videoFred
15th April 2017, 19:32
I have no time to show an example now, but it works much better when the result of FredAverage() is added to the detect clip as a random border, instead of a square box in the middle of the picture. I create the border by making a FredAverage clip from the source file, then resize and align the detect clip in the middle of the FredAverage clip. This way, I can create borders starting from 2 to..... pixels.
Fred.
StainlessS
16th April 2017, 16:43
I have no time to show an example now, but it works much better when the result of FredAverage() is added to the detect clip as a random border, instead of a square box in the middle of the picture.
Not sure that the above can be correct, only the area of the FredAverage clip (in relation to the detect clip area) could have any effect. But it may be preferable to see the detect clip center region rather than a square blob of color.
EDIT:
You may have to be careful if using given demo script,
[ie give dclip coords to GamMac as 0,0,0,0 if already cropped off border rubbish and replaced with FredAverage border,
otherwise GamMac will ignore dclip coords of FredAverage border].
videoFred
16th April 2017, 21:00
Not sure that the above can be correct, only the area of the FredAverage clip (in relation to the detect clip area) could have any effect. But it may be preferable to see the detect clip center region rather than a square blob of color.
Yes, I have not explained well. :o
Of cource the detect clip IS the FredAverage clip with the overlay. First, I crop the source clip to the coords I want. This is the source clip for FredAverage. Then I create the FredAverage clip. Then I resize the already cropped source clip, and overlay it (aligned to the center) over FredAverage.
Here we go:
Baseclip = dirt.crop(borderV,borderH,-borderV,-borderH,align=true).bicubicresize(newWfast,newH4)
Average= baseclip.FredAverage(invert=true)
Over = baseclip.bicubicresize(width(baseclip)-(al2)*2,height(baseclip)-(al2)*2)
Detect= overlay (Average, Over, x=al2,y=al2).converttoRGB24(matrix="rec709")
Dirt= source with Removedirt()
BorderV and borderH = coords for GamMac
NewWfast and NewH4 = I prefer a fixed size for the GamMac detect clip because my source can be very different in size. NewWfast is fixed to 608 pixels, NewH4 is calculated before in the script to have the same aspect ratio as the source.
Al2 is the width from the wanted borders, or you could say the amount of the feedback to the GamMac loop.
EDIT:
You may have to be careful if using given demo script,
[ie give dclip coords to GamMac as 0,0,0,0 if already cropped off border rubbish and replaced with FredAverage border,
otherwise GamMac will ignore dclip coords of FredAverage border].
Correct. I was aware of this. :)
Fred.
videoFred
28th April 2017, 18:28
For some strange reason FFMpeg is not opening Avisynth scripts with GamMac().
I get no FFMpeg error message: it's freezing.
The same scripts are opening fine when GamMac() is disabled.:confused:
EDIT: it' the last version of Gammac that causes the problem: vs 1.07
version 1.06B6 is running fine in FFMpeg
Fred.
StainlessS
29th April 2017, 12:24
Fred, I see you there.
Can you give script, ffmpeg command, and ffmpeg version please.
How long before freeze, straight away or some time into encode ?
videoFred
29th April 2017, 13:09
Hello StainlessS,
I will do this as soon as possible. ;)
Edit: the freeze is straight away.
Fred.
StainlessS
29th April 2017, 15:05
I'm not having any problems with it.
Here a mod I've was working on but with some debug output (dll In the DEBUGGING folder),
wiithout debugging in folder root).
Try without first, if problems then PM me link to some of the debug output.
You would need DebugView to capture debug output (from sysInternals [MicroSoft] Google it).
Here, temp link:- LINK DELETED
EDIT: Well actually just need last few hundred lines of debugging (very last line will probably tell where problem is).
videoFred
29th April 2017, 19:35
First, I'm using this simple testscript:
A = Avisource("Z:\VDP\VdP_Sp2.avi").converttoRGB24().trim(0,100)
B = A.Gammac()
B
And this ffmpeg command line:
ffmpeg -i test.avs -c:v prores -profile:v 3 -an c:\output.mov
pause
As said before, ffmpeg is freezing at the very start with GamMac v1.07, but it works fine with GamMac v1.06B6.
Now I'm going to test the GamMac 1.8beta testbuild asap.
Fred.
StainlessS
30th April 2017, 10:05
Thanks Fred, I think I know what I did wrong, silly mistake (corrected in 1.8B).
I'll have a bit more of a play and post update.
StainlessS
30th April 2017, 12:59
Fred,
Note, some of the effects of the blk/wht blocks thing could be achieved by changing Th and/or Scale.
It gives a little more info if RAW R,G,B values are shown in metrics (Verbosity>=4, the real mins/maxs) without taking
Th into consideration.
Also Note, the FLAGS (and color) on the "n] Flags:- 1SR LockVal=69.000" line show the used mode for the individual
frame (which can change because of low input range, or eg full scale input range, whether real, or improvised via
Black/White blocks)
(The Flags on post #120 show what the Blk/Wht Blocks forced).
EDIT: Blk/Wht blocks will most likely (depending upon size) force full scale input range, ie scale=0
(so Scale setting of non zero ignored and set as if scale=0 for every individual frame)
EDIT :
Scale=1 [scale all channels to Min(R,G,B) and Max(R,G,B)].
Scale=1, is exactly same as scale=0 when all channels minimums are 0, and all channels maximums are 255.
Setting Scale=1, and Th=0.0, would be to some degree self adjusting,
and would switch to showing Scale Flag as Scale=0 when Min(R,G,B)==0, and Max(R,G,B)==255, Blk,wht blocks (if big enough, Th dependent)
would always set Scale=0, for every frame, so may as well just set Scale=0 and forget about the blk,wht blocks.
In post #120, all three images use scale=2, but 2 of them use blk,wht blocks to change to scale=0, the cat image is an exception and
stays scale=2 for some reason, I would be interested to see result of scale=1 and scale=0 when Th=0.0. (and with Verbosity=4).
# -----------------
# -----------------
# -----------------
From Post #104
Perhaps default Th should be 0.0 to detect real min,max pixel values, make user select Th to ignore when required
(what say you Fred ?, Th=0.0 is least destructive).
...
EDIT: Above are by no means perfect, but suggest maybe that Th=0.0 should be default.
The R,G and B Mul args have not been used above, but could provide further correction where needed.
Permission to change default Th to 0.0 requested (If you think a good idea, see post #104 again).
EDIT: Default Th, currently 0.04%.
EDIT: Th=0.0, avoids big mistakes in eg JohnMeyer KidsInRedRomperSuits color shift (Especially for Scale=2). (user can always change to Th=0.04 if required).
If DC already denoised, then Th=0.0 is a real good idea.
EDIT: I think I'll also change valid input range of GamMax from 2.0 -> 10.0 to 1.0 < GamMax <=10.0, might be useful not just as
Guess range limiter, but also as a correction/colorshift limiter. (will likely need some experimentation to see if of any worth).
EDIT: "Matt_Greece_002.png", might look better (contrast) with 0.0 < Th.
EDIT: Have implemented GamMax limiter, 1.0 < GamMax <=10.0, and now also shows G flag on top line, hi-lited if
Gamma correction has been limited by GamMax for current frame (limited to GamMax or 1.0/GamMax).
StainlessS
30th April 2017, 16:07
Fred, see prev post.
Here, GamMac() v1.08Beta2, with new default Th=0.0, in anticipation of your acceding to my request.
Also, new valid range mod GamMax, 1.0 < GamMax <= 10.0, gamma correction limiting functionality.
Here (Beta will be lifted if you accede to my request, otherwise original Th=0.04 will be reinstated.):- LINK REMOVED
Th, Default 0.00 Sets Default for loTh and hiTh. Suggest Default, 0.00(percent). [-1.0(OFF) , or 0.0 -> 1.0]
...
GamMax, default 10.0 Upper value for guess gamma [1.0 < GamMax <= 10.0]
Starting guess upper range and limit for gamma estimator.
The lower guess range and limit will be set to 1.0 / GamMax, by default 0.1.
v1.08Beta2, Now allowing lower limit of GamMax to go as low as almost 1.0, GamMax now usable as
a gamma correction limiting device, where correction not allowed to exceed GamMax or go lower than
its reciprocal ie 1.0/GamMax. 'G' limited flag now added to flags line in metrics, hi-lited if Gamma
limited by GamMax (limiting includes any Red,Grn,BluMul, multiplier result).
...
Upper frame metrics shown as eg:- (when Verbosity=5=FULL)
nnnnn] Flags:- 1SRG
R G B
RAW: 10,253 10,253 10,253
IN: 10,253 10,253 10,253
IN_AVE: 78.466 88.552 78.767
SCALED: 71.847 82.431 72.162
GAMMA: 1.135 1.000 1.123
OUTAVE: 82.431 82.422 82.451
...
'G' = Correction limited by GamMax, mode signfied by color.
Greyed out. Not Range Limited.
Orange hi-lite, at least 1 channel has GamMax limited gamma correction.
EDIT: Individual channel gamma result is also hi=lited if GamMax limited eg for Red channels limited
GAMMA: 1.135 1.000 1.123
EDIT: LoTh and HiTh still hi-lited in metrics if not OLD default of 0.04, will fix that to hi-lited if not NEW default of 0.0, if new default accepted.
StainlessS
15th May 2017, 14:41
Bump !!!
videoFred
15th May 2017, 18:29
Bump !!!
On your head? :D
Serious, thank you for the latest update, testing it right now.
Fred.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.