histogram matching/curve computing question

[LaTo]

Thanks for your suggestions LaTo.
I deliberately kept the code separate and as separate function call to make it easy to rip out for other uses,
as for coding style, that is how I've always done it and it is quite clear to me.
Sure but you can do that without duplicating such large portion of code ;)

I notice that you multiply the Y coords by pitch and add X offset rather than using a raster pointer incremented by pitch at every line,
that is a lot of multiplications that could be replaced by a simple addition every now and then, not something I would not do myself.
Yes, that's micro-optimization... In an analysis filter like this you won't gain much speed, anyways I changed the code.

However, debug pixel sampling functionality is broken as histogram plots Luma 255 where histogram is zero (ie white outline),
original MatchHistogramDebug() plots histogram value only @ Y= 255(bottom line), outline only rendered where histogram value is greater than 0.
My bad, copy-pasted too quickly and forgotten the > 0 check... I fixed the code.

I did however like your overall style, but is not mine, I'm a C programmer not CPP, each to their own I guess.

And just to clarify, the TAKE_3 post also contains the bug fix.
Thanks for your work LaTo, much appreciated. :)
Your contributions are well appreciated too, thanks!

[StainlessS]

Post #46 script updated.
Crashed if changed ConvertToYV24 to eg ConvertToYV16, as Overlay returns YV24 when given YV16 and YV12 clips (does not match for Stack clips).

LaTo, Integer Divide by Zero In both plugins when given Y8 clip (Plane arg does not matter)
MatchHistogramDebug() or Debug=True code OK.

EDIT: I'll withdraw my plug if you fix the zero divide.

[LaTo]

Should be fixed now. I updated the package.
(GetWritePtr() doesn't return NULL with inexistent plane, weird thing, need to check size of plane)

[StainlessS]

(GetWritePtr() doesn't return NULL with inexistent plane, weird thing, need to check size of plane)

(vi.width==0) means no video, (ie source for vi.HasVideo==false)
(src->GetRowSize(PLANAR_U)==0), means no plane.

Found another bug I'm afraid (you must be getting sick of me :) )

If Avisynth v2.6 with v2.5 plugin, then plugin cannot tell eg YV24 from YV12 (vi.IsYV12==true) for all planar.

I usually cope with this by adding one of the below snippits, depending upon what a plugin supports.


# ifdef AVISYNTH_PLUGIN_25
if(vi.IsPlanar() && vi.pixel_type != 0xA0000008) {
// Here Planar but NOT YV12, If v2.5 Plugin Does NOT support ANY v2.6+ ColorSpaces
env->ThrowError("RoboCrop: ColorSpace unsupported in v2.5 plugin");
}
# endif


OR plugin supports all colorspaces, but not if rendering (or even reading chroma with wrong YV12 RowSize and Height) anything to frame (simply gets frame and passes it on to client).


#ifdef AVISYNTH_PLUGIN_25
if((show || ver) && vi.IsPlanar()) {
if( vi.pixel_type!=0xA0000008 && // YV12
vi.pixel_type!=0xE0000000 // Y8
) {
env->ThrowError("FrameSel: ColorSpace unsupported for Show & Ver in v2.5 dll\n");
}
}
# endif

Above vi.pixel_type gives real YV12 status.


I too forgot to add one of the above snips in the debug plug I did.

The only problem you will have is weird chroma output at top Left Hand Side of frame (Y8 functions OK).
EDIT: Above wrong, if you eg rendered info.h metrics text then top LHS would be wrong, but as you
do a MakeWriteable so you are starting with a good eg YV24 inverted frame and you only transfer pixels values from
LUT to chroma planes, so top LHS will in this case be more or less correct, but the inverted clip will not
be fixed for the rest of the frame, ie still inverted chroma (for the invert demo below).

this will demo problem

avisource("D:\avs\starwars.avi")
ConvertToYV24()
B=Invert
CS=MatchHistogram(b,Last,plane=4,Show=true,Debug=False)
return CS.ConvertToYV12


Not a major thing, some coders dont seem to care if wrong due to this problem. :helpful:

EDIT: If you choose to add 2nd snippit, then need to detect if chroma plane requested for Y8 and ThrowError.
By the way, the YV12 pixel_type 0xA0000008 is fixed in concrete.

These settings for script in post #46 should also demo the problem

avisource("D:\avs\starwars.avi")

(VersionNumber>=2.6) ? ConvertToYV24() : ConvertToYV12

A=Last
TEST=1 # 0=Invert Luma : 1=Photo -ve invert : 2=Gamma test
#GAMMA=1.0/2.2 # A little excessive
GAMMA=0.66
BLUR=0.0
###################################
# MatchHistogram mode only #
RAW=True # False = Smooth histogram : True=No Smooth
PLANE=4 # Plane to fix (0=Y : 1=U : 2=V : 3=U+V : 4=Y+U+V)
#MatchHistogram Debug mode only #
DEBUG_RAW=False # False = Smooth histogram : True=No Smooth
DEBUG_PLANE=1 # Plane to show in debug mode (0=Y : 1=U : 2=V)



EDIT: My version plugin links removed.

[LaTo]

Found another bug I'm afraid (you must be getting sick of me :) )

If Avisynth v2.6 with v2.5 plugin, then plugin cannot tell eg YV24 from YV12 (vi.IsYV12==true) for all planar.
I've added the YV12 check for plugin v2.5 used in avisynth v2.6 :devil: