washed out colors from VGA to HDMI

[DiTBho]

So, I bought a VGA to HDMI adapter, and today I tried it. Colors are faded like when, after many cycles of your clothes in the washing machine you got colors washed out.

What can it be? And how to fix it?
The VGA cable is brand new.
The HDMI cable is brand new.
The VGA source has brilliant colors.
The VGA-to-HDMI adapter is a GANA 1080P Full HD.

Why life always is so complex?!? 

[DiTBho]

Googling ... this explains an interesting case, but it's not my case.

Attached to the HDMI there is a video grabber, and things work perfectly with HDMI-sources.

Don't  you know, guys, a well-known working VGA2HDMI? (supposing it's its fault)

[Nominal Animal]

Do you have full black-white intensity range?  Or is the HDMI output similar to when your RGB output was restricted to say 51-204 (20%-80%)?
If you have a scope, verifying the VGA color signals (pin pairs 1-6 for red, 2-7 for green, 3-8 for blue) are 0.7 Vpp, would be useful.

Have you opened the adapter yet? pics of the board?

[DiTBho]

Have you opened the adapter yet? pics of the board?

does not open, there are no screws, the case is glued.
If it is faulty I will return it to Amazon, but I cannot return it if it is damaged.

I am tempted to buy a second adapter, but which model?
I'd like to have something with screws so I can open it without problems.

[DiTBho]

Do you have full black-white intensity range? 

To test this, I would have to create a black- # 00.00.00-to-white- # ff.ff.ff intensity image test on Gimp.
I will do it! Then we can compare the original image on Gimp with the captured image.

diff(original{R.G.B}, captured{R.G.B}) = ?!?

If you have a scope, verifying the VGA color signals (pin pairs 1-6 for red, 2-7 for green, 3-8 for blue) are 0.7 Vpp, would be useful.

Yup, but in this case: should I amplify the { R, G, B } signals with OAs?
Isn't there a VGA amplifiers?

Or is the HDMI output similar to when your RGB output was restricted to say 51-204 (20%-80%)?

umm, how to test this? 

I don't have here a device with native HDMI-out.
I could borrow an RPI, just to see if the problem is at the HDMI-side of the grabber rather than at the VGA-side of the VGA2HDMI

That's the best I can do here.

[Nominal Animal]

To test this, I would have to create a black- # 00.00.00-to-white- # ff.ff.ff intensity image test on Gimp.

Or use one of the well known "test pattern" images, as they're already designed for visual verification and tuning of displays/televisions.

Yup, but in this case: should I amplify the { R, G, B } signals with OAs?

I didn't think that far.  I always try to find the problem first, before worrying about how to fix it.  (The idea being that if I limit the solution space to the one I know I can fix beforehand, I'm unlikely to pinpoint the true problem.)

I don't have here a device with native HDMI-out.

Hmm, that's a problem, since the issue could also conceivably be in the (HDMI input of the) display and not the VGA2HDMI gadget.

[m k]

The screen has switched on the Technicolor compensation.

[jonovid]

The VGA-to-HDMI adapter is a GANA 1080P Full HD.

looks like the same case style of video adapter as sold as a no-name brand on AliEx   
them cheap video adapters all use the same plastic case.
HDMI-to-AV  RGB-to-HDMI VGA-to-AV  RGB-to-AV just to name a few.
the brand name is irrelevant . crack it open  and see what pcb and chips their are using? 

[DiTBho]

The screen has switched on the Technicolor compensation.

Can you explain? and is there a workaround? kind of compensating circuit or something?

[DiTBho]

crack it open and see what pcb and chips their are using?

I paid 20 euro for it, I am still not sure if to return it to Amazon or not,  I am still in time to return. So at the moment I won't crack it for inspection, maybe in the future if I will decide to keep it.

- - -

I am looking at the Startech VGA2HD2, which looks better on the paper. It's more expensive, on Amazon it's listed at 110 euro, I can find on a local store for 90 euro, but it's still 5X more expensive than the GANUA one.

Dunno 

I am going to test all the equipment separately, stage per stage, so

• (source) VGA --> VGA2HDMI --> HDMI-LCD, comparing the same image on the VGA screen and on the HDMI screen
• (source) HDMI -->VIDEO-Grabber, comparing the captured image with the original one

rather than

(source) VGA --> VGA2HDMI (stage1) --> HDMI-VIDEO-grabber(stage2) --> stream


(source) VGA: my old laptop has one VGA port
(source) HDMI: The Raspberry RPI has one/two HDMI ports

[DiTBho]

In the description of the Startech VGA2HD2, they mentions YPbPr and PC-VGA in the video source compatibility list. They recommend a shilded and short VGA cable.

[AndyBeez]

This may be of no help at all but, my monitor has a hidden factory mode that permits setting 'profiles' on the HDMI channels. There is a whole soup can of settings including picture brightness, contrast, gamma, R/G/B gain, R/G/B offset, pixel overscan, pixel dithering and something called HDMI RGB range. Which seems to squeeze colours from greyscale thru vibrant. Maybe there is an equivalent on your monitor which can compensate for the budget voodoo?

[DiTBho]

Maybe there is an equivalent on your monitor which can compensate for the budget voodoo?

Yes, my NEC LCD supports these settings, but ... on the final project the HDMI goes directly to the HDMI-video-grabber

Code: [Select]

                _________          _________
    |  VGA     |         |        |         |
SBC | -------> |         |        |         |
    |          |         |  HDMI  |  H.264  |  udp/ip
    |          | adapter | =====> | encoder | =======>
       audio   |         |        |         |
    /--------> |         |        |         |
    |          |_________|        |_________|
    |           VGAtoHDMI           Grabber
    |
comments
microphone
and here I can do nothing but post-processing color correction on { FinalCut, Premiere, DaVinci, ... }
But I would like to avoid doing it.

[bw2341]

So the VGA source is a single-board computer? Is it your own design or a commercially available product?

Is there a serial EEPROM on the SBC to present the EDID information? If not, I suspect that without an EDID EEPROM, the default values for video white and sync levels on the VGA to HDMI adapter do not match the output levels on the SBC.

If there are no user controls on the VGA to HDMI adapter to adjust for various input VGA levels, you will have to find a more expensive VGA to HDMI adapter with this feature.

To check if the VGA to HDMI adapter is defective, I would connect an older PC with a VGA output.

[DiTBho]

So the VGA source is a single-board computer? Is it your own design or a commercially available product?

The SBC is a commercial AMD Geode x86-PC in mini ITX form factor, running Linux.
I have also tried a common PC and a laptop with no progress, still washed out colors.

Is there a serial EEPROM on the SBC to present the EDID information?

Yes. But it didn't help.

I also tried with a RGBHV cable, a cable with only the { R, G, B, H, V, gnd } wires from the VGA-board adapter to the VGA2HDM, so without any additional EDID information over i2c, there was no difference in the results: washed out colors.

It sounds that ... either EDID is wrong or it's irrelevant (ignored)

If not, I suspect that without an EDID EEPROM, the default values for video white and sync levels on the VGA to HDMI adapter do not match the output levels on the SBC.

The SBC is a true miniPC with a common PC-AMI-bios. When it boots it's 640x480@50Hz, H and V sync work with a pixel clock frequency of ~25Mhz, which should be the minimal default choice.

640x480@60Hz, pixel clock 25.175 MHz -----> Industry standard

Then you boot Linux, the kernel reads what it's passed through boot command line, and accordingly sets the video card to 1024x768@60Hz, which OK, it has a different sync-polarity and the higher 65MHz pixel-clock, but it should be a common choice.

1024x768@60 Hz, pixel clock 65.0 MHz

I mean, I didn't use any weird or extreme configurations:

weird: 1024x768@43 Hz, pixel clock 44.9 MHz (*interlaced)
weird: 1024x768@70 Hz, pixel clock 75.0 MHz
weird: 1024x768@75 Hz, pixel clock 78.8 MHz
weird: 1024x768@85 Hz, pixel clock 94.5 MHz
weird: 1024x768@100 Hz, pixel clock 113.31 MHz
extreme: 1600x1200@60 Hz, pixel clock 162.0 MHz
extreme: 1600x1200@60 Hz pixel clock 162.0 MHz
extreme: 1600x1200@65 Hz pixel clock 175.5 MHz
extreme: 1600x1200@70 Hz pixel clock 189.0 MHz
extreme: 1600x1200@75 Hz pixel clock 202.5 MHz
extreme: 1600x1200@85 Hz pixel clock 229.5 MHz
extreme: 1600x1200@100 Hz, pixel clock 280.64 MHz
extreme: 1680x1050@60 Hz, pixel clock 147.14 MHz
extreme: 1792x1344@60 Hz, pixel clock 204.8 MHz
extreme: 1792x1344@75 Hz, pixel clock 261.0 MHz
extreme: 1856x1392@60 Hz, pixel clock 218.3 MHz
extreme: 1856x1392@75 Hz, pixel clock 288.0 MHz
extreme: 1920x1200@60 Hz, pixel clock 193.16 MHz
extreme: 1920x1440@60 Hz, pixel clock 234.0 MHz
extreme: 1920x1440@75 Hz, pixel clock 297.0 MHz

If there are no user controls on the VGA to HDMI adapter to adjust for various input VGA levels, you will have to find a more expensive VGA to HDMI adapter with this feature.

I am afraid there is no control. There are no trimmers, the VGA2HDMI looks like a blackbox 

[Nominal Animal]

Does the Linux kernel report any EDID information (from a HDMI display, back through the VGA2HDMI converter, via I2C to the VGA adapter)?

Install the edid-decode package (sources at git.linuxtv.org/edid-decode.git), and run
    find /sys/devices/ -name edid -exec edid-decode '{}' ';'
to find out.

If the kernel receives no EDID information, then the VGA2HDMI converter does not pass it back from the HDMI display to the VGA adapter, which indeed could be part of the problem.  It is notable that HDMI uses E-EDID whereas VGA just plain EDID (same link), so some kind of mapping is needed on the converter.

The particular bits we're concerned about are the three most significant bits at byte offset 20 in the EDID 1.4 block:
    000: RGB signal range is from -0.3V to +0.7V
    001: RGB signal range is from -0.286V to +0.714V
    010: RGB signal range is from -0.4V to +1.0V
    011: RGB signal range is from 0V to +0.7V

It is also possible in Linux to create your own EDID information for the kernel driver to use instead of what is passed via the VGA I2C lines in a fully connected VGA cable.  Specifically, in edid.S, you'd change
    video_parms:   .byte   0x6d
(which corresponds to the default 0V to +0.7V signal range), into either
    video_parms:   .byte   0x0d  /* -0.300V to +0.700V */
or
    video_parms:   .byte   0x2d  /* -0.286V to +0.714V */
or (unlikely!)
    video_parms:   .byte   0x4d  /* -0.400V to +1.000V */

Whether your VGA adapter is actually capable of honoring this or not, I do not know.

Pin 9 in the VGA connector does provide at least 50mA at 5V±5%, but to create a board to adjust the levels, one would need a bipolar supply, and a capability to both shift (0.0V to -0.3V) and amplify (by 1.000× to 1.429×) each of the RGB signals, noting that each of them have a separate ground/return.  So, it should be quite straightforward to implement such an analog board, except that at 1280x1024, you need 160 MHz of bandwidth; are fast enough opamps too expensive to make such a thingamajick useful?  I dunno.  Making a stable enough bipolar supply alone scares me.

[mariush]

The HDMI output may be Studio (Limited) RGB / YCbCr   where the values for the 3 elements are not 0..255 , they're 16..235 for Y and 16..240 for Cb and Cr

See https://en.wikipedia.org/wiki/YCbCr#Y'PbPr_to_Y'CbCr

You should configure the HDMI capture card to also capture assuming the input is in this format, and the capture card should then expand that 16..235 to original 0..255  , and Cb/Cr from 16..240 to 0..255 and restore the colors.

Some TVs use the "Full " (0..255) YPbPr / RGB when you configure it on PC Input / Raw  but assume that Studio/Limited mode when HDMI input is set to "Bluray" or "TV set top box" or allow you to switch between Full / Limited.

Video cards also have this option to output Studio (Limited) RGB/YCbCr  or Full RGB/YCbCr - check the control panel of your video card. I know for sure AMD cards have it. 
This way you would be able to test your capture card.... perhaps by setting it as 2nd display and clone your main monitor.
There are also filters to correct captured data after capture in most video editors, if this turns out to be the issue and you already captured stuff.

[m k]

The screen has switched on the Technicolor compensation.

Can you explain? and is there a workaround? kind of compensating circuit or something?

Just one of those asymmetrical picture "enhancement" modes.
But that is in the monitor so it's irrelevant.

It seems that your problem is too cheap adapter.
On the other hand the link has a converter list and it is not saying anything about the picture quality, it's also 10 best, yours is #7, so one can assume that not so good ones are disqualified.
https://www.slashdigit.com/best-vga-to-hdmi-converters/

If you have a peak hold DMM make white full screen picture and measure those VGA RGB values.

There's a USB power connector.
Have you checked how your Linux box is seeing it?

[bw2341]

Oops! I had it the wrong way around. The sink device (VGA to HDMI adapter) has the EDID EEPROM. The source (SBC) has to read the EDID and present the proper signal.

The SBC is a commercial AMD Geode x86-PC in mini ITX form factor, running Linux.
I have also tried a common PC and a laptop with no progress, still washed out colors.

If the VGA to HDMI adapter has the same problem with other VGA sources, the VGA to HDMI is either broken or incorrectly designed.

You mentioned earlier that you don't have a native HDMI source to check the HDMI capture device. You could try a DVI source with a DVI to HDMI cable. It's not the best test device as there are a lot of differences between DVI and HDMI. Can you reveal which HDMI capture device you are using?

With a DVI to HDMI cable you could also test the VGA to HDMI adapter by connecting it to a DVI monitor. This might not work as I'm not sure if HDMI sources are required to support DVI sinks.

Could you post screenshots and video clips of the problem? A screenshot from the source and the matching video clip of the capture would be helpful.

[AndyBeez]

I note @eevblog Dave has already been in this ball park before:

https://www.eevblog.com/forum/reviews/vga-to-hdmi-converter-teardown/

[DiTBho]

Does the Linux kernel report any EDID information (from a HDMI display, back through the VGA2HDMI converter, via I2C to the VGA adapter)?

Just checked and it doesn't report any EDID information. I never worried because it's not a problem for my { NEC-17"CRT, NEC-21" }, which work just fine.

My NEC monitors are "multisync" so they probably have a smart circuit; I'd like to know that the VGA2HDMI module handles H and V frequencies and all other properties without talking to the EDID eprom.

[DiTBho]

Pin 9 in the VGA connector does provide at least 50mA at 5V±5%, but to create a board to adjust the levels, one would need a bipolar supply, and a capability to both shift (0.0V to -0.3V) and amplify (by 1.000× to 1.429×) each of the RGB signals, noting that each of them have a separate ground/return.  So, it should be quite straightforward to implement such an analog board, except that at 1280x1024, you need 160 MHz of bandwidth; are fast enough opamps too expensive to make such a thingamajick useful?  I dunno.  Making a stable enough bipolar supply alone scares me.

There are only 4Mbyte of VRAM for the framebuffer, it's enough from 640x480/32bit to 1024x768/32bit

• 640x480@60Hz, pixel clock 25.175 MHz, ~<1MB vram
• 1024x768@60 Hz, pixel clock 65.0 MHz, ~<3MB vram

Limited VRAM here is a pros because you only need ~70Mhz of bandwidth for the OAs 

[DiTBho]

If the VGA to HDMI adapter has the same problem with other VGA sources, the VGA to HDMI is either broken or incorrectly designed.

Just ordered other three from Amazon. Just for testing, I will return them in a week.
- GANA white (9 euro)
- GANUA black (13 euro)
- GANA black (20 euro)

I am also going to buy the Startech Pro (120 euro), which looks more professional and has better feedbacks

You mentioned earlier that you don't have a native HDMI source to check the HDMI capture device.

I asked a friend to lend me an RPI 3. This Linux card has an HDMI port. Tomorrow we will see 

With a DVI to HDMI cable you could also test the VGA to HDMI adapter by connecting it to a DVI monitor. This might not work as I'm not sure if HDMI sources are required to support DVI sinks.

Could you post screenshots and video clips of the problem? A screenshot from the source and the matching video clip of the capture would be helpful.

Yup, in hindsight I have already prepared a kind of Philips PM5544 test card, I just need to set-up and compare.

I will post here some screenshots.

[DiTBho]

Have you checked how your Linux box is seeing it?

it's only a +5V power link. USB.D+ and USB.D- pins are not connected.

[DiTBho]

The White Ganua in a video on YouTube