Brightness and Contrast

A "new fashioned" televisor, using an Arduino to drive the motor and display.

Moderators: Dave Moll, Andrew Davie, Steve Anderson

Brightness and Contrast

Postby Andrew Davie » Sat Apr 01, 2017 9:42 pm

Here's the current video pipeline, as I understand it...

I have a 16-bit sample from a WAV file (at, say, 22050 Hz).
I have to convert this into an 8-bit value representing brightness of a "nixel" (a Nipkow pixel - I just coined that, so (TM))
So first I downshift (in the current case, by 6 bits) - effectively the same as dividing by 64. Just because that gets my range 0-255 for the videos I am testing.
Then I lookup the gamma-corrected value and send that to the LED array.

Now to get brightness and contrast...

I believe that brightness is just an offset of the 0-255 value, with the resultant value capped to 0-255 range.
So, I have a signed brightness (-128 to 127) which is added to the 0-255 brightness, it's capped, and then that's the new value.
I'm unsure if the brightness should be applied to the gamma-corrected value, or before gamma correction.
I'm pretty sure the analog NBTV solution is to pre-apply. But I'm inclined to think a post-application would be better.

So I've been thinking about contrast and how that works.
I now think that it's a multiplier of the 0-255 value - effectively stretching or shrinking the spacing bewteen values.
SO, let's say we had nixels of the value 0 to 100, and our contrast was *2 we would now have values from 0 to 200.
Again, the resultant value would be capped to 0-255 range.

The pipeline could apply brightness, contrast, gamma in any order and I'm not entirely sure which would be advisable.
Really quite easy to test, I suppose.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Brightness and Contrast

Postby Klaas Robers » Sat Apr 01, 2017 10:23 pm

Brightness is indeed an offset of the video value. You do that before gamma correction, because you want to keep black as black, that is no current through the LEDs. From that point the non linear gamma comes into action.

Contrast is an amplification. You should preferably do the multiplication before truncation to 8 bit words. Otherwise you get more quantisation noise, introduced by too early truncation, followed by amplification (multiplication).

But there is more. It is not granted that in the file the digital value zero (00 00) is black. It depends from the source that you are going to use. For the CDs of the NBTVA I tried to keep black at digital 00 00, sync pulses are negative (two's complement), and video is positive. But it can be different, as video signals in general are AC coupled, the mean value of video and sync is zero.

So you should do something on DC-restoring, have a routine that keeps the bottom of the sync pulses at a certain value. That is, after the video has got its optimal range. Then your brightness control brings black to 00 00. This is absolutely needed, as the depth of the sync pulses is not at all stable from source to source.

The order is then:
- Contrast control = multiply by a certain value.
- DC-restoring = clamping.
- Brightness control = add / subtract a certain value.
- Truncation, that is limiting from 00 to FF,
- This clips off the sync pulses too.
- Gamma correction.
- PWM setting.
User avatar
Klaas Robers
"Gomez!", "Oh Morticia."
 
Posts: 1656
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

Re: Brightness and Contrast

Postby Andrew Davie » Sat Apr 01, 2017 10:34 pm

Klaas Robers wrote:Brightness is indeed an offset of the video value. You do that before gamma correction, because you want to keep black as black, that is no current through the LEDs. From that point the non linear gamma comes into action.

Contrast is an amplification. You should preferably do the multiplication before truncation to 8 bit words. Otherwise you get more quantisation noise, introduced by too early truncation, followed by amplification (multiplication).

But there is more. It is not granted that in the file the digital value zero (00 00) is black. It depends from the source that you are going to use. For the CDs of the NBTVA I tried to keep black at digital 00 00, sync pulses are negative (two's complement), and video is positive. But it can be different, as video signals in general are AC coupled, the mean value of video and sync is zero.

So you should do something on DC-restoring, have a routine that keeps the bottom of the sync pulses at a certain value. That is, after the video has got its optimal range. Then your brightness control brings black to 00 00. This is absolutely needed, as the depth of the sync pulses is not at all stable from source to source.

The order is then:
- Contrast control = multiply by a certain value.
- DC-restoring = clamping.
- Brightness control = add / subtract a certain value.
- Truncation, that is limiting from 00 to FF,
- This clips off the sync pulses too.
- Gamma correction.
- PWM setting.



Thank you for the very useful information.
Since I am fairly certain I will now "standardise" my source files - that is, preprocess them - I can ensure some things.
I am thinking of using the full 0-255 range for brightness (even though I know - only 64 needed for the eye). But nonetheless, with 0-255 for brightness I just need a single bit (say, lowest bit) to indicate a sync pulse (if indeed I even need sync pulses at all because as you have said, I can calculate this). But anyway, with a sync pulse as the lowest bit, it will be negligible if ignored and just played as brightness value, but easy to detect with a digital stream direct from a SD card/file. Then I have full range of 0-255 which needs no preprocessing unless brightness/contrast are applied. But it would be nicer this way. There may be different source formats - I can ignore all that and guarantee my televisor is "fed" with a standardised format of my own choosing.
I have been playing with Audacity, and I think 8-bit, 19200 Hz seems a reasonable choice. The video from 0-255 with bit 0 (value 1) being sync pulse.
Many thanks for the suggestion on the pipeline/processing order.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Brightness and Contrast

Postby Klaas Robers » Sat Apr 01, 2017 10:48 pm

It is even easier. If you use digital value 00 as sync pulse and exclude that for video, then all values 01 to FF are free for video. We did something similar with the sync of Compatible Colour NBTV on CD. But you have to pre-process all your files, you cannot use available material. You make an exclusive video format.
User avatar
Klaas Robers
"Gomez!", "Oh Morticia."
 
Posts: 1656
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

Re: Brightness and Contrast

Postby Andrew Davie » Sat Apr 01, 2017 10:52 pm

Klaas Robers wrote:It is even easier. If you use digital value 00 as sync pulse and exclude that for video, then all values 01 to FF are free for video. We did something similar with the sync of Compatible Colour NBTV on CD. But you have to pre-process all your files, you cannot use available material. You make an exclusive video format.


Yes, good idea. And yes, I plan to preprocess all my files. Since I put them on a SD card to play anyway - I see this as not much different to others putting their files on a CD. I am in control of the playback software so the format can be whatever I want it to be. Choosing a format that reduces the demand on the microprocessor makes a lot of sense and is easy for me.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Brightness and Contrast

Postby Klaas Robers » Sat Apr 01, 2017 11:03 pm

This is the way to go when microprocessors are expensive or take up much space.

In fact you don't need any contrast control or brightness control in your monitor. Even the gamma correction can be done in preprocessing. Then still you need to find a clever trick for the sound, as 8 bits is far too few for sound, but may be you can find some clever preprocessing for that problem too.
User avatar
Klaas Robers
"Gomez!", "Oh Morticia."
 
Posts: 1656
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

Re: Brightness and Contrast

Postby Andrew Davie » Sat Apr 01, 2017 11:52 pm

Klaas Robers wrote:This is the way to go when microprocessors are expensive or take up much space.

In fact you don't need any contrast control or brightness control in your monitor. Even the gamma correction can be done in preprocessing. Then still you need to find a clever trick for the sound, as 8 bits is far too few for sound, but may be you can find some clever preprocessing for that problem too.


Yes, the gamma needs to be preprocessed (even though it is relatively cheap to do in real time). I think I might need contrast/brightness to cater for different viewing conditions, so I still plan to keep those. There are many pages on the web that claim 8 bits is sufficient for sound. I will have to try and see! I don't want perfection - something "tinny radio sounding" would be sufficient.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia


Return to Andrew Davie's Arduino Televisor

Who is online

Users browsing this forum: No registered users and 1 guest