Citrix HDX and HDX 3D Pro technologies use a multitude of compression technologies and codecs to support an enormous range of hardware, end-points, operating systems and network connections for XenDesktop and XenApp.
Our technologies are adaptive, so most of the time you will be unaware if we are changing technologies under-the-hood to support your particular systems, application usage and network conditions.
The administrator has control over the adaptive behaviour and compression levels via the visual policies available, details here. There are policies that control static and moving image compression separately because the human eye is less sensitive to artefacts in moving images (our brains fill in the details).
JPEG is one technique we use in some of our codecs (how we encode and transmit graphics from the server to the user’s client device). It is one of the most widely used image compression techniques and is particularly well suited to formats like video and photographic images. It is actually based on a combination of Fourier transform techniques and chromatic (colour) sub-sampling (I’ve provided some background reading if you really want to delve deep, here). JPEG can achieve compression ratios of x10 on many types of data without significant degradation in image quality to the human eye. It does this, in part, by discarding high-frequency components of an image that the human eye is generally less sensitive to in the context of something like a photographic image.
The human eye is, however, very sensitive to high-frequency components (sharp edges in an image) in certain circumstances; particularly situations where there is very little low-frequency data to drown out the missing information (i.e. plain backgrounds) and sharp edges and pixel-scale structures which users are very familiar with (e.g. TEXT!). JPEG is fundamentally weakest on images that consist of text on plain backgrounds.
Once you have seen JPEG’d text a few times it becomes fairly easy to spot. My own experience is that it’s frequently the cause of help desk calls complaining about “image quality”, hence it is something system administrators in particular should be aware of; I find it helpful to query such complaints with a sample image and to ask for a similar screen shot from the user.
In the shown image I’ve compressed part of the text on the screen in jpeg (in the green panel) and part pixel perfect in bitmap (the red panel).
An Example of JPEG’d Text
Pure JPEG isn’t great for text, actually most image compression techniques aren’t. Although HDX codecs are often described as “thinwire”, “H.264”, “DCR” many of them contain some extra magic and fairy dust to ensure text and some other things are handled. You can get a very good view of the various graphics modes and encoders available in my colleagues blogs, particularly Fedi’s guide to graphics modes and Amit’s guide to codecs.
JPEG can incorporate a number of compression techniques, some of which are also used by H.264 and other compression techniques. Some of the algorithms that can be used are Chromatic (Colour) Subsampling or another algorithm the discarding of higher Fourier components (small scale structure as described above), read more here. H.264 also often uses chromatic sub-sampling but not the Fourier techniques, in JPEG it is usually the Fourier artefacts that are most prominent around text. So these are what to look for when trying to spot JPEGs. (In a future blog I’ll cover Chromatic sub-sampling and how _pure_ chroma sub-sampling artefacts in H.264 look different to those seen with Fourier-based compression in most JPEG algorithms).
Chroma sub-sampling basically assumes the pixels next to each other are similar so less information is transferred about colour and is inferred. This means it’s good for film like video but again weakest on sharp edges on text on contrasting backgrounds. Its artefacts basically smudge or dim the colour a bit. CAD users are often very sensitive as it makes straight or near-straight lines in applications in Autodesk a bit less sharp. The cone receptors in the human eye are also more sensitive to certain colours so artefacts on text and lines are more noticeable with certain colours, a fact used to an advantage in compression by compressing colours we are least sensitive to higher than those we are (Geeks – read more here)!
When Could I See Significant JPEG Artefacts When Using HDX?
For our mainstream technologies, we certainly wouldn’t be relying on highly-compressed JPEG’d transmission of text. However we do currently have a couple of fall-back mechanisms that currently may use this. These were never envisaged as a transmission mechanism many users would use and are designed to ensure support in some fairly obscure cases where other mechanisms can’t succeed. HDX will always get through, no matter what!
The majority of users should not be using a codec falling back to highly compressed JPEG text compression. Long term we are looking to change our fall back mechanisms so even if a system is misconfigured the user will not end up in a situation where they may be aware of visual artefacts or quality issues. We’ve learned that even though most of these users have better transmission protocols available but perhaps we need to take care of the choice and configuration for them more frequently.
Our adaptive technologies will however adjust JPEG compression levels to deal with lowered bandwidth – this is the most likely circumstance under which a user will become visually aware of JPEG. It is usually a symptom that indicates that there is an underlying network or bandwidth issue.
When am I likely to be Using Codecs Utilising JPEG Compression?
The currently available legacy and compatibility codecs do use JPEG amongst the compression techniques and the level of JPEG compression applied are parameters indirectly controlled when a user sets visual policy modes. The level of compression used can be controlled independently for static and transient (moving images/videos) as the human eye’s sensitivity to compression is very different between the two types of data.
Our H.264 supercodec does not currently use JPEG compression so if you are seeing significant JPEG artefacts and you have an H.264 endpoint you should check you really are using the H.264 codec, even if you are “sure” you are. Some advice on how to do that is here, in this article CTX200370. H.264 can leave visual artefacts but they are visually different and I’ll cover what those look like in a future blog.
True lossless mode does not use compression and hence does not use JPEG compression.
What should I do if I see excessive JPEG artefacts?
- True lossless mode does not use compression, sometimes users seeing JPEG artefacts select lossless as a “solution” when excessive compression appears as a consequence of bandwidth problems, this heavily intensive bandwidth mode is usually not the solution and generally causes more problems by loading a network even further.
- Check your network, the most likely cause is a bandwidth problem
- Check your graphics modes, you need do this on every VDA on a network as a badly behaving VDA can impact on other users (see CTX200370)
- Upgrade your receiver, our newest receivers are designed to be optimal for the server versions available and the most recent receiver is likely to be the best
- Check your visual quality settings, for most users using a VDI desktop and office applications I would expect the default Visual Quality Policy (Medium) to give a good visual experience.
- This overview video displaying the impact of various quality settings on frame rate from Jason Southern at NVIDIA is worth a look and similar benchmarking should help a system administrator set their expectations