AviSynth 2.5.1 Crop Restrictions?

[Trip Machine]

Hi.

I'm not sure if this has been covered yet but I found two cropping restrictions that weren't present in 2.07.


1) In 2.07 I remember being able to crop with odd numbers in GKnot but it was okay since I was going to resize it afterwards. But in 2.5.1, I can't open an avs file in VDub with odd crop values even though I have a resize command with even values.


2) This one bothers me a little bit more. I found that I had to keep the left and right crop values equal. Because if I don't, when I playback the movie, there is a thin black bar about 2-4 pixels wide that runs on the right side of the movie and gets encoded.

So say if my left and right crop values are 2 and 14, then I would have end up changing it to 14 and 14, (which can cut out quite a bit from the picture), if I wanted to crop with no visible black bars.


Thanks for reading.

[sh0dan]

Odd crop numbers simply isn't possible because of the YV12 colorspace. (technical stuff) (http://www.avisynth.org/index.php?page=DataStorageInAviSynth)

If you insist on cropping odd numbers, use the trim functions within the resize command. See the docs on how to do this.

[Trip Machine]

Oh okay, I guess I can stick to even values. No big deal. Heck it's only 1 more pixel.

But what about the left and right crop values having to be the same as stated in number 2)? Is this due to the colorspace of YV12 as well?

[sh0dan]

But what about the left and right crop values having to be the same as stated in number 2)? Is this due to the colorspace of YV12 as well?

There is only chroma every second pixel - if you crop at odd numbers on either side, chroma will be shifted a pixel.
Therefore it is not possible to crop odd numbers without resampling chroma (which is done in the resizer).

[xekon]

I am encoding a 1080p source, usually my crop is 132 or 140 off the top and bottom to maintain a mod 16 resolution.

I am working with a source that need 139 off the top and 141 off the bottom, for whatever reason they didnt just center the picture, and have 140 on top and bottom....

so crop(0,139,0,-141) does not work.

I am having trouble finding the documentation on the resizer that shows how to crop odd numbers, could anyone give me an example, here is what I am trying to do:

crop(0,139,0,-141)

edit: I am using Avisynth 2.6

[StainlessS]

Either crop top and bottom by even numbers, OR, use a resizer instead.
EG, Spline36Resize(x,y,0,139,-0,-141) # use x,y as you wish.

(Not sure you'll get an answer from those above, back in 2003).

[feisty2]

crop(0,139,0,-141)

edit: I am using Avisynth 2.6

a little "pointresize" hack can get ur work done

#1920x1080 yuv420p16 input#
y=stackvertical (greyscale ().dither_get_msb ().converttoyv24 ().crop(0,139,0,-141),greyscale ().dither_get_lsb ().converttoyv24 ().crop(0,139,0,-141))
ufull=utoy ().dither_resize16 (1920,1080,kernel="point")
u=stackvertical (ufull.dither_get_msb ().converttoyv24 ().crop(0,139,0,-141),ufull.dither_get_lsb ().converttoyv24 ().crop(0,139,0,-141)).dither_resize16 (960,400,kernel="point")
vfull=vtoy ().dither_resize16 (1920,1080,kernel="point")
v=stackvertical (vfull.dither_get_msb ().converttoyv24 ().crop(0,139,0,-141),vfull.dither_get_lsb ().converttoyv24 ().crop(0,139,0,-141)).dither_resize16 (960,400,kernel="point")
ytouv (u,v,y)

[feisty2]

and if ur input is simply yv12
remove all "dither_get_xsb" and "stackvertical" stuff
and replace "dither_resize16" with "pointresize"
hope it helps

[StainlessS]

If you just want to crop without resize (since you are using v2.6 avisynth, and assuming standard 8 bit YV12)

ConvertToYV24()
crop(0,139,0,-141)
ConvertToYV12()

should work, and be even height

[feisty2]

If you just want to crop without resize (since you are using v2.6 avisynth, and assuming standard 8 bit YV12)

ConvertToYV24()
crop(0,139,0,-141)
ConvertToYV12()

should work, and be even height

this "crop" is lossy

[xekon]

Either crop top and bottom by even numbers, OR, use a resizer instead.
EG, Spline36Resize(x,y,0,139,-0,-141) # use x,y as you wish.

(Not sure you'll get an answer from those above, back in 2003).

ok so with a 1920x1080 source and crop(0,139,0,-141) that gives me a total crop of 280 in height giving me a new resolution of 1920x800

do I resize to the original size or do i resize to the size that it is after the crop? since I am not actually after the resize but just using it as a workaround to crop odd number of lines.

Spline36Resize(1920,1080,0,139,-0,-141)
or
Spline36Resize(1920,800,0,139,-0,-141)

Thanks! Also the Spline36Resize is a simple one line, do I get some befits by using the "pointresize" hack posted by feisty2?

Thanks guys, I really appreciate it.

[Asmodian]

do I resize to the original size or do i resize to the size that it is after the crop? since I am not actually after the resize but just using it as a workaround to crop odd number of lines.

Spline36Resize(1920,1080,0,139,-0,-141)
or
Spline36Resize(1920,800,0,139,-0,-141)

Spline36Resize(1920,800,0,139,-0,-141)

Easy to test too. ;)

Thanks! Also the Spline36Resize is a simple one line, do I get some befits by using the "pointresize" hack posted by feisty2?

feisty2's hack is lossless while with the resize the chroma goes through the Spline36 interpolation to move the 1/2 chroma pixel over.

This should be a good translation of feisty2's hack for yuv420p(8):
y=ConvertToY8().Crop(0,139,0,-141).ConvertToYV12()
u=utoy().PointResize(1920,1080).ConvertToY8().Crop(0,139,0,-141).PointResize(960,400)
v=vtoy().PointResize(1920,1080).ConvertToY8().Crop(0,139,0,-141).PointResize(960,400)
YtoUV(u,v,y)

[foxyshadis]

this "crop" is lossy

There is no not-lossy crop for odd values. You would literally have to design a custom YV12->RGB filter to make that work, because the only standards are MPEG1, MPEG2, and DV, none of which site the chroma above the even lines. All players and editors will convert it back as if it's below and therefore shift chroma down if you don't blend it properly.

[xekon]

There is no not-lossy crop for odd values. You would literally have to design a custom YV12->RGB filter to make that work, because the only standards are MPEG1, MPEG2, and DV, none of which site the chroma above the even lines. All players and editors will convert it back as if it's below and therefore shift chroma down if you don't blend it properly.

of the posted solutions, which is the least lossy? or am I better off just cropping 140 off the top and bottom, ill lose one pixel line of information on the top, and gain 1 pixel black bar on the bottom, would prefer to avoid doing that.

I tried this one and it works:

y=ConvertToY8().Crop(0,139,0,-141).ConvertToYV12()
u=utoy().PointResize(1920,1080).ConvertToY8().Crop(0,139,0,-141).PointResize(960,400)
v=vtoy().PointResize(1920,1080).ConvertToY8().Crop(0,139,0,-141).PointResize(960,400)
YtoUV(u,v,y)

but I would like to use whichever is least lossy. my source material is YUV

[foxyshadis]

Least lossy is definitely cropping on an even border without touching chroma, but then you end up with that bottom black line (unless you want to duplicate it from the line above). Shifting chroma a pixel down isn't likely to be noticeable at 1080p... but neither is perfect. The trade-off is up to you.

[Asmodian]

There is no not-lossy crop for odd values. You would literally have to design a custom YV12->RGB filter to make that work, because the only standards are MPEG1, MPEG2, and DV, none of which site the chroma above the even lines. All players and editors will convert it back as if it's below and therefore shift chroma down if you don't blend it properly.

Yes, I was incorrect. It might be mathematically lossless in YUV (except 1 line) but the hack shifts the chroma by 1 luma line.

Each line represents a luma line while 1, 2, 3.. etc represent the unique chroma value. 1, 2, 3, etc. are always paired vertically because you cannot have half chroma pixels.

Original - Option 1 - Option 2
1
1 - 2 - 1
2 - 2 - 1
2 - 3 - 2
3 - 3 - 2
3 - 4 - 3
4 - 4 - 3
4 - 5 - 4

I suggest the resize method as being better. It is better to slightly blur chroma than shift it. Simply using an even crop might be better still.

[feisty2]

what about pointresize (960,400,src_left=0,src_top=-1)
will this fix the bug?

[feisty2]

or just use dither_convert_yuv_to_rgb (chromak="point") then crop then dither_convert_rgb_to_yuv (chromak="point")
leave all the chromaplace problems to ditherpackage
im pretty sure ditherpackage would do the right job on chromaplace

[xekon]

is there a way to read the chroma values before and after to confirm if the chroma is being shifted? would be cool to crop it with odd numbers so I don't have the black bar at the bottom.

[feisty2]

is there a way to read the chroma values before and after to confirm if the chroma is being shifted? would be cool to crop it with odd numbers so I don't have the black bar at the bottom.

yes, u can see the chroma by using utoy or vtoy
then compare the result to the normally cropped chroma and see if its shifted

[Asmodian]

The chroma has to be shifted, see my example. There is no way to have a 1/2 chroma pixel crop without either shifting or interpolating it. This is because of the fixed chroma placement during YUV -> RGB as foxyshadis pointed out. You can either shift the chroma 1 luma pixel down, 1 luma pixel up, or interpolate it.

Take a checkerboard, cut off 1/2 the top row of squares, now align that edge along any row and get the squares to line up. It cannot be done, you have to have a 1/2 row mismatch.

[feisty2]

The chroma has to be shifted, see my example. There is no way to have a 1/2 chroma pixel crop without either shifting or interpolating it. This is because of the fixed chroma placement during YUV -> RGB as foxyshadis pointed out. You can either shift the chroma 1 luma pixel down, 1 luma pixel up, or interpolate it.

Take a checkerboard, cut off 1/2 the top row of squares, now align that edge along any row and get the squares to line up. It cannot be done, you have to have a 1/2 row mismatch.

i dont get it
if u wanna shift chroma up 1/2pixel so it would fit luma, it can be done
just 4x upscale the chroma with pointresize and crop the first top pixel then add 1pixel grayborder at the last bottom row (or pad the last row for 1pixel), then scale it back
chroma will be shifted up 1/2 pixel

[Asmodian]

You can only have full chroma pixels values, 2 luma pixels aligned to 1 chroma pixel in both dimentions (for YV12), if you move the chroma under the luma 1 luma pixel the alignment is different.

You cannot scale it back 2x (using point resize) without shifting it up or down half a chroma (1 luma) pixel. The YV12 -> YV24 is only so you can "cut off 1/2 the top row of squares", the problem remains.

I'll try to do a better example (horizontal for space):
YV12
luma values: 016 060 100 160 110 035
chroma values: --128-- --030-- --096--

YV24 after crop
luma values: 060 100 160 110 035 022
chroma values: 128 030 030 096 096 103

YV12
luma values: 060 100 160 110 035 022 or 060 100 160 110 035 022
chroma values: --128-- --030-- --096-- or --030-- --096-- --103--

You cannot change the alignment; it is defined in the YUV -> RGB matrix.
It would take interpolation to generate chroma values other than 128, 030, 096, or 103

[feisty2]

i mean after 2x upscale and scaling back
chroma was shifted 1/2 pixel down right?
then what would happen if i shift it up 1/2 pixel after cropping and scaling back to yv12 by 4x upscale it, crop the first row repeat the last row and scale it back
technically, it would shift chroma up 1/2 pixel right?
i just couldn't understand why it still ain't working

[DarkSpace]

Just so this possibility is mentioned also, you could resize only the chroma channels and keep operating in YV12 without going to YV24:

source = YourVideo()
y = source.ConvertToY8().Crop(0, 139, 0, -141)
uv = source..Crop(0, 138, 0, -140)
u = source.UToY8().Resize(y.Width() / 2, y.Height() / 2, 0, 0.5, -0, -0.5) # Replace Resize() with your favorite resizer!
v = source.VToY8().Resize(y.Width() / 2, y.Height() / 2, 0, 0.5, -0, -0.5) # If you resize in 16 bit (e.g. using DitherTools), you'll need to uncomment the next line!
# y = y.Dither_convert_8_to_16()
YToUV(u, v, y)

As I said, I'm just mentioning it for completeness' sake. If it already has been mentioned, I must have missed it, but the closest I could find was the business about upscaling to YV24 (with PointResize) and then cropping, then scaling back to YV12 (PointResize, again).

Edit: Out of curiosity, I tried making a function of the above script. No guarantees, but I think it should work:

# I'm bad at naming things, so feel free to rename this.
function UnevenCrop(clip yv12, int "left", int "top", int "right", int "bottom", String "kernel", bool "lsb_in", bool "lsb_out") {
left = Default(left, 0)
top = Default(top, 0)
right = Default(right, -0)
bottom = Default(bottom, -0)
kernel = Default(kernel, "cubic")
lsb_in = Default(lsb_in, false)
lsb_out = Default(lsb_out, true)

Assert(yv12.IsYV12(), "The clip must be YV12!")
Assert(((left + right) % 2 == 0) && ((top + bottom) % 2 == 0), "The final dimensions of the clip must be even!")
Assert(right <= 0 && bottom <= 0, "The right and bottom crop arguments must specify offsets, not dimensions!")

cropL = (left / 2) * 2
cropT = (top / 2) * 2
cropR = (right / 2) * 2
cropB = (bottom / 2) * 2

offsetL = (left - cropL) / 2.0
offsetT = (top - cropT) / 2.0
offsetR = (right - cropR) / 2.0
offsetB = (bottom - cropB) / 2.0

y = lsb_in ? yv12.ConvertToY8().Dither_crop16(left, top, right, bottom) : yv12.ConvertToY8().Crop(left, top, right, bottom)
uv = lsb_in ? yv12.Dither_crop16(cropL, cropT, cropR, cropB) : yv12.Crop(cropL, cropT, cropR, cropB).Dither_convert_8_to_16()
u = uv.UToY8().Dither_resize16(y.Width() / (lsb_in ? 4 : 2), y.Height() / (lsb_in ? 4 : 2), src_left=offsetL, src_top=offsetT, src_width=offsetR, src_height=offsetB, kernel=kernel)
v = uv.VToY8().Dither_resize16(y.Width() / (lsb_in ? 4 : 2), y.Height() / (lsb_in ? 4 : 2), src_left=offsetL, src_top=offsetT, src_width=offsetR, src_height=offsetB, kernel=kernel)

y = lsb_in == lsb_out ? y : lsb_out ? y.Dither_convert_8_to_16() : y.DitherPost(mode=-1)
u = lsb_out ? u : u.DitherPost(mode=-1)
v = lsb_out ? v : v.DitherPost(mode=-1)

return YToUV(u, v, y)
}

[feisty2]

okay, I see the problem now
I tried that 4x upscale trick and nothing really happened
the chroma is exactly the same as untouched, no shift up stuff
seems like a pointresize problem

[xekon]

There is no not-lossy crop for odd values. You would literally have to design a custom YV12->RGB filter to make that work, because the only standards are MPEG1, MPEG2, and DV, none of which site the chroma above the even lines. All players and editors will convert it back as if it's below and therefore shift chroma down if you don't blend it properly.

LOL, dang a lot of discussion here. I am even less certain about things than when we started. I am assuming most people just crop even number of lines and move on.

what is more compressible if I crop even number of lines:
1) black bar at the bottom of picture, or
2) duplicate the line above the black line to replace it

Also if anyone makes the "custom YV12->RGB filter" for odd crops let me know, I am assuming such a filter would be lossy though?

really seems like the best option is just crop even number of lines and move on.

Thanks for all the discussion :)

[feisty2]

I guess the most quality wise method would be first convert ur vid to yv24 with the best tool u can get like "nnedi3_resize16" (u can get it here https://nmm-hd.org/newbbs/viewtopic.php?f=7&t=1117)
then crop by odd numbers
then finally encode in yv24
cuz when u watch the vid, it's gonna be converted to rgb (4:4:4) anyway
and nnedi3_resize16 does a far better job than any known renderer (even madVR)
so why not just convert it to yv24 in avisynth with the best quality? :)

[bxyhxyh]

Cheapest and fastest method is to resize. And can you tell the loss from cropping done by resizers?

I do this way
Spline36Resize(1920,1074,0,3,0,-3).crop(0,136,0,-139)

I don't know if it is better than just Spline36Resize(1920,800,0,139,0,-141)

[Asmodian]

Just so this possibility is mentioned also, you could resize only the chroma channels and keep operating in YV12 without going to YV24:

I am pretty sure the resize will pass through the luma without touching it already. If a plane doesn't need resizing it isn't resized.

what is more compressible if I crop even number of lines:
1) black bar at the bottom of picture, or
2) duplicate the line above the black line to replace it

2) for sure

Cheapest and fastest method is to resize. And can you tell the loss from cropping done by resizers?

I do this way
Spline36Resize(1920,1074,0,3,0,-3).crop(0,136,0,-139)

I don't know if it is better than just Spline36Resize(1920,800,0,139,0,-141)

I assume you mean: Spline36Resize(1920,1074,0,3,0,-3).crop(0,136,0,-138)

Your method is slightly slower due to the two functions instead of one but they should be equivalent.

[bxyhxyh]

I assume you mean: Spline36Resize(1920,1074,0,3,0,-3).crop(0,136,0,-138)

Yes I meant 138.

Your method is slightly slower due to the two functions instead of one but they should be equivalent.
About speed you're right.
For quality I checked it by taking screenshots. Of course I couldn't see thier difference.

File Properties says:
crop(0,136,0,-138).Spline36Resize(1920,800,0,3,0,-3) - 1,950,999 bytes
Spline36Resize(1920,800,0,139,0,-141) - 1,950,990 bytes
Spline36Resize(1920,1074,0,3,0,-3).crop(0,136,0,-138) - 1,950,990 bytes

I checked two other frames as well. Second and third croppings seem equivalent. But first one...

[DarkSpace]

I am pretty sure the resize will pass through the luma without touching it already. If a plane doesn't need resizing it isn't resized.
That may be, but I don't share your faith regarding this. I agree that it's a logical thing to do, but since technically, the video isn't at the target dimensions yet, I'd rather I'm sure what's going on...

[foxyshadis]

Also if anyone makes the "custom YV12->RGB filter" for odd crops let me know, I am assuming such a filter would be lossy though?

It's only lossy if you ever try to convert it back to YV12. JanWillem32 (https://forum.doom9.org/showthread.php?t=157634) could probably show you how do it via pixel shader for playback, since he's already created multiple YUV->RGB shaders, but I don't know anything about pixel shaders, and that obviously only works in MPC and other PC players, plus you have to come up with a way to only use it for odd-cropped videos.

Personally, I would overcrop to mod-2 and let x264 pad it out, simplest fix and I'm unlikely to miss one line, but that's me. x264 will duplicate the last line to make everything mod-16 (1920x1080 is 1920x1088 internally already).

[Asmodian]

That may be, but I don't share your faith regarding this. I agree that it's a logical thing to do, but since technically, the video isn't at the target dimensions yet, I'd rather I'm sure what's going on...

The luma plane is already at the target dimensions after the crop, what could be done to it?

File Properties says:
crop(0,136,0,-138).Spline36Resize(1920,800,0,3,0,-3) - 1,950,999 bytes
Spline36Resize(1920,800,0,139,0,-141) - 1,950,990 bytes
Spline36Resize(1920,1074,0,3,0,-3).crop(0,136,0,-138) - 1,950,990 bytes

I checked two other frames as well. Second and third croppings seem equivalent. But first one...

Interesting, I assume the Spline36 interpolation uses information from more than 3 pixels away.

I too overcrop, one or two lines of video lost seems like the better option.

[xekon]

Least lossy is definitely cropping on an even border without touching chroma, but then you end up with that bottom black line (unless you want to duplicate it from the line above). Shifting chroma a pixel down isn't likely to be noticeable at 1080p... but neither is perfect. The trade-off is up to you.

my bottom line of pixels is black I would like to replace it with a copy of the line above, what is the avisynth function to duplicate/copy a line of pixels? been trying to search for it but I must not be using good search terms.

Thanks for all the great information, appreciate it :)

[foxyshadis]

my bottom line of pixels is black I would like to replace it with a copy of the line above, what is the avisynth function to duplicate/copy a line of pixels? been trying to search for it but I must not be using good search terms.

Thanks for all the great information, appreciate it :)

Crop first, then:

bottom=pointresize(width,15-(height+15)%16,0,(IsRGB()?height:0)-1,0,1)
stackvertical(last,bottom)
right=pointresize(15-(width+15)%16,height,-1,0,1)
stackhorizontal(last,right)

You need RGB or YV24 for odd values (or at least YUY2/YV16 for odd horizontal).

[Gavino]

bottom=pointresize(width,15-(height+15)%16,0,height-1,0,1)
...
The height-1 vs just -1 works around a bug in avisynth+'s resize cropping.
What bug? :confused:
Surely an offset of -1 (or 0) should by design give you the top row?
height-1 is required to get the bottom row.

[foxyshadis]

What bug? :confused:
Surely an offset of -1 (or 0) should by design give you the top row?
height-1 is required to get the bottom row.

Not quite, negative crops in avisynth wrap around, and this goes for resize crops as well. However, I realized my mistake: I was working in RGB, and avisynth doesn't hide the fact that it's stored upside down in the resize crops. Ugh. Well, I'll edit to fix that.

[Gavino]

Not quite, negative crops in avisynth wrap around
No they don't - they give an error. From transform.cpp:
if ( (_left<0) || (_top<0) )
env->ThrowError("Crop: Top and Left must be more than 0");
For 'resize crops', a negative offset is allowed and starts above the top edge.

I was working in RGB, and avisynth doesn't hide the fact that it's stored upside down in the resize crops.
That only affects which pixel is regarded as the 'nearest neighbour' in PointResize() (ie whether it takes the one above or the one below) - the offsets are still measured from the top of the image.

So, to get the bottom row, the correct offset for all colorspaces is height-1.
Similarly, for the rightmost row, it is width-1.

[foxyshadis]

That only affects which pixel is regarded as the 'nearest neighbour' in PointResize() (ie whether it takes the one above or the one below) - the offsets are still measured from the top of the image.

So, to get the bottom row, the correct offset for all colorspaces is height-1.
Similarly, for the rightmost row, it is width-1.

Then I'm not sure why width-1 gave me the left column instead of right. On the other hand, using -1 for top gave me the top instead of bottom. Maybe it is a bug after all.

[kotuwa]

Isn't there any easy way to PAD the NEAREST NEIGHBOR LINE !?...
:(

[colours]

caps caps caps interrobang ellipsis emoticon

PointResize with negative src_left/src_top, if I'm reading you right.

[Reel.Deel]

Padding? (http://forum.doom9.org/showthread.php?p=1596804#post1596804)

function Padding(clip c, int left, int top, int right, int bottom)
{
w = c.width()
h = c.height()
c.pointresize( w+left+right, h+top+bottom, -left, -top, w+left+right, h+top+bottom )
}

Padding only the right border, by 8 pixels:

yourclip.Padding(0,0,8,0)

[kotuwa]

This is about ConvertToYV24.

ConvertToYV24 can be used to crop 1 pixels, is it lossy? how?

And if the source is in YUV420p, then using ConvertToYV24 and recreating a YUV420p using x264 would be lossy?
What is the main difference compared to normal way without conversion?

I did 2 samples and found that the converted output gave slightly bigger output!

Here my tests...
Source: 1280x720. Same x264 settings within test.
Test A, Anime with animation tune. Test B, live with film tune.


Result A1: ............... crop(0, 2, 0, -2). (output: 1280x716). 1001 KiB
Result A2: ConvertToYV24() crop(0, 2, 0, -2). (output: 1280x716). 991 KiB
Result A3: ConvertToYV24() crop(0, 1, 0, -1). (output: 1280x718). 977 KiB

Result B1: ............... crop(0, 2, 0, -2). (output: 1280x716). 1.03 MiB
Result B2: ConvertToYV24() crop(0, 2, 0, -2). (output: 1280x716). 1.02 MiB
Result B3: ConvertToYV24() crop(0, 1, 0, -1). (output: 1280x718). 1.05 MiB

:confused:

1. What are the reasons for converted one giving smaller filesize?
Is it due to efficiency or loss of details?!

2. Why in test A, 718 height video is bigger than 716 height one?...

BTW... Thanks Colours for PM replies and all Others for the previous Replies
:]

[foxyshadis]

Assuming you're not encoding to Hi444, x264 is converting it back down to 4:2:0, so basically it's the same as using BilinearResize to 2x, then back down to 1x -- which slightly blurs the image. That's what's happening to the Chroma channel.

Here's an example so you can visualize how the up/down size looks after just one iteration, even though in your case it doesn't affect luma:

[colours]

Just to nitpick slightly, the default resampler the Convert* internal filters use is bicubic, and likewise, x264's default resampler is also bicubic. There still will be a slight blurring effect on the chroma, but it won't be as bad as shown in the screenshot.

The difference in file size between the various encodes is so tiny that you shouldn't bother treating it as anything statistically significant.

[kotuwa]

foxyshadis and colours, thanks for the replies!.. :)