Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Newbies

Reply
 
Thread Tools Search this Thread Display Modes
Old 23rd April 2012, 16:43   #21  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 4,103
Quote:
Originally Posted by lansing View Post
thanks for the help to all of you guys

And one more thing, if i ran neat video in virtualdub and output the result as lagarith lossless in YV12, before putting it into avs, will i get the same result as the avs conversion above?
No, it's slightly worse - I would do the conversion back in avisynth . Of course you can just as easily test it yourself. (There is even a sample video above with thin red text) . Whether or not the differences are enough to justify larger HDD storage demands for your goals is another discussion

I tested a bunch of combinations and different sources, and Gavino's suggestion seems the best overall in terms of least deterioration, blurring or aliasing for round tripping it (note there are situations when you may want "blocky" color edges e.g. some types of VFX work , and other times when you want smoother, chroma edges)

Last edited by poisondeathray; 23rd April 2012 at 16:53.
poisondeathray is offline   Reply With Quote
Old 23rd April 2012, 17:54   #22  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,193
ok thanks for the explanation
lansing is offline   Reply With Quote
Old 7th May 2012, 22:16   #23  |  Link
Soulvomit
Registered User
 
Join Date: May 2012
Posts: 27
Is there a way of converting interlaced YV12 to RGB without the shift in chroma using chromaresample="point" and preserving the interlacing?
Soulvomit is offline   Reply With Quote
Old 9th May 2012, 11:31   #24  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,387
Quote:
Originally Posted by Soulvomit View Post
Is there a way of converting interlaced YV12 to RGB without the shift in chroma using chromaresample="point" and preserving the interlacing?
The interlaced equivalent of my code in post#19 is:
Code:
ConvertToYV24(interlaced=true, chromaresample="point")
MergeChroma(PointResize(width, height, 0, 2))
ConvertToRGB32()
... # filtering in RGB32
ConvertToYV12(interlaced=true, chromaresample="point")
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 13th May 2012, 01:50   #25  |  Link
Soulvomit
Registered User
 
Join Date: May 2012
Posts: 27
Thanks for responding. I would like to point out though converting to YV24 isn't as lossless at it should be with AviSynth.
Soulvomit is offline   Reply With Quote
Old 16th May 2012, 17:54   #26  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,387
Quote:
Originally Posted by Soulvomit View Post
I would like to point out though converting to YV24 isn't as lossless at it should be with AviSynth.
What do you mean by that?
Which case(s) are you talking about?
Certainly, conversion from RGB to YV24 (like any RGB-YUV conversion) is subject to rounding errors within 8-bit accuracy.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 18th May 2012, 04:18   #27  |  Link
Soulvomit
Registered User
 
Join Date: May 2012
Posts: 27
Sorry, I should have specified. Yes, going from RGB to YV24 isn't as lossless with 'Synth as it is with VirtualDub.
Soulvomit is offline   Reply With Quote
Old 18th May 2012, 11:47   #28  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,387
Quote:
Originally Posted by Soulvomit View Post
going from RGB to YV24 isn't as lossless with 'Synth as it is with VirtualDub.
Evidence?

Does VirtualDub even support YV24?
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 18th May 2012, 12:54   #29  |  Link
Soulvomit
Registered User
 
Join Date: May 2012
Posts: 27
Never mind. I tried RGB>YV24>RGB in 'Dub again and it isn't lossless. I could have sworn it was as I've done it before and was going by that.
Soulvomit is offline   Reply With Quote
Old 26th November 2012, 20:32   #30  |  Link
zee944
Registered User
 
Join Date: Apr 2007
Posts: 240
I've a problem related to this. I've learned from this topic how to do YV12<-->RGB32 conversion without chroma shift, but in-between I have to do some cropping as well. When I use even numbers to crop, everything is fine:

Code:
  ConvertToYV24(chromaresample="point")
  MergeChroma(PointResize(width, height, 0, 1))
  ConvertToRGB32()

  Crop(10,104,-10,-100)

  # ...filtering, etc...

  ConvertToYV12(chromaresample="point")

  # ...further filtering, etc...

  AddBorders(10,104,10,100)
...but when I crop by odd values, things gets nasty:

Code:
  ConvertToYV24(chromaresample="point")
  MergeChroma(PointResize(width, height, 0, 1))
  ConvertToRGB32()

  Crop(10,105,-10,-99)

  # ...filtering, etc...

  ConvertToYV12(chromaresample="point")

  # ...further filtering, etc...

  ss=2
  PointResize(width*ss, height*ss)
  AddBorders(10*ss, 105*ss, 10*ss, 99*ss)
  PointResize(width/ss, height/ss)
The cropping by odd numbers (and adding the borders back eventually with supersampling) leads to heavy chroma shift, very noticeably on the red parts. I suspect that the PointResize() is responsible for this, but I don't know how to avoid it. Can you help?
zee944 is offline   Reply With Quote
Old 26th November 2012, 21:55   #31  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,173
PointResize is also known as Nearest Neighbour.

There is no interpolation it chooses the value of the closest geographical pixel.

For YV12, if pixel 1 is red and pixel 3 is green, what colour will pixel 2 be? Let's assume Green, now crop off 1 pixel, pixel 2 becomes pixel 1, 4 becomes 3, etc. Oops we just shifted the chroma ....
IanB is offline   Reply With Quote
Old 27th November 2012, 01:41   #32  |  Link
zee944
Registered User
 
Join Date: Apr 2007
Posts: 240
Quote:
Originally Posted by IanB View Post
PointResize is also known as Nearest Neighbour.

There is no interpolation it chooses the value of the closest geographical pixel.
Well I've tried replacing the last PointResize() with Lanczos4Resize(), which looked better but there was still chroma shift, so I abandoned it. It isn't the closest I can get, or is it?
zee944 is offline   Reply With Quote
Old 27th November 2012, 04:37   #33  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,798
It is the ConvertToYV12(chromaresample="point") that is the issue. Cropping by one half a color sample and using point resize is supposed to shift chroma, as IanB explained, no way around it.

This seems to not shift chroma and looks better with my test than the simple ConvertToYV12(chromaresample="lanczos"):
Code:
PointResize(last.width*2,last.height*2)
ConvertToYV12(chromaresample="point")
LanczosResize(last.width/2,last.height/2)
But I am at a loss to explain why, probably something to do with resizing the luma along with the chroma.

Better to crop in multiples of 2.

I used this test script though ffdshow (YV12->NV12) and MadVR (0.85.1, nearest neighbor):
Code:
imagesource("red.png", pixel_type = "RGB32")
PointResize(30,30)
ConvertToYV12(chromaresample="point")
addborders(2,2,2,2)
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB32()
Crop(0,1,0,-1)
PointResize(last.width*2,last.height*2)
ConvertToYV12(chromaresample="point")
LanczosResize(last.width/2,last.height/2)
An aside: For the same reasons you should not be using super sampling and point resize at the same time. Using point resize undoes the super sampling. I think your example would just add 106 to the top and 98 to the bottom.

Last edited by Asmodian; 27th November 2012 at 06:59.
Asmodian is offline   Reply With Quote
Old 27th November 2012, 18:32   #34  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,387
Quote:
Originally Posted by Asmodian View Post
An aside: For the same reasons you should not be using super sampling and point resize at the same time. Using point resize undoes the super sampling. I think your example would just add 106 to the top and 98 to the bottom.
Not exactly.

The purpose of the supersampling is to end up adding borders with an odd number of pixels (here 105 and 99, matching the earlier Crop). This works for the luma, thus restoring the uncropped luma pixels to their original positions. However (and this is probably what you meant), it adds 53 chroma pixels to the top and 49 to the bottom, so chroma is shifted down by 1 luma pixel (2*53 - 105).

In addition, the earlier odd-numbered Crop has introduced a shift of its own, amounting to 1 luma pixel, so the final result has a shift of 2 luma pixels.

However, as this is an even number (and we have a YV12 clip), it can be easily corrected by adding a final
MergeChroma(PointResize(width, height, 0, 2))

Thus the following sequence is completely lossless (except of course for the pixels cropped off).
Code:
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
#ConvertToRGB32() removed to make completely lossless

Crop(10,105,10,-99)

ConvertToYV12(chromaresample="point")

ss=2
PointResize(width*ss, height*ss)
AddBorders(10*ss, 105*ss, 10*ss, 99*ss)
PointResize(width/ss, height/ss)
MergeChroma(PointResize(width, height, 0, 2))
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 27th November 2012, 20:20   #35  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,798
I thought it had to move the chroma without interpolation.

Oh, I see. You moved the chroma back after making the video mod2 again! Seems so obvious now. Thanks.

edit: it is somewhat embarrassing how well I feel I understand YV12, point resize, etc. and how bad I am at seeing the (in retrospect, at least) obvious consequences.

You are also right, I was only thinking about the chroma when looking at supersampled addboarders (but I didn't think I was).

Last edited by Asmodian; 27th November 2012 at 20:31.
Asmodian is offline   Reply With Quote
Old 27th November 2012, 21:12   #36  |  Link
zee944
Registered User
 
Join Date: Apr 2007
Posts: 240
Nice, this works, thanks Gavino.

However, it's quite frustrating that I have to remember how I cropped the image earlier (by even or by odd values), then figure out if even or odd borders I want to add now and act accordingly. Can the colorspace conversions and cropping/adding borders be separated with a well-thought out function? I mean, to do a color conversion anytime, adding/cropping anytime by any values without taking into account what and how happened before, yet keep the chroma intact all the time?
zee944 is offline   Reply With Quote
Old 27th November 2012, 22:38   #37  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,387
Quote:
Originally Posted by Asmodian View Post
Oh, I see. You moved the chroma back after making the video mod2 again! Seems so obvious now. Thanks.

edit: it is somewhat embarrassing how well I feel I understand YV12, point resize, etc. and how bad I am at seeing the (in retrospect, at least) obvious consequences.
If it's any consolation, I don't think it's very 'obvious'.
I had to sit down with pencil and paper and trace out where the individual chroma pixels went at each stage of the process, getting quite confused until I was finally sure I had worked it out correctly.

Quote:
Originally Posted by zee944 View Post
Can the colorspace conversions and cropping/adding borders be separated with a well-thought out function? I mean, to do a color conversion anytime, adding/cropping anytime by any values without taking into account what and how happened before, yet keep the chroma intact all the time?
I'm not sure if that's possible. I'll need to think about it for a while and my head still hurts after the earlier effort.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 28th November 2012, 13:59   #38  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,387
Quote:
Originally Posted by zee944 View Post
Can the colorspace conversions and cropping/adding borders be separated with a well-thought out function? I mean, to do a color conversion anytime, adding/cropping anytime by any values without taking into account what and how happened before, yet keep the chroma intact all the time?
I might be able to come up with something that could help you, but before I spend more time thinking about it, are you really sure your images are so precise that you need to crop by 105 instead of 106 or 104?
It would certainly be simpler just to restrict your crops to even numbers.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 28th November 2012, 16:40   #39  |  Link
zee944
Registered User
 
Join Date: Apr 2007
Posts: 240
Quote:
Originally Posted by Gavino View Post
I might be able to come up with something that could help you, but before I spend more time thinking about it, are you really sure your images are so precise that you need to crop by 105 instead of 106 or 104?
For anyone else, no - it's pretty poor material noone else would care about. As for me, if there would be no general solution I would still crop by 105 and use your chroma-merging trick somehow. Your posts have helped me tremendously in the past, and I'm sure I'll ask for help in the future, so don't spend time with this one, at least not yet. The by-pass (the chroma-merging trick) has already been covered, I'll try to use that.

Last edited by zee944; 28th November 2012 at 16:59.
zee944 is offline   Reply With Quote
Old 30th November 2012, 10:46   #40  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,387
@zee944: Strange how the mind works - while thinking about something else, a relatively simple solution to your problem occurred to me...

You can use these customised wrapper functions for Crop and AddBorders which together produce the right results for both even and odd crop values.
Code:
function MyCrop(clip c, int left, int top, int right, int bottom) {
  topc = top%2 == 0 ? top : top+1
  bottomc = (bottom > 0 || top%2 == 0) ? bottom : bottom+1
  c.Crop(left, top, right, bottom)
  top%2 !=0 ? MergeChroma(c.Crop(left, topc, right, bottomc)) : last
}

function MyAddBorders(clip c, int left, int top, int right, int bottom) {
  ss = top %2 == 0 ? 1 : 2

  c
  PointResize(width*ss, height*ss)
  AddBorders(left*ss, top*ss, right*ss, bottom*ss)
  PointResize(width/ss, height/ss)
}
In outline, your script would look like this:
Code:
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))

MyCrop(10,105,-10,-99) # must do in YV24, so BEFORE RGB conversion

ConvertToRGB32()

# ...filtering, etc...

ConvertToYV12(chromaresample="point")

# ...further filtering, etc...

MyAddBorders(10, 105, 10, 99)
The (vertical) crop values can then easily be changed from odd to even without changing the rest of the script.
It works by ensuring that the chroma is always cropped with an even value, even if the luma is cropped with an odd value.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Reply

Tags
colorspace conversion, quality, rgb32, yv12

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:46.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.