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 15th May 2018, 18:38   #1  |  Link
Logan9778
Registered User
 
Join Date: Mar 2017
Posts: 118
Using smoothlevels on NTSCJ Japanese DVD

Hi guys.

I'm trying to experiment with levels, but I don't know if I'm doing it right. I'm trying to get a faded looking NTSCJ Japanese encode to show up right on my lcd monitor. I think it's outputing 16-235 luma, so I'm using smoothlevels to change it to 0-255. Looking at the built in histogram in AvsPmod, dark blacks now reach the 16 limit line, where before they were showing around max 25 to 30. But the problem is, they now cross over it at points, looking like they hit around 12 over even 10. I know Ghitulescu said that PAL and NTSCJ can have darker blacks than the 16 limit, so I guess my question is, how should I deal with the blacks that go beyond 16?

Quote:
Originally Posted by Ghitulescu View Post
In PAL it is possible to have a blacker black as the pedestal is not required (so for NTSC in Japan).

Do PAL and NTSCJ use some other luma scale?

This is the smoothlevels code I'm using.

smoothlevels(Output_low=0, Output_high=255)

Thanks!

Here are pics of my AvsPmod with and without smoothlevels

No smoothlevels



Smoothlevels



Blacks going over the 16 limit line


Last edited by Logan9778; 15th May 2018 at 20:12.
Logan9778 is offline   Reply With Quote
Old 16th May 2018, 23:32   #2  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
It is fine to have black go below 16 after your range adjustment. You might also do a bit less of a stretch, maybe outputlow=4 or something. The error is most likely not a true levels issue because it is far away from normal limited range. It seems like it is simply low dynamic range with a high black level; use as much stretch to get it corrected as you can without going over very often.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 16th May 2018, 23:47   #3  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
In the end you got to know what your playback chain is gonna do with Y<16.
Make a DVD with flickering test bars and watch the result.
For most of DVD players you want to touch Y=16 only for pitch black, this shall yield R=G=B=0.
Y of 12 or 10 would yield the same black, so you would have effectively crushed your shadows.
If such movie exhibits different blacks per scene, and it doesn't look like artistic intention then I would consider that a grading fault.
I suggest to go through by scene and consequently adjust shadow values by scene.
To see what the called function is actually doing it can be recommended to keep debug view open.
SmoothCurve is often my friend here.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."
Emulgator is offline   Reply With Quote
Old 17th May 2018, 08:14   #4  |  Link
Logan9778
Registered User
 
Join Date: Mar 2017
Posts: 118
Thanks guys!

In the end, I used

Code:
SmoothLevels(input_low=24, input_high=229, output_low=16, output_high=235)
I realized I should still output 16-235 for YUV, and that the luma had been over-compressed ( I was getting 24 for solid black in ColorYUV). At least I think this is what is happening. I wonder if the 229 should have been 227, since pitch black was off by 8. 235-227=8. But it doesn't seem to make any huge difference.

I had been using AvsPmod's %YUV luma showing in the bar, and for some reason it showed blacks too high, and whites too low. I went with ColorYUV() and used the loose min/max values and it seems to be correct.

After using the Smoothlevels() code,
Avisynth histogram showed pitch black as 16 ( the first black frame of the video) while the brightest scenes hit 255 max in the histogram. So, I guess it's good now?

Should I do anything with the colors since I stretched the luma?

Last edited by Logan9778; 17th May 2018 at 09:57.
Logan9778 is offline   Reply With Quote
Old 17th May 2018, 18:22   #5  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
Great solution, much better than my suggestion. Best to use 16-235 for the output.

You could check the loose min/max values for the chroma channels as well, remember to use 16-240 for them.

Edit: This probably won't work at all, the video is very unlikely to have 100% values for min/max U or V. I am not sure what should be done.. thinking in U and V is hard. Maybe do the range fix in RGB?
__________________
madVR options explained

Last edited by Asmodian; 17th May 2018 at 19:19.
Asmodian is offline   Reply With Quote
Old 17th May 2018, 22:55   #6  |  Link
Logan9778
Registered User
 
Join Date: Mar 2017
Posts: 118
Thanks Asmodian!

Yeah, I might try converting it all to RGB later and experiment there. A LOT more learning to go!

EDIT: Well, in the end, I found out that there was no mistaken double compression of the levels when they compressed the levels to YUV.

But it was interesting learning about levels, and personally, I think they are a little compressed ( probably for an artistic reason to fade them a little) and that it is possible to stretch or change them to what you think they should be.

Last edited by Logan9778; 18th May 2018 at 22:18.
Logan9778 is offline   Reply With Quote
Old 20th May 2018, 07:41   #7  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Probably less for an artistic reason than that someone who didn't know what they were doing did another 0-255->16-235 compression after it had already been done. Very common in low-budget stuff.

Digital NTSCJ can indeed be 0-235, as an incorrect interpretation of the NTSCJ 0-714mV in Japan, generally by capture cards only developed for the American market. The correct way to handle it, and any other level weirdness, would be to scale it to 16-235 (or better yet, 64-960), where you use your best judgment to decide where the zero-level lies. BTB isn't uncommon due to analog and DCT noise, but black is still black; just scale and threshold it wherever it looks like it should be.
foxyshadis is offline   Reply With Quote
Old 22nd May 2018, 23:24   #8  |  Link
Logan9778
Registered User
 
Join Date: Mar 2017
Posts: 118
Thanks Foxy.

64-960?

It doesn't seem to be double compression, but I think someone did screw up along the line somewhere. Looks like the first frame is just a black frame, yet it shows to be 23 in the 16-235 scale.
Logan9778 is offline   Reply With Quote
Old 23rd May 2018, 02:33   #9  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by Logan9778 View Post
Thanks Foxy.

64-960?

It doesn't seem to be double compression, but I think someone did screw up along the line somewhere. Looks like the first frame is just a black frame, yet it shows to be 23 in the 16-235 scale.
64-960 is the same scale in 10-bit. Makes a lot of sense to process and encode anime especially in high bit depth, to prevent the broad banding you often get in flat areas.
foxyshadis is offline   Reply With Quote
Old 23rd May 2018, 02:42   #10  |  Link
Logan9778
Registered User
 
Join Date: Mar 2017
Posts: 118
Oh Thanks! Something I will remember! I was wondering why I always see old anime in 10-bit.
Logan9778 is offline   Reply With Quote
Reply

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 17:42.


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