- Update (16th Aug 2015) – Now a CTX: CTX201802 – FAQ: HDX Extra Color Compression (ECC) Policy in XenApp and XenDesktop
Extra Color Compression (ECC) is a policy that can be applied to control how HDX manages bandwidth vs. quality and other resources (e.g. CPU). It is documented in the XenDesktop and XenApp product documentation here.
What is Extra Color Compression (ECC)?
Technologically, it is chromatic (colour) sub-sampling of JPEG data.
Why is it call ECC and not Chromatic Sub-sampling?
“Sub”-sampling implies doing less of something. In the case of this policy , the sampling is an additional step and so applying this policy is doing something _extra_ and as such there is an associated CPU cost.
What is Chromatic Sub-Sampling?
I’ve written before about how chromatic sub-sampling can be applied to both H.264 and JPEG data, in these articles here and here. There is also plenty of good technical detail on Wikipedia and the rest of the internet. Basically it’s a compression technique that takes into account that the human eye is actually more sensitive to luminescence (brightness) than colour information. At the bottom of this article I’ve added a “Geek Treat” for those that want to read more.
When can I use Extra Color Compression (ECC)?
This policy is relevant to HDX graphics modes that use JPEG technologies i.e.
- the original thinwire mode (now the “legacy graphics mode” in XenDesktop/XenApp 6.5
- the emerging thinwire+ technologies (at time of writing in tech preview)
What are the benefits?
Extra Color Compression is an optimization that can save up to 20% on the size of lossy compressed images, but at a small expense of quality. This can reduce bandwidth significantly particularly when customers have simpler, legacy applications with limited graphical-richness.
Why might I not want to use ECC?
- It is additional compression and the quality reduction in highly graphical data may be undesirable. Certain data such as text over a complex background will appear sharper if ECC is not used.
- The is a small additional CPU cost
- Certain kinds of graphical data may exhibit artefacts. A typical example is shown here: the artefacts are the red lines on the picture on the web page below:
- The red lines over the image are artefacts of the solid red bar at the bottom of the web page. This is fairly unusual as it caused by the way the red bar is overlaid on the website, however if users find they use applications that do exhibit such artefacts we would recommend changing this policy. Such artefacts are likely to be more perceivable on static images. (This is essentially a manifestation of Nyquist’s Theory, i.e. a limitation of Physics and the technology and not something Citrix can change!)
Geek Treat – A Walkthrough of Chromatic Sub-Sampling
The Original Image:
- Thanks & Credit to Martin Latteier for the putting this together with the UK HDX team!
References
The original release announcement is sometimes referenced but is now quite out of date: http://blogs.citrix.com/2011/01/07/dynamic-color-compression-cuts-bandwidth-consumption-by-35/
The 35% quoted is probably excessive and in average use cases 10-20% is more likely. In general ECC is also not currently enabled by default although this has not always been the case.
Virtually Visual 
Nice article, Rachel. Again, I gather this is something in particular of interest to users that are not on a LAN and cannot afford the extra bandwidth. It will be interesting to see how much of this can be compensated for by Framehawk. The ability of a session to self-adjust according to what it thinks of its own quality based on parameters such as frame rate, CPU utilization, bandwidth, latency, ping responses time, etc. would be an interesting topic to explore.
LikeLike