ColorYUV2, ColorYUV & Levels Graffers - 30 May 2012

[StainlessS]

After about 1 year+ of doing nothing with the ColorYUV2 thing, I decided to release what
I last touched. Its functional and I use it all of the time but withdrew because of other reasons.

I also am publishing the VB6 source for ColorYUV2 Graffer and latest executable (although I have
likewise done nothing with them for at least a year) source not previously published and in no way
cleaned up for publication, but I thought, why not?

Also exec + source of Levels Graffer, + RGBAdjust Graffer, and MP3 catalog thing (very basic, just
lists mp3 files indented by directory and files, but can do an a blink of an eye that which I
once spent about a week doing by hand).

Also for the risk taker, a UK lottery number picker and syndicate lottery checker (up to 99 cards),
with source.

ColorYUV2 plugin + Source + ColorYUV2 Graffer + Source see ColorYUV2_25_dll_20120529.zip
Via MediaFire in sig below.

For Others Graffers (incl ColorYUV2 graffer + toys) + source see Graffers&Toys.zip, again via Mediafire below.
(Includes RGBAdjust Graffer which has now been deleted as a separate and included in above zip).

https://s20.postimg.cc/e05bqbhq5/Coloryuv2_Graf.jpg (https://postimg.cc/image/r4aw309rt/)

EDIT: the above RENDER button is there basically for historical reasons and little else, the graffer
updates in real time (so long as you dont whiz the sliders too fast, done on a timer now).
Also, should be noted that it works on an RGB Bitmap, and NOT on an AVS file (EDIT + jpg etc).
EDIT: Expects conversion to RGB bmp from rec.601 (It need to know what YUV its dealing with,
in action, converts RGB->YUV does the sums then back to RGB to display again),
but this also means that the output is also only applicable when using rec.601
as Avisynth input to ColorYUV2.
EDIT: In ColorYUV2, we use the term 'rpow' rather than Gamma (poison word if not RGB).

RGBAdjust Graffer
https://s20.postimg.cc/9sajhkgal/Rgb_Adjust_Graf.jpg (https://postimg.cc/image/ucfdg1w1l/)

Levels Graffer
https://s20.postimg.cc/69yjl6fel/levels_Graf.jpg (https://postimg.cc/image/hz2j956d5/)

Graffers and toys
http://www.mediafire.com/file/5hdnos18p2pm206/Graffers%26Toys.zip

ColorYUV2 Graffer v1.0b (Bottom of page)
http://www.mediafire.com/file/wq4f9yy1kmp6753/ColorYUV2_Graf_v1-0b_21120614.zip

RGBAdapt:
http://www.mediafire.com/file/bo4afg77u4dfu8k/RGBAdapt_dll_v0.3-20150617.zip

See MediaFire in sig below this post for dll, or below
http://www.mediafire.com/file/875czvfnigu72ds/ColorYUV2_25_dll_20120529.zip

[Emulgator]

StainlessS, my appreciation for the 2 Graffers !
Finally I can see where my splines jump.
Very useful for a curveman like me, many thanks. Exactly what i needed.

[StainlessS]

@ Emulgator

On Levels Graffer, the one I put up has limited i/p o/p (with LIMIT off) -511 to + 511,
is this sufficient for your needs, I think I just recently saw a script using an o/p max
as something in the thousands (2000 I think, or maybe 9000), something to
do with making a mask for either AvsInpaint or ExInPaint, delogo stuff.
Anyway, I have just changed the source so that there are 3 limit option
buttons, limit to (0,255), (-999,999), (-9999,9999), what I wanna know is,
is the 3rd one overkill, I'm pretty sure I would never go that hi, is there a
realistic need for such.

[Emulgator]

For me the 8 bit range is sufficient for now,
but if you are just about to expand the range:
You could accommodate 48bit RGB colours (16bitR+16bitG+16bitB) from .bmp.
Some 16bit per component video is in sight as well for Avisynth 2.60.
Colour spaces like YV12 (12bit per sample: 8bit Y + 2bit Cb + 2 bit Cr) are there,
YV24 is coming.
And 16 bit are 65536 steps.
I guess 16bit per component will be end of the line for any video amplitude resolution for a longer time.
Maybe we will see anything extended like YV2*12
(24bit per sample:16bit Y +4bitCb + 4bit Cr).
Something is defined already: Y216, P216, P016 and more. See here:
http://msdn.microsoft.com/en-us/library/bb970578(VS.85).aspx

[StainlessS]

@ Emulgator

Thankyou for your reply.
Found the script that had that levels thing in it, InPaintFunc by Reuf Toc.


BlendedMask = Masque.DirtyBlur().levels(0,1,75,0,255)
BlendedMask = BlendedMask.mask(BlendedMask)
RepairMask = BlendedMask.levels(0,1,255,0,pp)
RepairEdge = Masque.DirtyBlur().levels(0,1,255,0,900) <<<<<<<<<<<<<<<
RepairEdge = RepairEdge.DirtyBlur().levels(0,1,75,0,pp)


It was 900 not 9000, but still somewhat higher than 255. Yeh, according to the
graffer, he could have got the same effect with approx levels(0,1.0,80,0,255),
Sorry if I was unclear, but not asking about 16/32 etc bit per channel, but only
in limiting the slider values, the graf will still saturate at 255, but as above, Reuf
Toc chose an alternative means to the same end. I have seen other scripts
where author chose to use values way outside 0-255 range, thats why I was
asking. Think I'll consider larger bits per channel, when levels does.

Thanks for your answer, I think I'll go back to a single tick box with slider limits
of +-999 or +-1000, maybe, with a limit of +-10000, the slightest movement of
a sliders has the grafs jumping all over the place, just not very ergonomic, thats
why I was a little hesitant to have that large a range.

Also, can you tell me if this would be of some assistance (dont bother if not),
the little red rings in the levels graffer were left over from previous functionality,
before I added the gamma slider (I had been using to estimate offset and gain,
where inputs could be significantly outside 0-255 range). Would re-introducing
readout of offset and gain be of general interest, at all, and perhaps, indications
of eg:
Y Where X = 0 : Y Where X = 255
X Where Y = 0 : X Where Y = 255

Of course I would probably have to disable readout if Gamma or Coring were selected.
I left in the red rings to emphasise what coring did.
Anyway, if that is of some use in your opinion, let us know, otherwise dont bother.

Ta for the link, always looking for that type stuff.

Thanx :)

[Emulgator]

You may leave it as is for me, others may utter their thoughts as well.
I guess one limit setting for 8-bit and one for 16-bit can accommodate almost all.
Still I will have to play with it to be able to utter some wishes,
but for now I am very happy with the graphs.
Too deep into a restoration job and cannot look up too long...
Hm, 10 bit is there as well. 1024 steps.
For still photography 12bit (4096 steps) and 14bit (16384 steps) raw formats exist as well.
Sensor development vs. bit saving.
You decide, it may be better to accommodate all bitdepths sooner or later.

[StainlessS]

@Emulgator

Reply not necessary to this, just wanna clarify.
The limit in the Levels Graffer, is just a limit on input/output slider values,
levels does not restrict the range of valid input/output args, -100 for input min
(or output min) is just as valid as 0, its just that most people usually
stick within the 0-255 range for input and output. The output will always
saturate at 255 with range 0-255. As Levels will accept (theoretically at least)
int sized args I could have the sliders accept +- 2 billion (I dare say there maybe
one or two overflows if I did that). The intent was to allow input/output sliders
to be allowed a reasonable amount of latitude, without getting rediculous.
As it is, VB 6 scroll bars are limited to I think +-32000, I dare say you
might be able to find a later version coping with much greater range.
It would be very easy to knock up a modified graffer, to give a greater
output saturated range, but showing edited bitmap would not be terribly
easy, VB6 uses the system to load a BMP/JPG (and maybe several other
formats), into a picturebox, where it (in the graffers case) is resized and
converted to fit the picturebox and to the current color resolution that
the PC is using. Perhaps on say windows 7 or later when they implement
the load/display of such files within the system, and when vb.net 2010+ is
capable of loading such files into it's picturebox controls, then it might be
feasable, but this probably aint currently so and Levels does not cope with
greater range than 0-255, not gonna happen in the levels graffer soon.
I will though, knock up a Levels type graffer, without the BMP features,
and enable you to select the output graf range 0 to (2^bpc)-1 (bits per
channel) with bpc range of 8 - 16. Give us a coupla days to do this. :)

[StainlessS]

On the ColorYUV2_GRAF.EXE in the toys zip, well today,
I got a TROJAN warning from Comodo v5.3.175888.1227
with AV DB v7828.

TrojWare.Win32.MonderGen@88653584

I uploaded to Virustotal.com where it was flagged by 0/43
different AV products, including Comodo, ie clean.
The Comodo AV DB in use there was 7837 (dated today,
the one I used was from yesterday), so I updated my AV
sig DB to the same version as on VirusTotal and it's still
showing the trojan warning.
Re-compiled, still showing it, code not that much different
to Levels_Graf.Exe and that dont show any warning.

Anyway, have submitted to Comodo as a false +ve, just
thought I should mention all the above.

-------------

@Emulgator
I will though, knock up a Levels type graffer, without the BMP features,
and enable you to select the output graf range 0 to (2^bpc)-1 (bits per
channel) with bpc range of 8 - 16. Give us a coupla days to do this. :)

@Emulgator,

Damn, I forgot all about that above, got sidetracked into that
DDigit thing and just went completely out of my head.
If you were holding you're breath, you must be blue by now.:stupid:


EDIT:-

The Malware thing above turned out to be becauseof a sequence of "buttons"
of a Visual Basic program form. If I swapped them in order, the warning disappeared.
"Life, ... Dont talk to me about life".

[StainlessS]

Here:-

RgbAdjust Graffer, not much debugging done but there seems little to go wrong with it,
so I put this up. Perhaps only temporary if it proves problematic.
Take it, try it. If it dont work proper, say so here. Incomplete so dont expect too much.

Link is likely to be deleted at some stage.

EDIT: Temporary link removed, click on sig.

[StainlessS]

New Version ColorYUV2() + New Version Graffers. See First Post.

[StainlessS]

@Emulgator,

Sorry, never did finish that graffer thing but this is what I got to :

https://s20.postimg.cc/rkw3pfxj1/LEVGRAF.jpg (https://postimg.cc/image/saew1sy2h/)

Probably of no general value but below a temp link to VB6 source and executable:
http://www.mediafire.com/?0ehnnvra129qstc

EDIT: The numbers to the right of "A Line Of Status Text" are input/output coords, in
this case input coord is in 8 bit, output is in 10 bits, and show the position of the mouse when I
snapped that screencap. EDIT: Scaled coords, the box is I think 512x512 pixels.

[Mounir]

Seems like an interesting plugin but what are the reasons we must use .bmp only and not a real video ? An integration in AvspMod may be welcome

[StainlessS]

ColorYUV2 is a plugin.
Of course ColorYUV2 usage could be integrated into AVSPmod (which I do not as yet use but am aware of) using their
"Sliders" (just watched a brief video on that utility), and if someone actually does that then maybe I would be
attacted to use it. I probably started the graffer things before I was even aware of AVSPmod, and also wanted
the graf display and not just the change in output video. Also, allowed me to judge that the plugin performed
as it should when comparing graffer output with debug mode exported luts from the plugin.
Last time I tried AVSPmod. I think I was less than delighted with the fluidity in eg using the sliders to scroll
from frame to frame, just did not feel as silky as VDubMod and probably one reason I have not currently
taken to AVSPmod. If you mean why can you not have the grafs in plugin, well maybe its because I,m
not clever enough to do that on the video frame. Its easy to draw eg a line or circle in Visual Basic,
not quite so easy on a video frame with a selection of color spaces. Why can I not load an AVS clip into
the graffers?, well I dont know how to do that either, sorry.
EDIT: To draw the grafs and grid/graticule in eg YV12, would probably require rendering into a frame buffer,
draw lines etc (maybe in RGB), and then final convert to YV12, to directly draw in YV12 would not I think look good
as each time you overdraw one line with another, the chroma mod would interfere with the previous rendered
choma and would probably look a mess. I'm guessing that is (EDIT: Frame buffer) perhaps the way the subtitle works in Avisynth
but with some sort of resize as well (if needed).

EDIT: If you actually mean to integrate the graffer into AVSPMod, then the source is supplied and could I think
quite easily be commandeered by the AVSPmod team, try nagging them about it.

[StainlessS]

Here Is the VB code for rec.601 to RGB and Back again.


Option Explicit
Option Base 0


' --------------------------------------------------------
Private Const cyb As Double = 0.114
Private Const cyg As Double = 0.587
Private Const cyr As Double = 0.299
Private Const cbu As Double = 2.018
Private Const crv As Double = 1.596
Private Const cgu As Double = 0.391
Private Const cgv As Double = 0.813
Private Const yDwnScale As Double = (219# / 255#)
Private Const yUpScale As Double = (1# / yDwnScale)
Private Const yOffset As Integer = 16
Private Const uvOffset As Integer = 128
' -----------------------------------------------------------------

Public Sub RGBtoYUV(r As Long, g As Long, b As Long, _
ByRef Yref As Long, ByRef Uref As Long, ByRef Vref As Long)
Dim scaled_y As Double, b_y As Double, r_y As Double
Dim y As Long, U As Long, V As Long
scaled_y = cyr * r + cyg * g + cyb * b
b_y = b - scaled_y
r_y = r - scaled_y
y = Round(scaled_y * yDwnScale + yOffset) ' CCIR Ranging
U = Round(b_y / cbu + uvOffset)
V = Round(r_y / crv + uvOffset)
y = IIf(y < 0, 0, IIf(y > 255, 255, y))
U = IIf(U < 0, 0, IIf(U > 255, 255, U))
V = IIf(V < 0, 0, IIf(V > 255, 255, V))
Yref = y
Uref = U
Vref = V
End Sub


Public Sub YUVtoRGB(y As Long, U As Long, V As Long, _
ByRef Rref As Long, ByRef Gref As Long, ByRef Bref As Long)
Dim scaled_y As Double
Dim b_y As Double, r_y As Double
Dim r As Long, g As Long, b As Long
scaled_y = (y - yOffset) * yUpScale
r = Round(scaled_y + (V - uvOffset) * crv)
g = Round(scaled_y - (U - uvOffset) * cgu - (V - uvOffset) * cgv)
b = Round(scaled_y + (U - uvOffset) * cbu)
r = IIf(r < 0, 0, IIf(r > 255, 255, r))
g = IIf(g < 0, 0, IIf(g > 255, 255, g))
b = IIf(b < 0, 0, IIf(b > 255, 255, b))
Rref = r
Gref = g
Bref = b
End Sub


If someone in the know could provide the numbers for rec.709 and also for PC.601 and PC.709 then I could plug those
into the ColorYUV2 graffer (I kept reading different info on the conversions on the net and got miffed with about 17 different
versions claming to do the same, thats why I got a bit miffed and put it on the back burner for a year +).

I guess I could then add a selection option to let the graffer know what it is dealing with (PC.709 etc) and perhaps implement
the ability to eg load in from a number of sequencial bitmaps to see how the settings affected the whole clip (of a eg SelectEvery 100,
sub clip). Perhaps a future version might also be able to load in an AVI or AVS and use that in addition to a bitmap sequence,
when I eventually figure out how.
EDIT: Note, above code converts eg Rec601 Luma Y of 128 to RGB 128, new color conversion routines
being worked on right now will convert Rec601 Luma Y of 126 (actual Rec601 mid point) to RGB 128.
Using new method outlined here:

http://avisynth.org/mediawiki/Color_conversions

[Gavino]

If someone in the know could provide the numbers for rec.709 and also for PC.601 and PC.709
http://avisynth.org/mediawiki/Color_conversions

[StainlessS]

Thankyou Gavino, shall see if I can plug it in.
Have located some info on AVIFile, gonna have a little play with it.

[StainlessS]

Can someone verify the below code is correct


Private Const rec601_kr As Double = 0.299
Private Const rec601_kb As Double = 0.114
Private Const rec601_kg As Double = 1# - (rec601_kr + rec601_kb)

Private Const rec709_kr As Double = 0.2126
Private Const rec709_kb As Double = 0.0722
Private Const rec709_kg As Double = 1# - (rec709_kr + rec709_kb)

Private Const pc601_kr As Double = 0.299
Private Const pc601_kb As Double = 0.114
Private Const pc601_kg As Double = 1# - (pc601_kr + pc601_kb)

Private Const pc709_kr As Double = 0.2126
Private Const pc709_kb As Double = 0.0722
Private Const pc709_kg As Double = 1# - (pc709_kr + pc709_kb)

Kr(0) = rec601_kr: Kb(0) = rec601_kb: Kg(0) = rec601_kg
Yscale(0) = 219# / 255#: CScale(0) = 112# / 255#
Yoff(0) = 16: Coff(0) = 128

Kr(1) = rec709_kr: Kb(1) = rec709_kb: Kg(1) = rec709_kg
Yscale(1) = 219# / 255#: CScale(1) = 112# / 255#
Yoff(1) = 16: Coff(1) = 128

' Posted by IanB at below link: "For PC.601 and PC.709 the chroma values are 128+/-127 so [1~255]."
' http://forum.doom9.org/showthread.php?t=125956
' so for PC chroma range, we use Cscale = 127.0/255.0 Not 127.5/255.0

Kr(2) = pc601_kr: Kb(2) = pc601_kb: Kg(2) = pc601_kg
Yscale(2) = 1#: CScale(2) = 127# / 255#
Yoff(2) = 0: Coff(2) = 128

Kr(3) = pc709_kr: Kb(3) = pc709_kb: Kg(3) = pc709_kg
Yscale(3) = 1#: CScale(3) = 127# / 255#
Yoff(3) = 0: Coff(3) = 128



In particular the PC range chroma, "Cscale",
think I've seen code recently that used 127.5/255.0 (but that would seem to be wrong).

[Gavino]

Looks right.

Note that since the K coefficients are independent of PC/Rec, there is no need to define both rec601_kr and pc601_kr, etc, as by definition they have the same values.

Conversely, the scale and offset values are independent of the 601/709 dimension (depending only on PC/Rec) and could be defined once as constants.

[StainlessS]

Thanks Gavino,

Yep I was aware of the constant duplication and would probably have pared down at some point.
Doing the conversions via precalc arrays to speed up, results would only need long type additions
and 1 long division by 65536.

EDIT: As far as scale and offset are concerned, will keep as is, would require special handling which would
increase code size, and also slow down. Prefer to keep in arrays so can use same code
without special cases.

[StainlessS]

ColorYUV_Graffer v1.0Beta

I've added options Rec601, Rec709, Pc601, Pc709 as RGB bitmap original YUV source.
(So it knows what you're using in Avisynth).

If anyone would like to examine the color space conversion routines before declaring as
non Beta v1.0, then VB6 source is included.

You can switch matrix at any time, not just before loading bitmap. In action, it converts
the input RGB to the desired YUV format and stores and works on that YUV (unless you
switch matrix in which case it converts the input RGB to YUV again using the new matrix).
Do not expect to see any difference in the image when switching source colour space,
it will look (almost) exactly the same (if it looks different then it would indicate a problem). You will
however see a change in displayed histograms.
EDIT: No difference when all sliders settings are reset.

Have added 'Chroma Locking' tick boxes which lock both U and V channels together when using
sliders (inactive when in Luma mode). Probably of most use when editing Chroma Cont_u or Cont_v,
if locked together, then it is equivalent to altering the saturation of an image, no need for Tweak
any more (or at least a reduced need for it). You can also go mad and get what I guess I might
call -ve color saturation. The other chroma lock functionality may come in handy but probably to
a lesser degree.

Also added a ClipBoard copy function which just copies the resultant ColorYUV2() command to the clip board.


Below just a little demo of reduced chroma sat on left side of image (cont_u=-100,cont_v=-100).
EDIT: I'm aware that you can do the reduced sat in ColorYUV anyway, but NOT usually in a real time
using sliders, not even in AvspMod using their sliders(I guess), and without the colorspace conversions
in Tweak. The saturation reduction will be most evident in the eyes.

https://s20.postimg.cc/47y26xhfh/CYUV-1-0b-frog-desat.jpg (https://postimg.cc/image/3v6o0qz5l/)

Have fun :)

EDIT: MediaFire back up now, preferable to the above link:
http://www.mediafire.com/?wq4f9yy1kmp6753

[Overdrive80]

Thanks for you filters, coloryuv2 graffers is great but you can consider to implement the posibility of loading videos, too??

[StainlessS]

Thank you for the nice words, If I knew how to do that, I would, maybe one day I'll figure it out.

[Bernardd]

Hello StainlessS,

Because i am working a RGB picture, when i make manual movies colors corrections, i have tried to write a script for add percentage of red, green and blue layers upon the frames.
Colours says me it easier to use ShowRed, ShowGreen, ShowBlue and Merge the filtered result. (http://forum.doom9.org/showthread.php?p=1680461#post1680461)
Thus i have write this short script, which use AvsPmod users sliders function.

Avisource .......

LoadPlugin("C:\......\ColorYUV2_25_dll_20120529\ColorYUV2.dll")

[<separator="Red users sliders">]
off_y_red = [<"off_y_red", -256, 256, 0>]
rpow_y_red = [<"rpow_y_red", -256, 256, 0>]
spow_y_red = [<"spow_y_red", -256, 256, 0>]
pord_y_red = [<"pord_y_red", 0, 1, 0>]

[<separator="Green users sliders">]
off_y_green = [<"off_y_green", -256, 256, 0>]
rpow_y_green = [<"rpow_y_green", -256, 256, 0>]
spow_y_green = [<"spow_y_green", -256, 256, 0>]
pord_y_green = [<"pord_y_green", 0, 1, 0>]

[<separator="Blue users sliders">]
off_y_blue = [<"off_y_blue", -256, 256, 0>]
rpow_y_blue = [<"rpow_y_blue", -256, 256, 0>]
spow_y_blue = [<"spow_y_blue", -256, 256, 0>]
pord_y_blue = [<"pord_y_blue", 0, 1, 0>]

# based on Colours's script : http://forum.doom9.org/showthread.php?p=1680461#post1680461 #
ConvertToRGB32(matrix="Rec601") # replace with the correct colour matrix if your source has a different one
red = ShowRed("y8")
green = ShowGreen("y8")
blue = ShowBlue("y8")
red_processed = red.ColorYUV2(off_y=off_y_red, rpow_y =rpow_y_red, spow_y =spow_y_red, pord_y = pord_y_red)
green_processed = green.ColorYUV2(off_y=off_y_green, rpow_y =rpow_y_green, spow_y =spow_y_green, pord_y = pord_y_green)
blue_processed = blue.ColorYUV2(off_y=off_y_blue, rpow_y =rpow_y_blue, spow_y =spow_y_blue, pord_y = pord_y_blue)
MergeRGB(red_processed, green_processed, blue_processed)
ConvertToYV12(matrix="Rec601") # use the same matrix as earlier


For you, has this ColorYUV2 use a sense ?

Is it possible to say : off_y put the color layer or the invert color layer on the frame with the same strength on dark and light luma tones (dark below 128, light above 128),
rpow_y put the color layer or the invert color layer strong on dark luma tones and lighter on light luma tones,
spow_y > 0 put the color layer on dark luma tones and the invert color layer on light luma tones and other side for negative values ?

Thanks

[StainlessS]

Hi Bernardd,
I thought I might be able to make it a little easier for you, so I spent a couple of hours doing RGBAdapt plugin,
just had to rip it out of RT_Stats (used only for Luma) and glued it together with the frame renderer.
Not much tested, but the only likely source of problems would be the LUT creator, and that has been working
fine for some tiime, so I dont expect any problems. Find it here:
http://forum.doom9.org/showthread.php?t=170642

It should not prove too difficult to mod your macro (or whatever they call it in AVSPMod).

EDIT: RGBAdust is quite similar to ColorYUV2, but it also has SPMid args for r/g/b, which affects the flexing or turning point
of the S-Power curve.

[Bernardd]

Hello StainlessS.
Well done !
I am impressed. In your very quick answer, you write a new plugin, but also you anticipate my whole luma range control need with the SPMid args.
Get something that you wish but you have not still wanted, it is marvelous.
This plugin is very efficient. With the graffer, a dummy like me know and understand that he is doing.
A minor bug 0.01 and 0.99 are not allowed for SPMid args. The graffer windows is not autosized, i cannot read the bottom, but it is not necessary in my case.
Thanks.

[StainlessS]

A minor bug 0.01 and 0.99 are not allowed for SPMid args

In Graffer or plugin ? (both look OK to me).

I'll squash the dialog box a bit to fit your 768 height.

[Bernardd]

0.01 an 0.99 are not allowed in plugin. I get this error message : RGBAdapt: Invalid R_SPMid(0.01 -> 0.99) {0.010000}
I use AviSynth 2.60A5 (CVS 20130920, ICL10) version.

[StainlessS]

Thank you sir, 0.01 comes out as 0.0099999 etc as a float conversion to double, will fix.
I did originally do the graffer thing for 768 display, however I obviously had to move things around
and forgot to put them back, hence the gap between sliders and bottom buttons, and your problem.
Thanks for pointing out the errors of my ways, I'm such a slipshod individual, sorry.
Will fix.

[StainlessS]

Bernardd, fixed the float->double conversion prob, fixed Graffer and included in zip.

[Bernardd]

StainlessS,
All is OK. Thousand thanks.