|
|
| Gubel |
| Posted: Jan 25 2013, 04:25 AM |
 |
|
Member
Group: Members
Posts: 14
Member No.: 35995
Joined: 22-January 13
|
Hello!
My request is very simple: I'm looking for a very simple filter that allows me to shift the chroma-UV-components pixel-wise horizontaly and verticaly. I know that Avidemux has a (very poor) option to do this, and ffdshow capable of shifting the color. But it would be nice to have a simple filter for the VirtualDub filter-chain, so I could open the preview-window and andjust the values at a critical frame easily.
Please don't tell me something about "Flaxen's VHS", this is a filter from the old days of VD where it only supported RGB! So with this filter the incoming YUV-data are converted to RGB prior the "Flaxen's"-filter, converted back to YUV, and then to RGB again. Proper chroma-shift is impossible and senceless when the video has been converted to RGB anytime. YUV has to stay YUV, from the video-tape until the final video-file!
So if it doesn't exist, I don't think it would be difficult to write a filter for this simple operation, is it? There could be a little config-window with two sliders +/- horizontal/vertical and a preview button. The only thing the filter would have to do is: grab the incoming YUV-data and move the UV-components a few pixels in x/y-direction in front of the Y-component.
I'm not a programmer, so would somebody be able to make this simple little filter? I believe it would be only 10 minutes or so to work for an experienced *.vdf-programmer?!? 
Thanks for your replies!
Best regards
Alex
|
|
| jpsdr |
| Posted: Jan 25 2013, 10:00 AM |
|
|
Advanced Member
Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06
|
I personnaly had developped a filter, but horizontal only. |
|
| Gubel |
| Posted: Jan 26 2013, 02:44 AM |
|
|
Member
Group: Members
Posts: 14
Member No.: 35995
Joined: 22-January 13
|
Sounds good! 
You only did it for yourself? How complex was the little "project"? Would it be possible to add a vertical shift-option?
If yes, give me the the PayPal-adress to spend you 10 billion dollars! 
I still can't imagine that there are so many filters out there, but no simple chroma-shift...  |
|
| jpsdr |
| Posted: Jan 26 2013, 02:05 PM |
|
|
Advanced Member
Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06
|
Get my projects here : http://jpsdr.free.fr/XBMC/Filters.rar
Notify me when you've retrieve them.
|
|
| Gubel |
| Posted: Jan 27 2013, 02:29 AM |
|
|
Member
Group: Members
Posts: 14
Member No.: 35995
Joined: 22-January 13
|
Thank you! I've downloaded the file. Wow, many projects!
I think I need the 32-bits versions, OK. First I deleted the empty "Release_***" folders. But now I don't know what to do with that *.asm / *.cpp / *.rc files... 
I tried to put them into the "plugins"-folder in the VD program directory, but it didn't work...
Here the ffdshow shift filter (sorry, it's in german):
That's what I would wish to have for VirtualDub. Of course I can use this ffdshow-filters while saving to AVI when selecting the "ffdshow Video Codec" and write another intermediate uncompressed YUY2-AVI "through" ffdshow. But when I want to use a third-party codec (DivX or x264) + the ffdshow filters, I would have to load and encode from this intermediate (processed) YUY2-AVI again. This is very space and time intensive. Another disadvantage is the missing realtime-preview to find the right settings.
Another alternative is to use the possibility of ffdshow to use its own filters within the VD filter-chain, but that filter only accepts RGB as input, so VD converts it to RGB, ffdshow back to YUV and back to RGB again before it returns the data to the VD-chain. Outputting YUV to ffdshow directly is only possible via "video codec"-option (preconditioned that VD "color depth" -> "output format to compressor" is set to "same as input" or any other YUV-option).
-> Useless and very annoying!!
That's why I'm why I'm dreaming of such a simple filter for VD directly...
|
|
| jpsdr |
| Posted: Jan 27 2013, 09:51 AM |
|
|
Advanced Member
Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06
|
Sorry, i thought you know how to compile and make project, and eventualy wanted to start from my project, and wanted to modify the source code to match your needs.
I was apparently mistaken.
In that case, download this : http://jpsdr.free.fr/XBMC/Filtres_JPSDR.rar
This is the compiled version. Just put the .vdf file matching your processor
in the plugins directory of VDub if you want to use the Intel compiled version,
otherwise use the Release_XP_P4.
The Chroma Shift filter will allow you to shift horizontaly.
I don't have vertical shift, and don't intend to do it. |
|
| Gubel |
| Posted: Feb 9 2013, 09:29 PM |
|
|
Member
Group: Members
Posts: 14
Member No.: 35995
Joined: 22-January 13
|
Hello back!
Thank you, I've downloaded your plugins (respectively the Plugin, since it a single *.vdf-file).
Much work I think, respect! You were right, I'm not a programmer (sorry) - I'm more the man who knows how to work right with the "given frontends".
Never look a gift horse in the mouth - of course! But yout "Chroma Shift"-plugin does something wrong (*sorry*): When both values (Cb and Cr) are set to equal levels (as it is in most cases - don't know in which case I would need to adjust them seperately), the Y-channel is shifted beyond the chroma patterns. This shifts the "actual image" Of course, I could add the filter twice in the chain, 1x only Cb, 1x only Cr. Then it should work correctly...
For the missing vertical shift I would also have a workaround: rotate the picture by 90° degrees, use the (horizontal) shift-filter and rotate it back.
Problem: The internaly "rotate"-filter in VD only works in RGB32  ...
I think I'll stick with the ffdshow-methode..
Thank you anyway!
Regards...Alex |
|
| jpsdr |
| Posted: Feb 10 2013, 09:20 AM |
|
|
Advanced Member
Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06
|
No, it's not wrong, it's on purpose : Shifting Cb/Cr to the left is finaly the same thing that shifting Y to the right.
But, if you want to shift Cb/Cr of one pixel to the left, but you are in YV12 format, how can you do that ? If you work only on Cb/Cr channels, you can't ! You can only shift by step of 2. But, if you're working on Y, it's another story. In that case, you can, you just have to shift Y of one pixel to the right.
So, what i'm doing is the following :
If Cb/Cr have the same value and same direction, it's Y which is shifted on the other way of the value asked. This allow any shifting value on any format, no limitation because of sub sampled chroma.
If Cb/Cr have different values and/or different directions, the value is rounded to the first valid value up (asking a shift of 1 on YV12 will produce a shift of 2), and it's chroma wich is shifted. |
|
| Gubel |
| Posted: Feb 10 2013, 12:45 PM |
|
|
Member
Group: Members
Posts: 14
Member No.: 35995
Joined: 22-January 13
|
Yes, I instantly knew what you're talking about. I hadn't thought about that - right.
So, we mostly have to deal with 4:2:2 (YV16, YUY2, UYVY, ...) and 4:2:0 (YV12, ...). In both cases the horizontal chroma-resolution is half the size of the luma. In a 400x300 pixels YV12-video for example the lume-pane has 400x300 pixels of resolution, the chroma-panes only 200x150 - so they were resized before they are overlayed...
Of course shifting luma about 5 pixels to the right is the same than shifting chroma 5 pixels to the left, with the difference that the "actual picture" (luma) moves to the right (I could even avoid that by padding and cropping before and afterwards), but you can move the full-sampled Y-channel pixel-wise while you can move the half-sampled C-channels only 2-pixel-wise. So without interpolation the chroma-panes could only be moved by 4 or 6 pixels, not 5 - the pixel-amount would have to be even.
That's what you mentioned above, right?
But what does the tool do, when moving Cr 3 pixels to the left, and Cb 2 pixels to the right for example? Then the pixel-difference between the two half-sampled chroma-fields is not even, so it actually would not be possible?
I think the easiest way would be to work only in 4:4:4-sampled YV24 colorspace. When you request 4:4:4 as input, if not, VD would convert it for you in the filter chain I think. The output could be 4:4:4 also again, almost every codec would accept it as input and if not, one can convert it back to YUY2 or YV12 by using "convert format"...
Of course, I'm only the petitioner and not the programmer (who has to do the hard work), so when you don't intend to do further development to your filters, I'll have to accept that!
So that's only only my 2 cents...
Regards! |
|
| dloneranger |
| Posted: Feb 10 2013, 01:13 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
The downside to that is that if you
convert to 444
shift the chroma one pixel
convert to 420
You'll end up blurring the origional chromas double sized pixels together
eg
origional blue, red, yellow
converted blue, blue, red, red, yellow, yellow
shifted blue, red, red, yellow, yellow
converted average of blue/red, average of red/yellow, etc
This may be unnoticable on skin etc or horrible on lines/edges of things
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| jpsdr |
| Posted: Feb 11 2013, 11:36 AM |
|
|
Advanced Member
Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06
|
| QUOTE (Gubel @ Feb 10 2013, 12:45 PM) | | But what does the tool do, when moving Cr 3 pixels to the left, and Cb 2 pixels to the right for example? |
As i've said, in that case, it works on chroma, and use the highest valid value. If you are in 4:2:x mode, it will shift Cr of 4 pixel to the left, and Cb of 2 pixel to the right, and if you are in 4:1:x mode, it will shift Cr of 4 pixel to the left and Cb of 4 pixels to the right.
But your idea of reducing Y shift is interesting, for a global shit of 5 pixel to the right, in 4:2:x, it can be done by shifting chroma of 4 pixel to the right, and Y of only 1 to the left. Haven't thought about it.
I had no plan to update my filter, but with this new idea i will. But... i don't know when... I may have a chance quick, but not sure.
Going all to 4:4:4 is not something i intend to, and it's the opposite! I designed the filter to handle subsampled format for not having to upscale.
EDIT :
@Gubel : Stay tuned, i may have an update with Up/Down quicker than expected...  |
|
| jpsdr |
| Posted: Feb 11 2013, 07:03 PM |
|
|
Advanced Member
Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06
|
New version with shift on Y minimized and vertical shift added.
Take here : http://jpsdr.free.fr/XBMC/Filtres_JPSDR.rar
Notify me when retrieve. |
|
| Gubel |
| Posted: Feb 21 2013, 01:58 AM |
|
|
Member
Group: Members
Posts: 14
Member No.: 35995
Joined: 22-January 13
|
Hey!
I only wanna say "I'm still alive" at this point...Thank you for your reply - I'll check that tomorrow. Then I will be here in this thread again...!
Regards...Alex |
|
| Gubel |
| Posted: Feb 24 2013, 10:44 PM |
|
|
Member
Group: Members
Posts: 14
Member No.: 35995
Joined: 22-January 13
|
Hello back jpsdr!
Wow, I think you made it! That's exactly how I thought it should work! Bravo! And Thank you very much!
I checked all possible vaules of odd and even numbers of pixles...
Now I only have another very simple proposal to make it easier to adjust the right values and taking the filter to perfection:
Could you exchange the "Edits" for the shifting-values with "sliders" and "labels" showing the selected value? I think a range of +-15 pixels would be enough in most cases. Then we would have 4 sliders for horizontal/vertical shift of Cr/Cb. A "label" above them would show the amount of pixels.
You could even add a "checkbox" to "lock" the two Cr-/Cb-sliders :-)
I'm thinking of such a user-interface (I've just "designed" a bit with Borland Delphi ;-) ):
Best regards!
Alex |
|
| jpsdr |
| Posted: Feb 25 2013, 08:06 AM |
|
|
Advanced Member
Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06
|
Glad you like it and seems to work fine.
I'll not change the interface for several reasons.
First, my specific knowledge in specific Windows/GUI programing is near zero. So, i don't know how to make sliders... 
Also, i don't want to make silders, because they have limitations, and, except for specific cases, i don't like limitations. And on the other way, if you give sliders too much range, you loose accuracy. Basicaly, i don't like sliders, with edit, at least, you can precisely put what you want, and don't hit issues like "I want to put +20 but slider allows me only +15 max", or "I want to put +7 but slider go directly from +6 to +8"...
So, for me, GUI is "perfect" as it is.
But you make me think that maybe i've not checked for "stupid" shift value higher than image size. |
|
|
