A question about displacing pixels using a grid

[TheProfileth]

I was wondering if it would be possible to do something along the lines of this
http://screenshotcomparison.com/comparison/33922
or this
http://screenshotcomparison.com/comparison/33923
that being insert a 2x2, 4x4, or 8x8 grid and have it displace the original image keeping the original pixels all intact only separating them into individual blocks, I had some ideas concerning this, but I need to know if this is possible first

[-TiLT-]

Unfortunately grid() (http://avisynth.org/vcmohan/Grid/Grid.html) will just draw a grid over the image, not separate the blocks.

Scripting it with avisynth (with a lot of crop() & overlay() ) would be possible, but not trivial to implement (though some pros might write it down in 30 secs).

I think first thing in the script should be adding of black borders (right and bottom) to keep the image modulo of the blocksize and prevent problems when cropping at the right side and bottom.

[Didée]

Think more simple. Do a PointResize(), then overlay the grid. ;)

[-TiLT-]

Like a 1,1->9,9 minus 1px grid for a 8,8 grid.

Yeah, keeping things simple isn't that easy sometimes.

[TheProfileth]

I am entirely sure that this is possible with either scripting a dll or an avsi, I will take a look into this and try your idea Didee
Edit:As -TiLT- implied, the actual upscaling to the right resolution ends up being a bit hard to calculate correctly
Edit2: Well Didee after getting the right size , point resize doesn't seem to do anything different than any other resize with regards to achieving my goal.
Again let me state
my goal is to insert a grid quiet literally INTO the picture, meaning that the resolution is increased by the number of pixels that the grid takes up, rather than just superimposing it on the image

[Gavino]

my goal is to insert a grid quiet literally INTO the picture, meaning that the resolution is increased by the number of pixels that the grid takes up, rather than just superimposing it on the image
That's the point of using PointResize.
If you get the numbers right, it will add duplicate pixels at exactly the points where the grid goes, displacing the others to the right or down to fit around the grid.

For example, for a 4x4 grid, resize by a factor of 5/4, then overlay the grid.

[TheProfileth]

That's the point of using PointResize.
If you get the numbers right, it will add duplicate pixels at exactly the points where the grid goes, displacing the others to the right or down to fit around the grid.

For example, for a 4x4 grid, resize by a factor of 5/4, then overlay the grid.
Alright let me try that
Edit: Ok well the problem with doing that is that not all of the "extra pixels" get covered up and then you end up with blocks that contain weird artifact like blotches which sort of defeats the purpose
Edit2:lol I forgot to use 5 not 4 ok hold on
Edit3:damn it seems that the input for the grid must be a even number so I can't use 5 or 9 or 17, I also can't use any value below 4

[Gavino]

Remember also that if the grid encloses 4x4 pixels, the grid itself will be every 5 pixels, and so on.

[TheProfileth]

So Gavino, do you or anyone you have any other methods that could work?

[Gavino]

An alternative way of creating the grid is to use mt_lutspa.
For example,
mt_lutspa(expr="x 5 % y 5 % * 0 == 255 0 ?", relative=false)
will create a grid-like mask with a grid spacing of 5.
The mask can then be used in overlaying a solid-coloured clip on top of the original, thus adding the grid to it.

[2Bdecided]

Edit3:damn it seems that the input for the grid must be a even number so I can't use 5 or 9 or 17, I also can't use any value below 4converttorgb() first?

[Didée]

... While waiting for the printer to finish my document ...

Most probably this is erroneous, but at least it's a start.

FWIW:

# YV12 required, as is MaskTools.
#
# target: 8x8-grid expansion
#
# "MAY CONTAIN NUTS"

o = last

owidth = o.width
oheight = o.height

exwidth0 = owidth * 9.0/8 + 1
exheight0 = oheight * 9.0/8 + 1

exwidth1 = ceil(exwidth0/4.0) * 4
exheight1 = ceil(exheight0/4.0) * 4

xcorr = ((exwidth1-exwidth0) / 9.0) *8
ycorr = ((exheight1-exheight0) / 9.0) *8

ex1 = o.pointresize(exwidth1,exheight1,0,0,owidth+xcorr,oheight+ycorr)
ex2 = ex1.mt_expand(mode="-1 -1",U=3,V=3)

grid = ex2.mt_lutspa(relative=false,expr="x 8 % 0 == y 8 % 0 == | 0 255 ?")

ex2.mt_logic(grid,"min",U=2,V=2)

[Gavino]

# target: 8x8-grid expansion

grid = ex2.mt_lutspa(relative=false,expr="x 8 % 0 == y 8 % 0 == | 0 255 ?")[/code]
I'm not sure how the rest of your script works, but that bit doesn't look right.
As I pointed out above, to contain 8x8 blocks of original pixels, the grid spacing must be 9x9

[Didée]

Oh yes, those 8's should be 9's, of course. Also, the script feeds destination width|height as float values into the resizer. That's not so good. :D

[-Vit-]

I didn't try the above script, but this works with the PointResize approach
[I don't like the mt_merge at the end, but had problems with chroma otherwise. BTW. it needs MaskTools alpha 45 or above as it uses the newer syntax for lutspa]

# Split into grid of given size
# size = grid x dimension, sizeY = grid y dimension (= x dimension by default)
# color = grid color in RGB (e.g. $00FF00 for green, defaults to black)
# xMod and yMod = dimension restrictions on clips (defaults to multiples of 4) [could calculate from clip type]
# Examples: GridSplit( 8 ) # 8x8 grid GridSplit(5,3,$808080) # 5x3 grid, gray grid lines
function GridSplit( clip c, int size, int "sizeY", int "color", int "xMod", int "yMod" )
{
xMod = default( xMod, 4 )
yMod = default( yMod, 4 )
sizeY = default( sizeY, size )
color = default( color, $000000 )

# Original dimensions
w = c.Width()
h = c.Height()

# Dimensions with grid lines, but may not fit given mods
nw = w + (w-1) / size
nh = h + (h-1) / sizeY

# Pad above dimensions to fit mods
pw = ((nw + xMod - 1) / xMod) * xMod
ph = ((nh + yMod - 1) / yMod) * yMod

# Equivalent dimensions to above without grid lines - must pad to this size before rescale to ensure each
# block of "size" pixels will map to exactly "size+1" pixels in result
bw = float(size * pw) / (size+1)
bh = float(sizeY * ph) / (sizeY+1)

# Pad, then rescale using dimensions calculated. Also offset duplicated pixels to provide neat position for grid lines
c.PointResize( pw, ph, 1 - 0.5/(size+1), 1 - 0.5/(sizeY+1), bw, bh )

# Black out both grid and padded pixels
gridCondition = "x 1 + " + string(size+1) + " % 0 == y 1 + " + string(sizeY+1) + " % 0 == | "
paddedCondition = "x " + string(nw) + " >= y " + string(nh) + " >= | "
grid = mt_lutspa( mode="absolute", expr=gridCondition + paddedCondition + "| 0 255 ?", U=1,V=1 )

background = BlankClip( grid, color=color )
mt_merge( background, last, grid, luma=true )

return last
}

[TheProfileth]

Hey thanks everyone, I will be sure to try your method out -Vit- will give feedback in a second
Edit: Ok so that works great, but umm..... now I need a method to remove it :3

[TheProfileth]

A problem I did not nice until now was that the grid actually causes the image to change, around the grid lines it seems like there is something odd going on :( , so even if the removal of said grid was easily accomplished it still would leave the image changed.

[-Vit-]

That's an optical illusion. The split pixels are exactly as the original image. However moving pixels will jump as they pass over the lines and the sheer amount of black in the image also makes the levels seem different [ try GridSplit(1) ].

I don't see it as a particularly useful effect though. Best I could
get out of it was by chaining a few together:

GridSplit( 8 )
GridSplit( 9 )
GridSplit( 10 )

or

GridSplit( 4 )
GridSplit( 20 )
GridSplit( 84 )

[TheProfileth]

-Vit- it is no optical illusion see here
http://eypic.com/kya43f60b.png
look around the edges, this was a blue image originally

[-Vit-]

Ah yes, I forgot that. The chroma will be off at the edges, because of the subsampling in YV12. Absolutely can't avoid that if you want to inject 1 pixel into a format that samples at every two pixels. Not sure why the effect is creeping two pixels in though.

Would work in RGB, but MaskTools can't do RGB

[Didée]

The bare minimum, necessarily, is that something *has* to go on with chroma.One chroma "pixel" is as big as 2x2 luma pixels. Obviously, shifting luma pixels by 1-pixel-steps will cause some minor chroma misalignment.

More severe, there will be trouble when one tries to overlay a "colored" grid. Since -Vit- uses

mt_merge( background, last, grid, luma=true )

at the end, try with "luma=false" instead, for a black grid without an own color. (Probably. I'm sleeping again.)


Mind to drop a hint what you're trying to achieve? An image scaler?

[-Vit-]

Here's a variant, thrown together rather quickly [much of the calculation is irrelevant if I assume mod1, but it doesn't hurt]. Needs grid() (http://avisynth.org/vcmohan/Grid/Grid.html). Add a ConvertToRGB() on your source, should (?) avoid those problems. Make sure you output in RGB though.

# Variant on GridSplit using V.Mohan's Grid function. Good for RGB images
# Size must be odd and at least 3
function GridSplit2( clip c, int size, int "color", int "xMod", int "yMod" )
{
Assert( size % 2 == 1 && size >= 3, "GridSplit2: size must be odd and at least 3" )

xMod = default( xMod, 1 )
yMod = default( yMod, 1 )
color = default( color, $000000 )

# Original dimensions
w = c.Width()
h = c.Height()

# Dimensions with grid lines, but may not fit given mods
nw = w + (w-1) / size
nh = h + (h-1) / size

# Dimensions with grid lines padded to fit mods
pw = ((nw + xMod - 1) / xMod) * xMod
ph = ((nh + yMod - 1) / yMod) * yMod

# Equivalent dimensions to above without grid lines - must pad to this size before rescale to ensure each
# block of "size" pixels will map to exactly "size+1" pixels in result
bw = float(size * pw) / (size+1)
bh = float(size * ph) / (size+1)

# Pad, then rescale using dimensions calculated. Also offset duplicated pixels to match grid function
c.PointResize( pw, ph, 0.5/(size+1), 0.5/(size+1), bw, bh )

Grid( lineint=size+1, bold=1, vbold=1, vbcolor=color )

return last
}

[Gavino]

Neat solution, -Vit-.
Since resizer source width and height can be floats, I think you can simplify it, eliminating pgw and pgh (and sxMod and syMod) and changing the PointResize parameters to avoid the need for the subsequent Crop, while maintaining the correct scaling factor.
(Edit: this applies to both GridSplit and GridSplit2.)
bw = float(size * pw) / (size+1)
bh = float(sizeY * ph) / (sizeY+1)
c.PointResize( pw, ph, 1 - 0.5/(size+1), 1 - 0.5/(sizeY+1), bw, bh )
BTW there is a typo in the commented example: GridSplit(5,3,$808080) should be GridSplit(5,3,color=$808080).

[TheProfileth]

damn, the gridsplit2 works but I need to convert to rgb which means it is no good for what I had in mind, do you think there is a way for it to work in yuv12, someway that avoids mod1

[-Vit-]

Gavino: Well spotted about the float width/height - dunno what I was thinking given I was using those subtle little float offsets to move the duplicated pixels. I did enjoy that rare use of a recursive lcm/gcd though. I will update the previous posts. But I don't see that the example is a typo; "color" is the next parameter along even if it is named...

TheProfileth: 2-pixel wide gaps will work. Using the original version of GridSplit:

c=last
y = c.GridSplit( 8 ).GridSplit( 9 )
u = c.UToY().GridSplit( 4, color=$808080 )
v = c.VToY().GridSplit( 4, color=$808080 )
YToUV(u,v,y)


The 8 & 9 create a 2-pixel wide gap between every 8 pixels in the luma to match the single gap every 4 pixels of chroma. As well as 8,9 & 4 you could use values 2,3 & 1, 4,5 & 2, etc. You see the pattern.

[Gavino]

But I don't see that the example is a typo; "color" is the next parameter along even if it is named...
Sorry, my mistake there - I confused myself.

Note that with RGB clips (in GridSplit2), you will need to use a different vertical offset because of the upside-down way PointResize works with RGB. (I'm too tired to work out what it should be right now - time to sleep. :))

[jmac698]

Hey,
The board was busy so I missed a lot of this, but I had my own solution brewing;

#Gridmod 0.9 - Draw a grid in between pixels
#by jmac Mar/11
#requires masktools v2a48 or above (needs lutspa function)
#gridx/y should be number of pixels in each grid square
#bugs - last grid line on right and bottom not drawn
# spaces left for grid lines will be wrong in RGB
gridx=8
gridy=8
#Prepare test image
blk=$108080
gry=$7D8080
grygrid=$608080
wht=$EB8080
stackvertical(line(48,blk),line(48,gry),line(48,wht),line(48,gry))
stackvertical(last,last)
stackvertical(last,last)#The picture should be blk,gry,wht,gry, and again
turnleft
horizontalreduceby2
#Insert extra lines
w=last.width
h=last.height
nw=w/gridx+w
nh=h/gridy+h
#add an extra pixel for each gridline starting at 0
pointresize(nw,nh)
#draw grid
s="x "+string(gridx+1)+" % 0 == y "+string(gridy+1)+" % 0 == | "+string(grygrid/65536)+" 255 ?"
#return messageclip(s)
grid=mt_lutspa(relative=false,expr=s)
mt_lutxy(last,grid,"y 255 = x y ?")

function line(int w, int c) {
blankclip(width=w,height=2,pixel_type="YV12",color_yuv=c)
}
The idea is pretty easy; just pointresize with extra pixels of the number of gaps you need. To avoid all this problem with yv12 and pairs of pixels, just doublesize everything beforehand and resize back down after. The chroma resampling will occur and merge the colors of your grid lines but that's the best that can be done in yv12. If seeing the pure pixels is critical for some reason, either use rgb at the end or keep it doublesize.
I haven't analyzed the other solutions but they're probably similar; though they seem to have way too many formulas to me.
Also note that this behavior of pointresize is implementation specific; but yet another reason why we need a social contract on this. Also note that RGB resize occurs in the opposite order; therefore the pixel gaps will start at the end. You need special code when you resize in rgb, just do a mirror image on it after.
When analyzing per pixel I also use a special transform; I put Y into G, V into R and U into B, then I can preserve the YUV values in an RGB image and it even looks reasonable.
There's no need for limitations to odd widths; yv12 always has to be padded to mod2 anyway. I didn't pay much attention to color in my solution but I'm sure it's easy to solve.
p.s. Don't try to solve the intricate problems of color in real size, just resize everything to doublesize and then work with the fat pixels with no worries.

[-Vit-]

Maybe I'm missing something, but I couldn't get that script to work. It resizes to a strange width/height and fails the YV12 mod2/4 restrictions. That's partly what the extra intricacy in my solution is for - padding the point resize to a valid dimension. Then you need adjustments to make sure the duplicated pixels lie exactly underneath the grid given the padding. PointResize is consistent within each colorspace, so the adjustments are no worse than the different mods needed for each.

I don't think doubling and working with "fat" pixels will work because PointResize will still be working with real pixels not the fat ones.

[Gavino]

I haven't analyzed the other solutions but they're probably similar; though they seem to have way too many formulas to me.
Your solution only works if the input width and height are multiples of the grid size. The extra complexity is needed to ensure the added pixels are exactly a grid apart for all possible grid sizes and clip dimensions.
Also note that RGB resize occurs in the opposite order; therefore the pixel gaps will start at the end.
Only in the vertical dimension - horizontal is the same as YUV.

[-Vit-]

Your solution only works if the input width and height are multiples of the grid size.
It's even more restrictive than that, must be a multiple of (grid size * modX), where modX is the mod restriction for that dimension/colorspace. So a multiple of 32x16 for YV12 and 8x8 grids

[Gavino]

function GridSplit2( clip c, int size, int "color", int "xMod", int "yMod" )
...
c.PointResize( pw, ph, 0.5/(size+1), 0.5/(size+1), bw, bh )
Are you sure about that vertical offset? As I said,
Note that with RGB clips (in GridSplit2), you will need to use a different vertical offset because of the upside-down way PointResize works with RGB.
I think the offset needs to be -(0.5+(pw-1)%(size+1))/(size+1).
Maybe. :)

An alternative solution retaining the original offsets would be to use:
c.FlipVertical()
PointResize( pw, ph, 0.5/(size+1), 0.5/(size+1), bw, bh )
Grid( lineint=size+1, bold=1, vbold=1, vbcolor=color )
FlipVertical()

which makes the grid lines start on the bottom instead of the top.

[2Bdecided]

damn, the gridsplit2 works but I need to convert to rgb which means it is no good for what I had in mindIs it only me that's wondering what you have got in mind?

Just nosey, that's all.

Cheers,
David.

[TheProfileth]

Is it only me that's wondering what you have got in mind?

Just nosey, that's all.

Cheers,
David.

Well I plan to use the grid as a mask and try and do some method of filtering with it, atleast that is the general plan, thus I also need a technique to remove said grid once filtering is over.
I will try the other methods to see if they work, hopefully something will work eventually.

[Gavino]

I think the offset needs to be -(0.5+(pw-1)%(size+1))/(size+1).
Maybe. :)

An alternative solution retaining the original offsets would be to use:
c.FlipVertical()
PointResize( pw, ph, 0.5/(size+1), 0.5/(size+1), bw, bh )
Grid( lineint=size+1, bold=1, vbold=1, vbcolor=color )
FlipVertical()

which makes the grid lines start on the bottom instead of the top.
Both of those are wrong too.
This is what I now think it should be (changes from -Vit- original marked in blue):
# Variant on GridSplit using V.Mohan's Grid function. Good for RGB images
# Size must be odd and at least 3
function GridSplit2( clip c, int size, int "color", int "xMod", int "yMod" )
{
Assert( size % 2 == 1 && size >= 3, "GridSplit2: size must be odd and at least 3" )

xMod = default( xMod, 1 )
yMod = default( yMod, 1 )
color = default( color, $000000 )

# Original dimensions
w = c.Width()
h = c.Height()

# Dimensions with grid lines, but may not fit given mods
nw = w + (w-1) / size + 1 # grid starts on 1st pixel
nh = h + (h-1) / size + 1 # grid starts on 1st pixel

# Dimensions with grid lines padded to fit mods
pw = ((nw + xMod - 1) / xMod) * xMod
ph = ((nh + yMod - 1) / yMod) * yMod

# Equivalent dimensions to above without grid lines - must pad to this size before rescale to ensure each
# block of "size" pixels will map to exactly "size+1" pixels in result
bw = float(size * pw) / (size+1)
bh = float(size * ph) / (size+1)

# Pad, then rescale using dimensions calculated. Also offset duplicated pixels to match grid function
c.FlipVertical()
PointResize( pw, ph, 0.5/(size+1), h-bh, bw, bh )
FlipVertical()

Grid( lineint=size+1, bold=1, vbold=1, vbcolor=color )

return last
}

[-Vit-]

I came up with a simpler version that just tweaks the vertical offset, no flip. Perhaps you've tested some more obscure cases though...

# Variant on GridSplit using V.Mohan's Grid function. Good for RGB images
# Size must be odd and at least 3
function GridSplit2( clip c, int size, int "color", int "xMod", int "yMod" )
{
Assert( size % 2 == 1 && size >= 3, "GridSplit2: size must be odd and at least 3" )

xMod = default( xMod, 1 )
yMod = default( yMod, 1 )
color = default( color, $000000 )

# Original dimensions
w = c.Width()
h = c.Height()

# Dimensions with grid lines, but may not fit given mods
nw = w + (w-1) / size
nh = h + (h-1) / size

# Dimensions with grid lines padded to fit mods
pw = ((nw + xMod - 1) / xMod) * xMod
ph = ((nh + yMod - 1) / yMod) * yMod

# Equivalent dimensions to above without grid lines - must pad to this size before rescale to ensure each
# block of "size" pixels will map to exactly "size+1" pixels in result
bw = float(size * pw) / (size+1)
bh = float(size * ph) / (size+1)

# Pad, then rescale using dimensions calculated. Also offset duplicated pixels to provide neat position for grid lines
c.PointResize( pw, ph, 0.5/(size+1), 1.5/(size+1) - 1, bw, bh )

Grid( lineint=size+1, bold=1, vbold=1, vbcolor=color )

return last
}

[Gavino]

The +1's on nw and nh are definitely needed, as the use of Grid() introduces an extra gridline at the start (compared to the original function with mt_lutspa). Otherwise you lose the last pixel in each row and column.

The vertical offset is tricky to work out because with RGB PointResize starts at the bottom, and the last pixel (unlike the first) is not at a fixed displacement from the gridlines. The floating point source height (bh) also complicates where it thinks the 'bottom' is. So I found it easier to work out with an inverted clip.

I used this pattern of repeating colours as a test:
function Line(int color) { BlankClip(width=200, height=1, color=color) }

StackVertical(Line(color_red), Line(color_green), Line(color_blue), Line(color_white))
StackVertical(last, last)
StackVertical(last, last)
StackVertical(last, last)
StackVertical(last, last)
StackVertical(last, last)

GridSplit2(3) # also try 5, 7, 9, 11 ,..

PointResize(width, 4*height)
The final PointResize is to make the result more visible for checking.

Apart from the missing final pixels (+1 problem), your new version seems to work.
I'm just not sure why. :)

[TheProfileth]

So, is there no possible way to do this in yuv12 :confused: and then I still need a function to then remove the grid that has been inserted

[-Vit-]

Did you try my post above (http://forum.doom9.org/showthread.php?p=1483652#post1483652)? It does seem to work, only limitation is that it inserts 2 pixel gaps not 1. I imagine the PointSize approach could be reversed, but I don't have time to do it at the moment.

[jmac698]

prof,
I'm writing a massive, fully general solution to this problem. It's completely original, I haven't had time to read these posts. I can think of some other uses. Here's a preview. (it doesn't really do anything but draw a test pattern in a very over-engineered way :)

testpattern

function testpattern {
#Create a uniquely colored pattern so that it is easy to see the results of the other functions
blu=box(color=color_blue)
yel=box(color=color_yellow)
grn=box(color=color_green)
red=box(,color=color_red)
stackhorizontal(yel,grn,red,blu)
stackhorizontal(last,last)
stackhorizontal(last,last)
stackvertical(last,last.turnright)
stackhorizontal(last,last.flipvertical)
}

function box(int "w", int "h", int "color", string "pixel_type", bool "fat", clip "template") {
#make a box, even a line, of color c, in given colorspace, using giving template video properties (except width, height, pixel_type)
#defaulting ot1x32 video pixels, black, YV12
#1 pixel sizes are supported
#fat=true leaves the result doublesize, which is a way to emulate yuv 4:4:4, i.e., yv12 is doublewidth and doubleheight with 2x2 "fat" pixels
w=Default(w,1)
h=Default(h,32)
pixel_type=Default(pixel_type,"YV12")
fat=Default(fat,false)
template=Default(template,blankclip(pixel_type=pixel_type))
color=template.isYUV?Default(color,$108080):Default(color,$000000)
assert(w>0 && h>0,translate(0,"en",w,h))
template#Note there's no way to completely copy properties between clips i.e. with blankclip (audiobit depth is not knowable)
convertto(pixel_type)
modw=pixel_type=="YV12"||pixel_type=="YV12"?2:LeftStr(pixel_type,3)=="RGB"?1:1
modh=pixel_type=="YV12"?2:pixel_type=="YUY2"?1:LeftStr(pixel_type,3)=="RGB"?1:1
modresize(w,h,modw,modh)
setcolor(color)#bug - support fat and skinny lines in YUV
}

function translate(int error, string lang, val "val1", val "val2", val "val3") {
#Present a predefined error message in a given language, possibly including some values
#error starts at 0, lang is the ISO 639-1 lang code plus ISO 3166-1 alpha-2 region (just a quick made-up way of specifying dialects)
intlang=lang=="en"||lang=="en-gb"||lang=="en-ca"?0:lang=="en-us"?1:lang=="pr"||lang=="pr-br"?2:0
msg=select(error, \
select(intlang, \
"Box: Width and Height must be at least 1 (Width=%.0f, Height=%.0f)", \
"Box: Width and Height must be at least 1 (Width=%.0f, Height=%.0f)", \
"error 0 lang "+lang \
) \
)
s=""
i=0
sub=extractto(MidStr(msg,i+1))
s=s+string(val1,sub)
i=i+StrLen(sub)
sub=extractto(MidStr(msg,i+1))
s=s+string(val2,sub)
i=i+StrLen(sub)
sub=extractto(MidStr(msg,i+1))
s=s+string(val2,sub)
i=i+StrLen(sub)
sub==""?s+MidStr(msg,i+1):s#Bug: If sub<>"" then check if anything left
}

function extractto(string str) {
#Extract the substring up to and including %*f
p1=FindStr2(str,"%")
p2=FindStr2(str,"f",p1)
p2>p1?MidStr(str,1,p2):""
}

function FindStr2(string str, string find, int "startpos") {
#FindStr with starting position
startpos=Default(startpos,1)
startpos=startpos<1?1:startpos
str=MidStr(str,startpos)
p=FindStr(str,find)
p==0?0:p+startpos-1
}

function convertto(clip c, string pixel_type) {
#convert clip to the given pixel_type and return
c
pixel_type=="YUY2"?converttoyuy2:pixel_type=="YV12"?converttoyv12:pixel_type=="RGB"?converttorgb: \
pixel_type=="RGB24"?converttorgb24:pixel_type=="RGB32"?converttorgb32:converttoyv12
}

function modresize(clip c, int w, int h, int modw, int modh) {
#Resize clip c mod modw, modh e.g. 3x3 with 2,1 ->4x3
w=(w+modw-1)/modw*modw
h=(h+modh-1)/modh*modh
pointresize(c,w,h)
}

function setcolor(clip c, int color) {
#Set the clip c to the color "color"
b2=byte(color,2)
b1=byte(color,1)
b0=byte(color,0)
c
isYUV?tweak(bright=-255,sat=0,coring=false).ColorYUV(off_y=b2, off_u=b1-128, off_v=b0-128): \
RGBAdjust(0,0,0,1,b2,b1,b0)
}

function byte(int x, int n) {
#Returns byte n of int x, e.g. x=65538, byte(x,0)=2, byte(x,2)=1
p1=Pow(2,n*8)
p2=Pow(2,(n+1)*8)
int((x-Floor(x/p2)*p2)/p1)
}

[Gavino]

#Note there's no way to completely copy properties between clips i.e. with blankclip (audiobit depth is not knowable)
From v2.58, BlankClip has the "sample_type" parameter.

And can't your setcolor function be done simply by using BlankClip(c, color=color)?
(or coloryuv for YUV clips)

[jmac698]

Amazing, I had no idea Blankclip took clip as an argument. Thanks! I also thought there was no audiobitdepth property, but I found that too. Whew! I want to make a string2() that takes any number of arguments too. I think the translate function should work from a file, and maybe if I write it, more people will include translations in their scripts.

[Gavino]

I had no idea Blankclip took clip as an argument.
That's what I was referring to way back in this post, when you first mentioned clip templates.

[jmac698]

Now that makes more sense. I started to write my templater too, with definitions for sd_DVD_NTSC , 1080p etc.

[TheProfileth]

So I looked at that script that jmac698 made, don't exactly see how in its current state it can be useful, but I am interested in it.
Also still hoping a solution will appear to my original request

[jmac698]

That's because I'm not done. Had real work to do.

[-Vit-]

TheProfileth: I'll ask again (http://forum.doom9.org/showthread.php?p=1484189#post1484189), have you tried my 2-pixel solution (http://forum.doom9.org/showpost.php?p=1483652&postcount=25)? It works without affecting chroma and it's the best you can do with YV12. It's reversible.

[TheProfileth]

TheProfileth: I'll ask again (http://forum.doom9.org/showthread.php?p=1484189#post1484189), have you tried my 2-pixel solution (http://forum.doom9.org/showpost.php?p=1483652&postcount=25)? It works without affecting chroma and it's the best you can do with YV12. It's reversible.

Oh sorry, I missed that and thought you were referring to the other methods above your last post, which I had tried and did not work, I will try your method. BTW if it does work I still need a way to reverse it afterwards