Talk:Transform coding

Latest comment: 10 months ago by 130.75.173.142 in topic compression?

compression?

edit

Hi folks,

Transform-coding is not a type of compression, but used by compression. Nearly all transformations used by compression-methods are reversible. The lossy compression is a result of the quantisation-process which follows the transformation. Maybe someone could point that out. -- ThePacker 01:10, 4 February 2006 (UTC)Reply

I would argue that the term "Transform-coding" implies the application of a transform in the context of signal coding, which usually means source coding, i.e., data compression. So I would say that, yes, tranform-coding is a term describing a class of compression algorithms, namely those centered around the application of transforms to achieve (most of the time) signal decorrelation. 130.75.173.142 (talk) 15:06, 16 December 2023 (UTC)Reply

It seems that you know enough on that subject to point that out yourself? I am doing a report on "Transform-based Image Coding", so I am interested in any changes that can occured on this page. Also I think your definition is right thus you should change it with your words. It would be a good improvement. -- -M-ric 07:02, 4 May 2006 (UTC)Reply

IMHO, it does qualify as a lossy compression technique. --206.79.158.100 23:04, 14 September 2007 (UTC)Reply


hi guys,

Is JPEG uses discrete cosine transform or discrete wavelet transform? in the article [wavelet compression], it was mentioned that JPEG uses discrete wavelet transform. as i am not clear about this i didnt change the content. please check. —Preceding unsigned comment added by 61.95.205.43 (talk) 04:42, 19 December 2007 (UTC)Reply

---

Hi, Transform encoding doesn't compress data in itself, however it is used by compression techniques to change the format of the data into a form which would allow greater compression to be achieved. In theory transform encoding isn't lossy, however in practice it is often lossy due to rounding errors and approximations (fixed point arithmetic), any loss occurred is unintentional. The human eye is less responsive to high frequency components and so less data needs to be encoding for these. This idea is employed in the JPEG scheme, the discrete cosine transform transforms the data into the frequency domain which is then quantised. At the quantisation stage less detail is assigned for the higher frequency components. This is where the compression occurs, not at the transform stage. (Charlieds55 (talk) 14:11, 30 October 2010 (UTC))Reply

pixels per line?

edit

Um. "The average TV displays the equivalent of 350 pixels on a line, but the TV signal contains enough information for only about 50 pixels of blue and perhaps 150 of red. This is not apparent to the viewer in most cases, as the eye has sophisticated systems for "re-building" a sharp image based on clues from contrast and edges." I don't think the number of pixels is reduced at all- rather it's the range of color in a pixel that is reduced. --206.79.158.100 22:49, 14 September 2007 (UTC)Reply

Yes, the TV signal can produce the full range of color. Each of the red, blue, green guns (in a CRT television) fires the "full range of color". For example, a TV broadcast often displays (close to) black in one region and white in another region, so the range of color is the full range from black to white -- from red, green, blue "all off" to red, green, blue "full on".
I can see how there can be confusion between the number of physical pixels on, say, a LCD television or a Bayer filter, which is fixed in hardware, and the number of "effective pixels" in the broadcast TV signal.
Those "effective pixels" are exact numbers in digital TV -- chroma subsampling.
It is a bit subjective how many "effective pixels" there are in analog PAL or NTSC signal, since "there are no pixels in analog TV", but perhaps "about 50 pixels of blue" is an adequate oversimplified explanation for this transform coding article; we can leave the details to the analog television article and its sub-articles. --68.0.124.33 (talk) 15:08, 15 October 2009 (UTC)Reply