madVR - high quality video renderer (GPU assisted)

[aufkrawall]

Could someone please explain to me again what the reason was why NNEDI3 via DirectCompute was much slower than OpenCL?

[madshi]

We need to configure profiles for each types of videos, so that's taken into account there.
So you want to simplify the SuperRes options, and in the same step require users to use profiles (to achieve a comparable sharpness for all scaling factors)? Sorry, but this would be a step in the wrong direction, if our goal is to achieve a simple and easy to understand madVR configuration at some point in the future. I don't want SuperRes to produce different levels of sharpness, depending on which scaling factor you're using. That would be confusing and difficult to setup for users.

Could someone please explain to me again what the reason was why NNEDI3 via DirectCompute was much slower than OpenCL?
I don't know, maybe the DirectCompute compiler didn't optimize the code as well as the OpenCL compiler did? Or maybe I was too stupid to write well optimized DirectCompute code? I tried to directly convert the OpenCL kernel to DirectCompute, and while it produced correct image output, it was very slow. Could very well have been my fault, for all I know.

[Siso]

An odd thing madvr causing big dpc latencies, I've tested with evr-cp - no latency problems

madvr https://www.imageupload.co.uk/images/2015/06/11/madvr79f32.th.png (https://www.imageupload.co.uk/image/ZWjL)


evr-cp https://www.imageupload.co.uk/images/2015/06/11/evr-cp.th.png (https://www.imageupload.co.uk/image/ZWjV)

[iSunrise]

madshi, I found a bug with 0.88.11 that should be pretty easy to fix.

1) Go to image doubling
2) Enable double luma and chroma resolution
3) Use a scaling factor of at least 2.0x in your media player
4) Now, if you enable quadruple luma, the picture suddenly has a green tint over it. It goes away again if you either disable quadruple luma or if you additionally enable quadruple chroma.
5) As an additional note, it only happens when you have enabled "always - if upscaling is needed" on quadrupling, if you enable "only if scaling factor is XX" this does not happen. Seems like a corner case related to that "always ..." option that isn't handled correctly.

I accidentally found that out, since I enabled SuperRes after image doubling and then the green tint also goes away, irregardless of the doubling settings.

[omarank]

Feedback

Questions:

1) Do you prefer linear light on or off?
2) In my own very short tests I found that FineSharp sometimes introduces aliasing artifacts. These seem to be mostly fixed by setting the "repair" option to rather high values. Personally, I've tried setting "repair" to 1.0, and liked the result. But what is your opinion about this? Do you find "repair" at 1.0 works for you? Or would you prefer it at a lower value?
3) Do you see a difference worth noting between the 3 different modes? Please note that these modes will make more of a difference if the sources have stronger grain. So in order to judge which modes work best and which worst, it might make sense to also test with a source with a lot of grain in it. FWIW, mode 3 is slower, modes 1 and 2 are faster. So if you like mode 3 best, but not much better than 1 and 2, then it would still be useful to know whether you prefer 1 over 2 or the other way round.
4) Which combinations of strength and thinning would you suggest for low/medium/high presets?

Thanks! :)
1. On
2. Yes “repair” at 1.0 looks good. I didn’t see it doing any harm to the images
3. I like mode 3 much better than mode 1 and 2. Between mode 1 and mode 2, I can’t decide which one is better
4. The “thinning” parameter makes so slight changes that are hard to make out. While I was playing with this parameter, I settled on 0.0032. Below are my preferences for the presets:
Low preset: “strength” 1.5, Medium preset: “strength” 2.0, High preset: “strength” 2.3

Whether FineSharp is selected in image enhancements or upscaling refinements, my preferences are the same.

[Neeto]

An odd thing madvr causing big dpc latencies, I've tested with evr-cp - no latency problems

madvr https://www.imageupload.co.uk/images/2015/06/11/madvr79f32.th.png (https://www.imageupload.co.uk/image/ZWjL)


evr-cp https://www.imageupload.co.uk/images/2015/06/11/evr-cp.th.png (https://www.imageupload.co.uk/image/ZWjV)

Have found that it's different on different motherboards.
Also BIOS update can make it better or worse.... SIGH

[Siso]

Have found that it's different on different motherboards.
Also BIOS update can make it better or worse.... SIGH

The bios update cut my latency in half, so I guess it helped, but the madvr is acting weird in that matter of latency...

[6233638]

Use LatencyMon (http://www.resplendence.com/latencymon) to get a better idea of what's causing it.

[Siso]

Use LatencyMon (http://www.resplendence.com/latencymon) to get a better idea of what's causing it.

This is my result with highest dpc latency while playing a mkv with madvr https://www.imageupload.co.uk/images/2015/06/12/Capture.md.png (https://www.imageupload.co.uk/image/ZWUu)

[Braum]

Will it be possible, in the future, to share Madvr processing load between gpu and cpu ?

I got a 7870XT and a i5 3570K@4.5ghz and quickly reach the limits of my gpu, it's a bit frustrating to see my cpu doing practically nothing.

[nevcairiel]

CPUs are extremely bad at image processing, it wouldn't be that much of a help. If you wanted to, you could pre-scale the image on the CPU using ffdshow/AviSynth or something, instead of letting madVR do it, but personally I don't think its really worth it.

[Braum]

CPUs are extremely bad at image processing, it wouldn't be that much of a help. If you wanted to, you could pre-scale the image on the CPU using ffdshow/AviSynth or something, instead of letting madVR do it, but personally I don't think its really worth it.

Okay, thank you for this explanation :) I'll stick with Madvr.

[MysteryX]

Will it be possible, in the future, to share Madvr processing load between gpu and cpu ?

I got a 7870XT and a i5 3570K@4.5ghz and quickly reach the limits of my gpu, it's a bit frustrating to see my cpu doing practically nothing.
CPU won't do much for this kind of work, but you can combine with SVP which works mostly on the CPU to increase frame rate to 60fps. SVP then runs on the CPU while madVR runs on the GPU. SVP can also downscale the image to your monitor's resolution.

[godshades]

hi, im new here. Can any1 use vga GT 650m with GDDR3 (Asus N56VZ) tell me what best setting for madvr :D ?
Or how can i find the best setting, just try each setting and check render time ? :D

[ladersu]

madshi, if a settings.bin is corrupt, madVR is not able to read any settings from it? What can be done to restore?

[huhn]

hi, im new here. Can any1 use vga GT 650m with GDDR3 (Asus N56VZ) tell me what best setting for madvr :D ?
Or how can i find the best setting, just try each setting and check render time ? :D

choice what looks best to your eyes.

[AngelGraves13]

Will it be possible to one day get noise reduction in madvr? Mostly the luminance noise is what I'm referring to.

[blindbox]

Basically, it would require MadVR to deliver frames when they are needed to be displayed. This works for games (frame rendered then displayed instantly), but MadVR has a timing for the frame. However, MadVR cannot guarantee to send the frame when this time comes (No CPU time, and/or simply not precise enough timers).

This is why we have queues in FSE (apart from more stability), to let the GPU handle the presenting times of frames by using a HW circuit.

TL;DR: You need to present frames exactly when they need to be presented, with no queue. Current systems can't do this.

What about the fact that FreeSync and G-Sync purely relies on the frames that are about to appear on the display? The only knowledge that G-Sync and FreeSync has is that of the cables saying 'hey guys I'm sending you another frame!' (some may say FreeSync isn't doing this, but I'm pretty sure it does, given that DX's framerate reporting isn't entirely accurate).

I still don't understand why any under-the-hood timing is relevant when all F/G-Sync care about is what's coming out of the cable port currently.

[webs0r]

What about the fact that FreeSync and G-Sync purely relies on the frames that are about to appear on the display? The only knowledge that G-Sync and FreeSync has is that of the cables saying 'hey guys I'm sending you another frame!' (some may say FreeSync isn't doing this, but I'm pretty sure it does, given that DX's framerate reporting isn't entirely accurate).

I still don't understand why any under-the-hood timing is relevant when all F/G-Sync care about is what's coming out of the cable port currently.

Look at your madVR render time.
Let's say its hovering around 10ms per frame, and madVR just sent it "down the cable" with no timing mechanism. Your video will play back at 100 frames per second.
This won't be good for a movie shot at 24fps. Would play 4x too fast.

Gsync would work well in that, well, the monitor would show a clean frame for those 100 frames in that second, no matter on tiny madVR variations... e.g. one of the frames might go out at 11ms, the other at 9ms.

But the movie would be playing back like a Benny Hill intro. Not to mention you will have random judder from the timing jitter.

Something has to match the presentation to exactly 24fps. A precise mechanism needs to be in place for that. Gsync does not provide for, or help, that mechanism.

Watching video is not a game - you don't want to just push out frames as soon as they are ready.

[agustin9]

An odd thing madvr causing big dpc latencies, I've tested with evr-cp - no latency problems

madvr https://www.imageupload.co.uk/images/2015/06/11/madvr79f32.th.png (https://www.imageupload.co.uk/image/ZWjL)


evr-cp https://www.imageupload.co.uk/images/2015/06/11/evr-cp.th.png (https://www.imageupload.co.uk/image/ZWjV)

Which gpu do you have?

[Siso]

Which gpu do you have?

GTX 550 Ti

[blindbox]

Look at your madVR render time.
Let's say its hovering around 10ms per frame, and madVR just sent it "down the cable" with no timing mechanism. Your video will play back at 100 frames per second.
This won't be good for a movie shot at 24fps. Would play 4x too fast.

No, what I'm asking is that you send frames from madvr at 48 fps with frame doubling for a 24fps video and let G/F-Sync handle the rest. I never asked for madvr to send as much frames as possible.



Gsync would work well in that, well, the monitor would show a clean frame for those 100 frames in that second, no matter on tiny madVR variations... e.g. one of the frames might go out at 11ms, the other at 9ms.

This is not how G-Sync works. G/F-Sync works by measuring the time the client's frames reaches the end of the GPU pipeline, and then change the monitor refresh rate to make sure it looks fluid. Of course, this is an oversimplification. There's obviously some buffer and timing wizardry involved. But changing the monitor refresh rate on the fly is essential to this tech.


But the movie would be playing back like a Benny Hill intro. Not to mention you will have random judder from the timing jitter.

Like I said, G/F-Sync will handle that. All you have to do is give 48 fps to the graphics card. Or rather, make sure it's 48 fps at the end of the pipeline.

Something has to match the presentation to exactly 24fps. A precise mechanism needs to be in place for that. Gsync does not provide for, or help, that mechanism.

Okay, let madVR make sure the presentation is exactly 24 fps. However, when it comes to the refresh rate of the monitor, let MadVr assume the refresh rate is 48 Hz, and let G/F-Sync handle the rest of the anti-tearing. And they do this by changing the refresh rate of the video to 48 Hz or any arbitrary Hz that it supports.

Watching video is not a game - you don't want to just push out frames as soon as they are ready.

Yeah, okay. How about we push 48 fps (interestingly, in a lot of engines out there, you can limit the engine fps) into the GPU, and let the G/F-Sync handle the rest? We don't have to make it act like a game.



My answers in green above

From what I understood on how G/F-SYNC work, this is how it goes in chronological order, if MadVr is to implement G/F-Sync without making any changes.

1) MadVr checks the display's refresh rate. If it's not a nice multiple of the video fps, it will shift around the frametime of frames (aka pulldown effect).
2) MadVR sends a frame in its buffer. MadVR has a precision timer, so it sends this frame at 60 fps with very small variation.
3) G/F-Sync detects the time taken for the frame to finally reach the end of the GPU pipeline and put it in their buffer with a timestamp
4) G/F-Sync introduces a tiny delay and tells the monitor to change its refresh rate ASAP (there's perhaps a tiny overdriving circuit that forces the display to refresh immediately.. oh hey, it's called the VBLANK) and G/F-Sync does this by looking at the frame history i.e. at how fast it was put into the frame buffer before it was sent to the display. Anything that requires overcompensation, VBLANK it.
5) G/F-Sync finishes its job.

So all I'm asking here is that we remove that display's refresh rate check which effectively disables pulldown, and send the video down the GPU pipeline at 48 fps by simply doubling each frame, and let G/F-Sync handle the rest. And they do that by changing the refresh rate of the video on the fly.

Now let's see how it goes for games.

1)Games sends out as many frames as it wants no matter what
2) G/F-Sync detects the time taken for the frame to finally reach the end of the GPU pipeline and put it in their buffer with a timestamp
3) G/F-Sync said 'okay, this frame can go, that frame can go into my buffer... or maybe I'll drop it'
4) G/F-Sync detects wild variations in frame rate, and goes 'oh crap, change the refresh rate QUICK QUICK QUICK)... and G/F-Sync does this by looking at the frame history i.e. at how fast it was put into the frame buffer before it was sent to the display. If it requires overcompensation, VBLANK it.
5) G/F-Sync finishes its job.

Did I get this right? I don't think madVR is able to bypass the driver layer like DX12/Mantle can. Even then, DX12/mantle is still an abstraction and AMD/Nvidia can still put G/F-Sync at the end of the chain. They still have to go into the driver stack and into the driver's personal queue. Since madVR is unable to bypass this, G/F-Sync can still work.

If it works for games, and especially when the variation is very intensive in games, why wouldn't it work for videos? FPS too low? Right now MadVR works by V-SYNCing to the display. Hence you see some frames doing 12 ms, and some frames doing 9 ms to avoid tearing. Disable that v-sync, send that video at 48 FPS by frame duplication, give not a single crap about tearing, let F/G-Sync handle the rest.

I think the main take away is that, G/F-Sync allows variable refresh rate. What does that mean? You make sure the GPU outputs 48 FPS, G/F-Sync will then set the display to be at 48 Hz. Why do I keep mentioning 48 FPS? It's double the magic video fps of 24 fps, meaning that you can just double the frames.

Now tell me why wouldn't simply shoving a doubled 24 fps video at 48 fps and then letting G/F-Sync auto-set the display to 48 Hz work?

Pardon my tone. Also, this is why I wanted a more serious discussion on G/F-Sync in this thread. All the posts before this hasn't been as detailed as to what I posted. Even this one is perhaps not detailed enough. I didn't go into the greater details on why there's no tearing but the keywords are VBLANK and variable refresh rate. Variable refresh rate allows the monitor's refresh rate to be set to anything between 40~60 fps (IPS monitors are supporting FreeSync now!). VBLANK for forcing a refresh to compensate for any sudden changes.

I realize that there's a ton in this text of me simply screaming variable refresh rate and VBLANK in a hundred different ways. That's on purpose. I'm trying to get the idea across that all you have to do with G/F-Sync, is assume that monitor is a 48 Hz monitor, convert the video from 24 fps to 48 fps by duplicating the frames, and then G/F-Sync will change the monitor refresh rate to 48 Hz to suit your video. I may have also been contradictory on some parts. If you would please point that out, I'll be glad. I'm kinda bad at presenting my ideas.

[nevcairiel]

madshi has explicitly asked (http://forum.doom9.org/showthread.php?p=1719903#post1719903) for discussions around G-Sync/FreeSync to not be happening in this thread anymore at this time, so I suggest you respect his wishes, and if you want to continue discussing it, open your own thread.
All the technical points of why its more complicated than you seem to believe have already been discussed to death, so i suggest you actually read them, too.

[madshi]

An odd thing madvr causing big dpc latencies, I've tested with evr-cp - no latency problems
I remember that problems with DPC latencies have been discussed in this thread a long time ago. I don't remember the details, anymore. Maybe you can do a search to find the old posts? In any case, madVR does not directly talk to any drivers, or do any funny stuff, so I'm not sure how madVR itself could cause DPC latencies. So I also wouldn't know how to do anything about it.

What happens if you play a GPU heavy game? Does that also up the DPC latencies in a similar way?

madshi, I found a bug with 0.88.11 that should be pretty easy to fix.

1) Go to image doubling
2) Enable double luma and chroma resolution
3) Use a scaling factor of at least 2.0x in your media player
4) Now, if you enable quadruple luma, the picture suddenly has a green tint over it. It goes away again if you either disable quadruple luma or if you additionally enable quadruple chroma.
I can't reproduce it, unfortunately. Can you please start with madVR default settings, then try if you can still reproduce it with those? If you can, please create an issue on the bug tracker, with a download link to your madVR settings, and a full list of your hardware, OS and a screenshot with the Ctrl+J OSD on.

1. On
2. Yes “repair” at 1.0 looks good. I didn’t see it doing any harm to the images
3. I like mode 3 much better than mode 1 and 2. Between mode 1 and mode 2, I can’t decide which one is better
4. The “thinning” parameter makes so slight changes that are hard to make out. While I was playing with this parameter, I settled on 0.0032. Below are my preferences for the presets:
Low preset: “strength” 1.5, Medium preset: “strength” 2.0, High preset: “strength” 2.3

Whether FineSharp is selected in image enhancements or upscaling refinements, my preferences are the same.
This is exactly the kind of feedback I'm looking for - thanks! :)

One question: With debanding there were often some thresholds where increasing one parameter by 0.1 didn't do much, but increasing 0.2 suddenly brought a big change. I think this is not the case with FineSharp, correct? A small change in the FineSharp parameters causes a small change in image quality, right? I suppose if I decided to use 1.4/2.0/2.4 that wouldn't bother you much? Or is there something "magic" about your choices of 1.5/2.0/2.3? Not that I'm planning to use 1.4/2.0/2.4, just asking how "fixed" your suggestions are.

hi, im new here. Can any1 use vga GT 650m with GDDR3 (Asus N56VZ) tell me what best setting for madvr :D ?
Or how can i find the best setting, just try each setting and check render time ? :D
Start with default settings. If it runs smoothly, try different algorithm to see if you like them better or not. Luma/image is more important than chroma. Jinc is nice, if your GPU can handle it. Try smooth motion FRC, if your display can't do 24Hz properly.

madshi, if a settings.bin is corrupt, madVR is not able to read any settings from it? What can be done to restore?
Try deleting the file, then madVR should read the settings from registry instead. If the settings in the registry are *also* corrupt, your only choice is to restore to default settings.

Will it be possible to one day get noise reduction in madvr? Mostly the luminance noise is what I'm referring to.
One day? Probably.

-------

Based on FineSharp feedback so far I've decided to always enable "linear light", use "mode 3" and set "repair" to the max value of 1.0 (unless several users come with objections). I'd still like to get more feedback from more users on the "strength" and "thinning" options. Which combination of those settings would you guys suggest for "low", "medium" and "high" presets?

Thanks!

[blindbox]

madshi has explicitly asked (http://forum.doom9.org/showthread.php?p=1719903#post1719903) for discussions around G-Sync/FreeSync to not be happening in this thread anymore at this time, so I suggest you respect his wishes, and if you want to continue discussing it, open your own thread.
All the technical points of why its more complicated than you seem to believe have already been discussed to death, so i suggest you actually read them, too.

I hope you can point out those discussions, as I've read all of them and I couldn't find one that properly answers this query.

I understand. If the reason why he's not doing it is because it's DisplayPort only (FreeSync is coming to HDMI, btw), then I won't pursue this further.

I first thought the reason why F/G-Sync is not considered is because of the lack of understanding of the methodology of both technologies (that is, by changing the refresh rate of the display on the fly, and making sure it matches the frametimes by some wizardy).

It's just that I thought having the capability of setting my refresh rate to whatever I want with whatever fps the video is playing at, is a match made in heaven.

Again, I have said, I have read every post on F/G-Sync on this thread. None of it answers my query. I took away an edit of mine when I said Asmodian tested G-Sync and it didn't work as expected because madVR is detecting the wrong Hz (at first I understood it as 48 Hz G-Sync as different compared to a 48 Hz monitor). Then he also said something similar to what I said - the fact that madVr tries to adjust the frametime of each frame based on the current refresh rate is screwing G-Sync up. What if madVr simply assumes that the monitor's Hz is 48? Asmodian asked the same thing but never got his reply.


It seems like it would work well if madVR simply assumed the refresh rate was whatever frame rate it wanted to render at but I really have no idea.




That's all from me. Not supporting it because it only supports Displayport and a small subset of monitors is a valid reason. I hope that's the reason, instead of a misunderstanding of the underlying tech.

[e-t172]

2) MadVR sends a frame in its buffer. MadVR has a precision timer, so it sends this frame at 60 fps with very small variation.

No, madVR doesn't have a "precision timer" (or at least not precise enough), and that's why your solution is not viable. Please re-read previous posts, especially my response to STaRGaZeR (http://forum.doom9.org/showthread.php?p=1719909#post1719909) who had the same misunderstanding.

Also, you seem to be assuming that G-Sync/FreeSync works by the GPU gauging the frame rate over some period of time and switching the screen to a matching refresh rate. That's not how it works: when using these technologies there is no such thing as a "refresh rate" anymore, frames are simply sent to the screen at unspecified times whenever the system feels like it.

To reiterate my previous explanation: when using a fixed refresh rate, the refresh rate clock is a hardware clock. madVR simply makes sure the GPU has a pipeline of frames to display (through "present frames in advance" mechanisms), and the hardware clock on the GPU makes sure these frames are sent to the display with a precise, regular cadence according to the fixed refresh rate. When using variable refresh rate, there is no hardware clock anymore, the frames can't be presented in advance and have to be timed in software. This is very difficult to do in an accurate manner because Windows is not a real-time OS and therefore doesn't guarantee the madVR presentation thread will run at the exact time required to accurately present the next frame. Therefore, such a solution would probably have too much presentation (= refresh rate) jitter to be viable for high-quality video playback.

it only supports Displayport

Actually, that's not true anymore (http://www.anandtech.com/show/9337/amd-shows-freesyncoverhdmi-concept-at-computex-2015).

[Siso]

I remember that problems with DPC latencies have been discussed in this thread a long time ago. I don't remember the details, anymore. Maybe you can do a search to find the old posts? In any case, madVR does not directly talk to any drivers, or do any funny stuff, so I'm not sure how madVR itself could cause DPC latencies. So I also wouldn't know how to do anything about it.

What happens if you play a GPU heavy game? Does that also up the DPC latencies in a similar way?

It appears that using lav cuvid makes the spikes go very high, tested with cpu decoding and dxva2 cp, with dxva cp is a little better, will try to experiment with the flush options but I do not know if that will help...I don't play games, so I cannot test with games.

[mortencombat]

Let me first thank you for the utterly awesome tool that is madVR. I've been considering a Lumagen Radiance VP but as far as I can tell, the "only" things that a (very expensive, and currently only 2K in) Radiance would bring that madVR does not - for my use cases - is HDMI switching (obviously) and aspect ratio/crop/zoom/vertical shift for CIH/CIW setups.

Are there any plans to add aspect ratio/crop/zoom/vertical shift to madVR? I realize that some players already offer some combination of these, but rarely all.

I would be all over developing a companion application which would store various profiles (combinations of aspect ratio/crop/zoom/shift) for madVR and expose these over a REST API for IP based remote control (Roomie Remote, iRule, etc.).

[madshi]

Let me first thank you for the utterly awesome tool that is madVR. I've been considering a Lumagen Radiance VP but as far as I can tell, the "only" things that a (very expensive, and currently only 2K in) Radiance would bring that madVR does not - for my use cases - is HDMI switching (obviously) and aspect ratio/crop/zoom/vertical shift for CIH/CIW setups.

Are there any plans to add aspect ratio/crop/zoom/vertical shift to madVR? I realize that some players already offer some combination of these, but rarely all.

I would be all over developing a companion application which would store various profiles (combinations of aspect ratio/crop/zoom/shift) for madVR and expose these over a REST API for IP based remote control (Roomie Remote, iRule, etc.).
I'm a CIH user myself, so you can rest assured that AR/crop/zoom/shift/masking etc are high on my personal to do list. However, what I personally wish for sometimes has to wait for what the majority of madVR users would benefit from...

[nevcairiel]

However, what I personally wish for sometimes has to wait for what the majority of madVR users would benefit from...

Sounds like you're doing it wrong. :)

[madshi]

Sounds like you're doing it wrong. :)
Haha! You may be right there.

[agustin9]

GTX 550 Ti

I had this problem with an AMD 4850, and lowering the gpu queues fixed it...

[iSunrise]

Based on FineSharp feedback so far I've decided to always enable "linear light", use "mode 3" and set "repair" to the max value of 1.0 (unless several users come with objections). I'd still like to get more feedback from more users on the "strength" and "thinning" options. Which combination of those settings would you guys suggest for "low", "medium" and "high" presets?

Thanks!
While I really like FineSharp (since it's very natural looking, easily my favourite sharpener) and most of the FineSharp settings you settled on, linear light produces artefacts and doesn't look natural at all. Without linear light it's fine. See the following screenshots that show the artefacts very clearly. This happens with other samples as well. I marked them so you can compare original -> no LL (very natural) and original -> LL (unnatural and with artefacts). Also please compare no LL -> LL, because you will instantly see that the LL image is artefacting all over the place.

Original
http://abload.de/thumb/sample1_finesharp_3_198oop.png (http://abload.de/image.php?img=sample1_finesharp_3_198oop.png)

FineSharp no LL (with your settings)
http://abload.de/thumb/sample1_finesharp_3_1mept8.png (http://abload.de/image.php?img=sample1_finesharp_3_1mept8.png)

FineSharp with LL (with your settings)
http://abload.de/thumb/sample1_finesharp_3_1jkoon.png (http://abload.de/image.php?img=sample1_finesharp_3_1jkoon.png)

For comparisons to really make sense, people need to also do screenshots and show them here. For some reason, the newly introduced features very rarely if at all are really looked at in detail with screenshots. I really would have loved to read some feedback on FineSharp from 6233638 and cyberbeing, too.

As for your questions regarding "low", "medium" and "high", I found that strength "0.2", "0.5" and "1.0" are giving the perfect mix. 0.2 is very mild sharpening (transparent enough to be completely natural), 0.5 is medium sharping (still very natural) and 1.0 is very visible sharpening, where you really need the extra "oomph" for bringing out details (but you can tell it's been sharpened). If you go any higher, you get very visible artefacts up to the point where it gets quite distracting (2.0 already rings like crazy, 1.5 is also not satisfactory).

The thinning parameter is a bit difficult to be honest, I settled on "0.020" for all strengths, because higher values than that give artefacts. You can easily tell when you test with "0.100", which looks horrible. So be careful with that setting.

..I can't reproduce it, unfortunately. Can you please start with madVR default settings, then try if you can still reproduce it with those? If you can, please create an issue on the bug tracker, with a download link to your madVR settings, and a full list of your hardware, OS and a screenshot with the Ctrl+J OSD on.
For some reason you left out 5) when you quoted me, you absolutely need this to reproduce it.

5) As an additional note, it only happens when you have enabled "always - if upscaling is needed" on quadrupling, if you enable "only if scaling factor is XX" this does not happen. Seems like a corner case related to that "always ..." option that isn't handled correctly.

If you really cannot reproduce it, which I doubt, since I am using default settings, I will add it to the bug tracker.

[ikarad]

It seems that directx 11 is more demanding than directx 9 path. With madvr 0.88.11 or 0.88.8 and this video https://www.youtube.com/watch?v=sLprVF6d7Ug (I have downloaded 8k movie), I have lotsd of presentation glitch with dx11 patch and not with dx9 path

1) dx9 + deband filter + chroma upscaling (bicubic 100) + image downscaling (CR/AAR/SLL) : no presentation glitch
dx11 + deband filter + chroma upscaling (bicubic 100) + image downscaling (CR/AAR/SLL) : lots of presentation glitch

2) dx9 + no deband filter + chroma upscaling (bicubic 100) + image downscaling (CR/AAR/SLL) : no presentation glitch
dx11 + no deband filter + chroma upscaling (bicubic 100) + image downscaling (CR/AAR/SLL) : no presentation glitch


3) dx9 + no deband filter + chroma upscaling (jinc) + image downscaling (CR/AAR/SLL) : no presentation glitch
dx11 + no deband filter + chroma upscaling (jinc) + image downscaling (CR/AAR/SLL) : no presentation glitch

4) dx9 + no deband filter + chroma upscaling (jinc AR) + image downscaling (CR/AAR/SLL) : no presentation glitch
dx11 + no deband filter + chroma upscaling (jinc AR) + image downscaling (CR/AAR/SLL) : lots of presentation glitch


With my 1080p videos, there aren't presentation glitchs with dx11 patch.

[Bulldogger]

:goodpost::goodpost:Let me first thank you for the utterly awesome tool that is madVR. I've been considering a Lumagen Radiance VP but as far as I can tell, the "only" things that a (very expensive, and currently only 2K in) Radiance would bring that madVR does not - for my use cases - is HDMI switching (obviously) and aspect ratio/crop/zoom/vertical shift for CIH/CIW setups.

Are there any plans to add aspect ratio/crop/zoom/vertical shift to madVR? I realize that some players already offer some combination of these, but rarely all.

I would be all over developing a companion application which would store various profiles (combinations of aspect ratio/crop/zoom/shift) for madVR and expose these over a REST API for IP based remote control (Roomie Remote, iRule, etc.).+1

[TheLion]

While I really like FineSharp (since it's very natural looking, easily my favourite sharpener) and most of the FineSharp settings you settled on, linear light produces artefacts and doesn't look natural at all. Without linear light it's fine. See the following screenshots that show the artefacts very clearly. This happens with other samples as well. I marked them so you can compare original -> no LL (very natural) and original -> LL (unnatural and with artefacts). Also please compare no LL -> LL, because you will instantly see that the LL image is artefacting all over the place.

Original
http://abload.de/thumb/sample1_finesharp_3_198oop.png (http://abload.de/image.php?img=sample1_finesharp_3_198oop.png)

FineSharp no LL (with your settings)
http://abload.de/thumb/sample1_finesharp_3_1mept8.png (http://abload.de/image.php?img=sample1_finesharp_3_1mept8.png)

FineSharp with LL (with your settings)
http://abload.de/thumb/sample1_finesharp_3_1jkoon.png (http://abload.de/image.php?img=sample1_finesharp_3_1jkoon.png)

For comparisons to really make sense, people need to also do screenshots and show them here. For some reason, the newly introduced features very rarely if at all are really looked at in detail with screenshots. I really would have loved to read some feedback on FineSharp from 6233638 and cyberbeing, too.

As for your questions regarding "low", "medium" and "high", I found that strength "0.2", "0.5" and "1.0" are giving the perfect mix. 0.2 is very mild sharpening (transparent enough to be completely natural), 0.5 is medium sharping (still very natural) and 1.0 is very visible sharpening, where you really need the extra "oomph" for bringing out details (but you can tell it's been sharpened). If you go any higher, you get very visible artefacts up to the point where it gets quite distracting (2.0 already rings like crazy, 1.5 is also not satisfactory).

The thinning parameter is a bit difficult to be honest, I settled on "0.020" for all strengths, because higher values than that give artefacts. You can easily tell when you test with "0.100", which looks horrible. So be careful with that setting.


For some reason you left out 5) when you quoted me, you absolutely need this to reproduce it.

5) As an additional note, it only happens when you have enabled "always - if upscaling is needed" on quadrupling, if you enable "only if scaling factor is XX" this does not happen. Seems like a corner case related to that "always ..." option that isn't handled correctly.

If you really cannot reproduce it, which I doubt, since I am using default settings, I will add it to the bug tracker.

Interesting. I have found the exact opposite to be the case, regarding LL. Please take a look at the video sample/test chart I have attached a few pages ago. With "quite high strength" of 2.0 this test chart looks horrible without LL (EE/ringing destroys it), with LL at this strength it is perfectly fine, EE/ringing is rather OK even if this sample is specifically designed to show problems.

I guess your preference for "quite low" strength settings may be a result of your no LL preference (regarding EE/ringing). Or maybe you use it in another context (not as Image Enhancement for HQ content (e.g. high bitrate BluRay). Or type of display...so many variables

Changes in parameters with FineSharp work gradually from what I can see - no big jumps.

I agree with you that thinning of 0.02 is a good sweetspot for all practical strengths. I don't agree about the suggested 0.2/0.5/1.0 strengths.

In my opinion FineSharp starts "to matter" at something like 1.0 (why bother with additional processing/artificial sharpening when the effect is hardly perceivable as is the case with 0.2 strength?)

The upper limit = High Setting should be between 2.0 and 2.4 in my opinion. With LL I have found this range to give very good results with very good source material (very little artifacting/EE/ringing to begin with, sources with inherent ringing/artifacting will look horrible with this high setting though).
2.2 seems like a good compromise - right in the middle.

[Barnahadnagy]

Finesharp: It is quite interesting IMO. It produces a completely different look than LumaSharpen, and I think its up to personal preference. As for me, I like finesharp for doing a bit of a touchup. LSharpen has better effect for more sharpening, if I want that.
Repair at 1 looks great, found no problems. Thinning: lower than 0.025, thats sure, I like it most between 0.018 and 0.02. As for strength: 2.2 seems to be good for high preset for me too. For mid I would go with 1.4, and 0.9-1.1 for low.

I didnt test LL much, but I do prefer it on with anime.

[Anime Viewer]

While I really like FineSharp (since it's very natural looking, easily my favourite sharpener) and most of the FineSharp settings you settled on, linear light produces artefacts and doesn't look natural at all. Without linear light it's fine. See the following screenshots that show the artefacts very clearly. This happens with other samples as well. I marked them so you can compare original -> no LL (very natural) and original -> LL (unnatural and with artefacts). Also please compare no LL -> LL, because you will instantly see that the LL image is artefacting all over the place.


I haven't noticed any artifacts in the sample videos I've looked at (I pause the videos and look at still frames while switching the features on and off to check for differences except for when I want to factor in how render times/present times are effected by the changes).
What gpu (Nvidia, AMD, Intel) are you using?
Do you have any hardware acceleration set in LAV, or are using the none setting in the LAV video decoder settings?
What are you using for your upscaler and downscalers?
What is the resolution of the video you are viewing (I see your settings are using a rule for 576p video)?
Do you get the same results for Linear Light in FineSharp image enhancement and upscaling refinement, or only only one of the two? Extending on that do you have the same problem is you enable liner light for other things (like in the image upscaling or downscaling areas)?

Interesting. I have found the exact opposite to be the case, regarding LL. Please take a look at the video sample/test chart I have attached a few pages ago. With "quite high strength" of 2.0 this test chart looks horrible without LL (EE/ringing destroys it), with LL at this strength it is perfectly fine, EE/ringing is rather OK even if this sample is specifically designed to show problems.


To compare and factor vs iSunrise's settings what gpu are you using? Do you have any hardware acceleration set in LAV? What scalers are you using for up and down scaling?

[iSunrise]

Interesting. I have found the exact opposite to be the case, regarding LL. Please take a look at the video sample/test chart I have attached a few pages ago. With "quite high strength" of 2.0 this test chart looks horrible without LL (EE/ringing destroys it), with LL at this strength it is perfectly fine, EE/ringing is rather OK even if this sample is specifically designed to show problems.
Actually, you found exactly the same as I did, however, it seems that you misinterpreted the results of your sample or at the very least, you came up with a different conclusion, because you probably didn't also zoom into the video and inspected more closely why the diagonal lines behave the way they do when they are sharpened. Also, I have found exactly the same image artefacts that I got in my samples in yours, which I showed in my last post (the weird blackness that consumes the image (borders) and seems to completely destroy image details that were there before).

The following is a screenshot of your original sample to demonstrate. I zoomed in so I can better explain the differences.

Original image:
http://abload.de/thumb/sample_thelion_finesh9xq2q.png (http://abload.de/image.php?img=sample_thelion_finesh9xq2q.png)

Now, this is with finesharp active, strength 2.0, no LL:
http://abload.de/thumb/sample_thelion_fineshplp4i.png (http://abload.de/image.php?img=sample_thelion_fineshplp4i.png)

The strength of "2.0" already does so much sharpening to the image that it shows you exactly what you would expect. It amplifies the picture details and thus, it will also show you compression artefacts a lot stronger than before. The diagonal lines now have a white glow around them, which is because there were already quite strong visible compression artefacts that you can see when you zoom into the lines and they get "amplified" by the amount of sharpening you did.

So what does this mean? It means that no LL shows you _exactly_ what you did, it shows you the oversharpening transparently, which is why the diagonal lines look oversharpened. Now, if you take a look at the squirrel (which actually resembles real image content a lot more) it still looks completely natural, although oversharpened, caused by the high strength settings.

Now, this is what happens when I turn on LL:
http://abload.de/thumb/sample_thelion_finesh0ho71.png (http://abload.de/image.php?img=sample_thelion_finesh0ho71.png)

1) The squirrel image now has very visible artefacts (I marked them) and it looks unnaturally sharpened.

2) What's interesting is that the effects of finesharp with LL for some reason do soften up the visible compression artefacts around the black diagonal lines, so much that it almosts acts like a de-amplification of the sharpener itself, it acts like it masks the sharpening effect. However, this is not what you would expect when you sharpen an image, especially not with the diagonal lines that are already artefacting (compression related) and also should get sharpened up. However, this effect is also not translating to the squirrel image, which is full of artefacts, meaning, you're not only oversharpening and masking, but LL also adds some very weird artefacts to the squirrel that are not part of the original image of the squirrel (look at the red arrows).

So the conclusion is, 2.0 is way too high and not recommended, as it amplifies the image way too much and causes side-effects. Second conclusion, LL produces some weird image artefacts, masks things you don't necessarily want to be masked, while no LL looks and works exactly as you would expect it to.

For completess sake, here's the same image with strength "1.0" and no LL:
http://abload.de/thumb/sample_thelion_fineshcwp8s.png (http://abload.de/image.php?img=sample_thelion_fineshcwp8s.png)

You can test it for yourself, if you want to be sure. If you turn down your strength from "2.0" to about "1.0" the diagonal lines look perfectly fine with no LL. This is because you didn't oversharpen the image, which is why I didn't recommend to use "2.0". "1.5" is already overdoing it IMHO.

BTW, always use some comparison tool where you can quickly swap between the images, manually. A browser with tabs works, or use StaxRips comparison tool, very handy.

[XMonarchY]

So do people like FineSharp more than LumaSharpen? I began to really like LumaSharpen in just about any quality content, but at lower-than-default settings for both strength and clamp.

I still keep gettiing occassional stutters, up to 10-15 times during a 45 minute video. It does create dropped and repeated frames during those stutters. I am still unable to figure out what is causing it... Can I provide some log or something? I have very slow upload speed of 512Kbits/second, so if the log is huge, I won't be able to upload it.

[TheLion]

Actually, you found exactly the same as I did, however, it seems that you misinterpreted the results of your sample or at the very least, you came up with a different conclusion, because you probably didn't also zoom into the video and inspected more closely why the diagonal lines behave the way they do when they are sharpened. Also, I have found exactly the same image artefacts that I got in my samples in yours, which I showed in my last post (the weird blackness that consumes the image (borders) and seems to completely destroy image details that were there before).

The following is a screenshot of your original sample to demonstrate. I zoomed in so I can better explain the differences.

Original image:
http://abload.de/thumb/sample_thelion_finesh9xq2q.png (http://abload.de/image.php?img=sample_thelion_finesh9xq2q.png)

Now, this is with finesharp active, strength 2.0, no LL:
http://abload.de/thumb/sample_thelion_fineshplp4i.png (http://abload.de/image.php?img=sample_thelion_fineshplp4i.png)

The strength of "2.0" already does so much sharpening to the image that it shows you exactly what you would expect. It amplifies the picture details and thus, it will also show you compression artefacts a lot stronger than before. The diagonal lines now have a white glow around them, which is because there were already quite strong visible compression artefacts that you can see when you zoom into the lines and they get "amplified" by the amount of sharpening you did.

So what does this mean? It means that no LL shows you _exactly_ what you did, it shows you the oversharpening transparently, which is why the diagonal lines look oversharpened. Now, if you take a look at the squirrel (which actually resembles real image content a lot more) it still looks completely natural, although oversharpened, caused by the high strength settings.

Now, this is what happens when I turn on LL:
http://abload.de/thumb/sample_thelion_finesh0ho71.png (http://abload.de/image.php?img=sample_thelion_finesh0ho71.png)

1) The squirrel image now has very visible artefacts (I marked them) and it looks unnaturally sharpened.

2) What's interesting is that the effects of finesharp with LL for some reason do soften up the visible compression artefacts around the black diagonal lines, so much that it almosts acts like a de-amplification of the sharpener itself, it acts like it masks the sharpening effect. However, this is not what you would expect when you sharpen an image, especially not with the diagonal lines that are already artefacting (compression related) and also should get sharpened up. However, this effect is also not translating to the squirrel image, which is full of artefacts, meaning, you're not only oversharpening and masking, but LL also adds some very weird artefacts to the squirrel that are not part of the original image of the squirrel (look at the red arrows).

So the conclusion is, 2.0 is way too high and not recommended, as it amplifies the image way too much and causes side-effects. Second conclusion, LL produces some weird image artefacts, masks things you don't necessarily want to be masked, while no LL looks and works exactly as you would expect it to.

For completess sake, here's the same image with strength "1.0" and no LL:
http://abload.de/thumb/sample_thelion_fineshcwp8s.png (http://abload.de/image.php?img=sample_thelion_fineshcwp8s.png)

You can test it for yourself, if you want to be sure. If you turn down your strength from "2.0" to about "1.0" the diagonal lines look perfectly fine with no LL. This is because you didn't oversharpen the image, which is why I didn't recommend to use "2.0". "1.5" is already overdoing it IMHO.

BTW, always use some comparison tool where you can quickly swap between the images, manually. A browser with tabs works, or use StaxRips comparison tool, very handy.

I can see what you mean. But I don't agree with your conclusions.
Zooming in on a test chart/picture like that to show the effect of sharpening filters will always tend to look "oversharpened". As you mention this content itself contains quite alot of artifacts. In total I would say LL on deals much more "gracefully" with this picture than LL off. The minimal pixel level differences in the sqirrel aren't significant in my opinion, even on a zoomed screenshot.
I sit at 1.1x screen widths from a 10 foot wide screen and a rather high end DLP projector in a bat cave. I can assure you that - in motion - with high quality content strength 2.0-2.4 is the upper limit of what I consider practical (I suggested it as High setting), while certainly remaining one of the more natural "sharpening"/contrast enhancement filters out there. It doesn't strike me as "oversharpened", and I consider myself rather sensible to that. FineSharp is one of the very few filters I can stand.
And in motion with good quality content I also consistently prefer LL On. It gives a slightly different look, which I prefer. It seems that the vast majority agrees.

[iSunrise]

It gives a slightly different look, which I prefer.
It shouldn't give you a different look. If it gives you a different look then that is not what we want. We want the same picture information, just amplified so it will look sharper. That's why it's called FineSharp. It's there to make fine details sharper, a graceful sharpener. We want to always choose the most accurate algorithm for a specific goal in mind, in this case we want a sharpener and not a tool that does sharpen, but also harms the picture in lots of other ways. Especially not if no LL doesn't produce these weird image artefacts. The negative effects of LL will get even more visible on low-resolution content if you upscale it. That's what my samples show and your samples show them, too.

The problem with most of people's tests is that they see that something is different and they instantly like it. madVR is about an accurate reproduction of what you feed it (accurate source reproduction). It's important that we settle on something that works for everyone and for that you have to prove that something is worth it or not worth it with actual real word samples.

If you can provide screenshots that show real benefits of LL in actual image content, which I doubt, it should be prefered, otherwise it adds unnecessary artefacts which are not there with no LL. The squirrel perfectly shows that no LL is more accurate. And there's a clear conflict, because you now tell me that LL is still prefered, which it clearly isn't, if you compared the images I took about 30 minutes to do.

This is how we did came this far, by judging based on some actual facts instead of "what I like best is what must be best".

You cannot just simply ignore one thing and then end the discussion with something like "the majority" agrees. The "majority" hasn't even shown some screenshots to compare. There's very few people left, apparently, that take their time to let everyone take part in comparisons. That's how it was done in the past, that's how it should be done.

Let's hope other people take their time, too, and provide samples and screenshots.

[Anime Viewer]

So do people like FineSharp more than LumaSharpen? I began to really like LumaSharpen in just about any quality content, but at lower-than-default settings for both strength and clamp.


When I first compared FineSharp and LumaSharpen I thought they had different effects (things they altered), but when I just did a quick test I didn't notice a significant difference with the content I tested. LumaSharpen seems to be less taxing (from a render speed perspective) than FineSharp. I'll do more extensive testing of LumaSharpen after madshi declares FineSharp testing complete, and asks us to move on to LumaSharpen.

[Sunset1982]

a Splitscreenfeautre would be great to compare different settings directly. Would that be possible or is it to much programming work?

[TheLion]

It shouldn't give you a different look. If it gives you a different look then that is not what we want. We want the same picture information, just amplified so it will look sharper. That's why it's called FineSharp. It's there to make fine details sharper, a graceful sharpener. We want to always choose the most accurate algorithm for a specific goal in mind, in this case we want a sharpener and not a tool that does sharpen, but also harms the picture in lots of other ways. Especially not if no LL doesn't produce these weird image artefacts. The negative effects of LL will get even more visible on low-resolution content if you upscale it. That's what my samples show and your samples show them, too.

The problem with most of people's tests is that they see that something is different and they instantly like it. madVR is about an accurate reproduction of what you feed it (accurate source reproduction). It's important that we settle on something that works for everyone and for that you have to prove that something is worth it or not worth it with actual real word samples.

If you can provide screenshots that show real benefits of LL in actual image content, which I doubt, it should be prefered, otherwise it adds unnecessary artefacts which are not there with no LL. The squirrel perfectly shows that no LL is more accurate. And there's a clear conflict, because you now tell me that LL is still prefered, which it clearly isn't, if you compared the images I took about 30 minutes to do.

This is how we did came this far, by judging based on some actual facts instead of "what I like best is what must be best".

You cannot just simply ignore one thing and then end the discussion with something like "the majority" agrees. The "majority" hasn't even shown some screenshots to compare. There's very few people left, apparently, that take their time to let everyone take part in comparisons. That's how it was done in the past, that's how it should be done.

Let's hope other people take their time, too, and provide samples and screenshots.

Again, I understand your point and even agree with most your arguments.
Both LL On and Off give a SLIGHTLY different look, and both obviously look vastly different from the original (FineSharp off). I can see why you interpret LL off as more "accurate" (as in "does what I would expect a traditional sharpening filter to do with the original) by those zoomed screenshots.
But if you really insist on discussing those screenshots again, here is my take: With your example I don't have any preference pro contra LL whatsoever. Those minor single pixel deviations are completely insignificant in my opinion - even in this zoomed screenshot scenario, let alone real world video content. To call them "weird image artifacts" and "more accurate to the original" is not my interpretation at all.
When I look at the sqirrel chart I vastly prefer the overall results with LL on. Call it "inaccurate", filtered, over-shoot compensated, whatever. The ringing/EE is dealt with much more "gracefully", while the "more representative of real video content" squirrel image shows again - in my opinion - completely insignifcant deviations in single pixels.

I am certainly not opposed to your objective approach of comparing pixels in zoomed screen captures (afterall I was one of those wasting way too much time @avs during the format/screen cap war comparing countless VC-1/AVC shots...), but in this case I still prefer LL on overall - as is the case with all video content I have tried. By a very small margin as the differences are minor given the proper context.

[iSunrise]

...Those minor single pixel deviations are completely insignificant in my opinion - even in this zoomed screenshot scenario, let alone real world video content. To call them "weird image artifacts" and "more accurate to the original" is not my interpretation at all.
When I look at the sqirrel chart I vastly prefer the overall results with LL on.
You again keep repeating that you prefer the squirrel with LL on, when I have clearly shown that LL on has artifacts that LL off doesn't. If you really had taken the time to compare them quickly side by side and you switched between them, you would instantly see what I see. The red arrows clearly show the problem and they are no exception, because these artefacts are also in my samples, which is not a coincidence by any means. I am not sure where you are going with this.

It's up to madshi to decide and the others to provide additional input, but I clearly am NOT satisfied with what I see when LL is on. It completely changes the image from the look with LL off.

LL always was a huge problem, even when we tested the dithering algorithms. It made the picture a lot darker overall. For some reason LL only works really good with downsampling, but doesn't for other features.

Hoping for some input from the usual suspects, like I mentioned before.

[JarrettH]

While we're debating this, I read on the FineSharp wiki that it is intended for high quality sources...

Small and relatively fast realtime-sharpening function, for 1080p, or after scaling 720p -> 1080p during playback (to make 720p look more like being 1080p).
It's a generic sharpener. Only for good quality sources! (If the source is crap, FineSharp will happily sharpen the crap.) ;) Noise/grain will be enhanced, too. The method is GENERIC.

Modus operandi: A basic nonlinear sharpening method is performed, then the *blurred* sharp-difference gets subtracted again.

[seiyafan]

Don't mean to veer off the current topic but what advantage does "D3D 11 for presentation" provide?

[JarrettH]

It enters and exits full screen exclusive mode much faster and there may be a performance advantage

[yukinok25]

Finesharp: It is quite interesting IMO. It produces a completely different look than LumaSharpen, and I think its up to personal preference. As for me, I like finesharp for doing a bit of a touchup. LSharpen has better effect for more sharpening, if I want that.
Repair at 1 looks great, found no problems. Thinning: lower than 0.025, thats sure, I like it most between 0.018 and 0.02. As for strength: 2.2 seems to be good for high preset for me too. For mid I would go with 1.4, and 0.9-1.1 for low.

I didnt test LL much, but I do prefer it on with anime.
I am new here, and I started to read this thread a couple of months ago.

I have been using MadVR for this period and played with the settings to get the best image video I could.
I have been paying with the image enhancement setting and I am totally agree with you here fine sharp is absolutely outstanding for me.

So far the best image I got its with repair at 0.50, mode 3.

All the others settings around 0.02/.003.