It is currently Fri May 25, 2018 3:49 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 80 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6
Author Message
PostPosted: Sat Apr 21, 2018 5:15 am 
Offline

Joined: Thu Jul 23, 2015 9:56 am
Posts: 9
NewRisingSun wrote:
I think he's asking about out-of-range R/G/B levels coming out of the color decoder after all automatic gain controls have been applied, which happens quite often in the NES since it does not start with R/G/B to begin with.

Yes, I'm talking about this.

NewRisingSun wrote:
I cannot imagine any analog TV adding DC to the entire RGB tuple just because one of them goes negative, and all old TVs that I have seen certainly didn't.

How about not so old? in 1995 there was already tvs that had OSD for example.
Also, perhaps some circuits may clamp somewhere in matrixing, or I don't know.

Anyway. Here is what it looks like now:
https://imgur.com/a/pHnQn1D
Read descriptions.

Almost all colors has some clipping issue.

Yes, I was trying to reduce contrast until all clipping values will fit. In result I had 0.5 contrast (half).

NewRisingSun wrote:
There is one partial PAL raw recording in this post. Partial because the capturing program is for NTSC only, and so still samples only for 1/60th time at 8*NTSC-Fsc.

I thought it has only mario inside. I would like to check normal PAL TV recording.

Regarding AGC. I wan't to know how I should exaclty scale voltages into IRE.
I don't think that decoder is forecaster of what white level is, without having white on screen.
So, it has to align voltages according to some rules without information about colors on picture.
At this moment I simply set color 1d to black = 0 IRE and white color 30 to 100 IRE.
Perhaps I should do this in other way. For example white is 120 IRE.

One additional note.
Consider decoded is R'G'B'.
Its theoretical luma is: 0.299R'+0.587G'+0.114B'
Now, assume R' is negative.
Then, clipped luma is 0.587G+0.114B, and it's greater than theoretical, because R is negative.
That's why I even started to think about this issue.
Similar consideration leads to darker clipped luma for colors which have component over 1.

I still don't get it though. Why we use linear transforms and equations for colors which are gamma precorrected.
As far as I understand, they have 1/2.2 gamma, and so you have to correct them to linear first.

Also, I was trying to assume that R'G'B' have 1/2.2 gamma, and then correct to RGB, and assuming that it is CIE RGB,
convert to XYZ, and then convert to sRGB. I got some trash in the end.


Top
 Profile  
 
PostPosted: Sat Apr 21, 2018 6:16 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 523
Your picture's "simple clipping" looks exactly right to me. I'm not sure what kind of different colors you are expecting.
r57shell wrote:
Regarding AGC. I wan't to know how I should exaclty scale voltages into IRE.]
There are two AGC methods used by TVs: adjust to sync, and adjust to burst. Adjust to sync is usually done for RF input, adjust to burst for baseband input. Adjust to sync means taking into account that sync tip to blanking is defined as 40 IRE, so measure and scale accordingly. (To be more precisely: since an RF signal is negative modulated, the sync tip will resemble the peak-to-peak amplitude.) Adjust to burst means that the color burst peak-to-peak amplitude is defined as 40 IRE, so measure and scale accordingly.
For the NES, adjusting gain according to sync will lead to a brighter than normalized picture, while adjusting to color burst will lead to a darker than normalized picture, "normalized" meaning you just define the NES' white level as 100 IRE (which is certainly not what any TV does, as the TV has no prior knowledge about what level is supposed to be "white").
r57shell wrote:
How about not so old? in 1995 there was already tvs that had OSD for example.
Doesn't matter. Regardless of age, there is no reason for a TV to add a DC offset to all three R/G/B simultaneously just because one of them goes negative. Just clip negative to zero individually and be done with it.
r57shell wrote:
I still don't get it though. Why we use linear transforms and equations for colors which are gamma precorrected. As far as I understand, they have 1/2.2 gamma, and so you have to correct them to linear first.
That might be correct in some abstract colorimetric sense, but NES/PAL systems are defined for gamma pre-corrected signals, not for some idealized signal, so transforming in linear space is wrong for those particular signals. (If you wanted to use abstract-idealized transformations, you would have to use different coefficients than 0.299/0.587/0.114 for current phosphor characteristics as well.)
r57shell wrote:
I thought it has only mario inside. I would like to check normal PAL TV recording.
I cannot seem to find the raw file of that Trappatoni picture at the moment. Attached is the only other raw PAL capture from normal TV programming that I have left. If you want, I can get out my setup and take some additional pictures.


Attachments:
OttoRehhagel.zip [262.93 KiB]
Downloaded 24 times
Top
 Profile  
 
PostPosted: Mon Apr 23, 2018 11:35 pm 
Offline

Joined: Thu Jul 23, 2015 9:56 am
Posts: 9
NewRisingSun wrote:
r57shell wrote:
I thought it has only mario inside. I would like to check normal PAL TV recording.
I cannot seem to find the raw file of that Trappatoni picture at the moment. Attached is the only other raw PAL capture from normal TV programming that I have left. If you want, I can get out my setup and take some additional pictures.

So, my decoder is sane. https://imgur.com/a/XmjZV17
This means, that actual PAL you have, has bars which can be emulated.
HardWareMan's dump has no such bars, or at least if the bars that it has, has same source, then they much less noticable.
I guess I need to find out how these bars made.

Edit:
r57shell wrote:
Also, I was trying to assume that R'G'B' have 1/2.2 gamma, and then correct to RGB, and assuming that it is CIE RGB,
convert to XYZ, and then convert to sRGB. I got some trash in the end.

I've found my mistake with sRGB conversion.
I had 0.031308 instead of 0.0031308.
Now it's not trash on output anymore.


Top
 Profile  
 
PostPosted: Fri Apr 27, 2018 5:47 pm 
Offline

Joined: Thu Jul 23, 2015 9:56 am
Posts: 9
Here is result of all my struggle.

https://gist.github.com/realmonster/b89 ... 1c42acf9e7
https://youtu.be/3f7UVUSlE0o

It's not final, but I hope I'll drop it for a long time.
Too much time spent into it. Need a break.
Possible addition for example: use different kernels instead of moving average.

Side note: crt-royale - not mine, all I do is applying it over mine result.


Top
 Profile  
 
PostPosted: Sat Apr 28, 2018 1:31 am 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 270
Location: Russia
Topic with more details was also announced here:
https://forums.libretro.com/t/add-nes-p ... kage/15848
http://forum.emu-russia.net/viewtopic.php?f=13&t=7041 (nice pictures and PAL-artifacts in-motion)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 80 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group