summaryrefslogtreecommitdiff
path: root/src/xine-utils/color.c
AgeCommit message (Collapse)Author
2014-06-06Copyright year update by hg log.Torsten Jager
2014-05-30rgb2yuy2 update.Torsten Jager
* palette color count guard. * add 4, 2, 1 bit palette support. * use default gray on NULL palette. * optional xine clut_t output.
2014-03-11Fix a short zero-init.Darren Salt
2013-09-13Copyright year update by hg log infoTorsten Jager
script execution time: 55"
2013-01-21rgb2yuy2: added 16/15/8 bit formatsTorsten Jager
2012-12-05color.c: direct rgb->yuy2 converterTorsten Jager
2012-10-07yuv444_to_yuy2_mmx: follow target UV pitchTorsten Jager
2012-05-28Added yv12_to_yuy2_sse2()Petri Hintukainen
2012-05-23Added missing #include "config.h" to make ATTR_ALIGN workPetri Hintukainen
2012-04-11Marked data const and fixed typePetri Hintukainen
2012-04-11Added MMXEXT version of yv12_to_yuy2()Roland Scheidegger
2012-04-11Removed incorrect .align directives from asm codePetri Hintukainen
2012-04-11MMX version of yv12_to_yuy2()Roland Scheidegger
2012-04-10yv12_to_yuy2: use the same macros for both odd and even linesRoland Scheidegger
(as a simple argument swap is all that's needed).
2012-02-15Merge from 1.1.Darren Salt
--HG-- rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
2012-02-15Improved RGB→YUV conversion v2 (use MPEG range instead of full range)Darren Salt
Video-out plugins expect MPEG range Y'CbCr data (Y'=16..235, Cb,Cr=16..240). RGB sources (still images and audio visualisation effects) need to be converted first. This patch fixes up the range calculations and corrects an off-by-one in the range for Cb and Cr over commit 68fcd69fb3b6 (which was reverted due to API change). It should also provide a little more accuracy: I've gone back to the source (http://www.itu.int/rec/R-REC-BT.601/) for the conversion information. (We should use float or double here, but that would be an ABI change.)
2012-02-14Backed out RGB→YUV patch – API change.Darren Salt
Anything which uses the COMPUTE_* macros would need to be recompiled because of the use of new tables. This change needs to be conditional somehow, at least externally.
2012-02-14Merge from 1.1Petri Hintukainen
--HG-- rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
2012-02-14Improved RGB->YUV conversion (use mpeg range instead of full range)Torsten Jager
Video out plugins expect mpeg range yuv data (y=16..235, uv=16..239). RGB sources (still images and audio visualisation effects) need to be converted first.
2011-12-31Merge from 1.1.Darren Salt
2011-12-22Use proper chroma upsampling for yv12 to yuy2 conversionRoland Scheidegger
The old code did some "averaging" which, while cheap, lead to serious chroma shift because the weighting factors turned out to be pretty random (arguably no averaging likely would have been given more correct results). It also in fact lead to chroma ghosts. To see why this was wrong read the following and then do the math. http://www.hometheaterhifi.com/the-dvd-benchmark/179-the-chroma-upsampling-error-and-the-420-interlaced-chroma-problem.html http://avisynth.org/mediawiki/Sampling As an example, let's look what happens at line 4 for interlaced content (where the code would have averaged chroma from chroma line 2 and 4): Chroma line 2 contains chroma values for line 2 (25%) and 4 (75%) while chroma line 4 contains chroma values for line 6 (25%) and 8 (75%) of the original (prior to subsampling) frame. Average these together and you get something quite wrong. Most importantly the center of these weights will be at 5.5 instead of 4 (hence chroma shift). For odd lines it is different (better but still wrong). So, fix this by using the correct weights for reconstruction of the chroma values (which is averaging for the progressive case for all pixels since the samples are defined to be between the lines, and use different weighting factors for odd/even/"upper"/"lower" lines). This runs more than twice the instructions (for the mmx case), but I measured only a performance impact of roughly 5% (on a Athlon64 X2) - seriously bound by memory access (by comparison the sort-of-pointless post-deinterlace chroma filter is nearly twice as slow hence if you don't need it because the values are correct this will be a lot faster). Note: this is only correct for codecs which use the same chroma positions as mpeg2 (dv is definitely different, mpeg1 is also different but only for horizontal positioning, which doesn't matter here). "yv12" as such seems underspecified wrt chroma positioning. On another note, while this algorithm may be correct, it is inherently suboptimal doing this pre-deinterlace (and a post-deinterlace chroma filter is not going to help much neither except it can blur the mess). This NEEDS to be part of deinterlace (which btw would also be quite a bit faster when handling planar directly due to saving one pass of going through all memory). The reason is while line 4 will now use the correct weighting factors, the fact remains it will use chroma values originating from lines 2, 4, 6 and 8 of the original image. However, if the deinterlacer decides to weave because there is no motion, it CAN and most likely wants to use chroma values from the other field (hence values originating from line 2, 3, 4, 5 in this case when using a very simple filter, with appropriate weighting). --HG-- branch : point-release extra : rebase_source : 808bb5785ca398970324bea6b391a9e24c576d2f
2009-11-30Trim trailing space & reduce space+tab.Darren Salt
2009-01-15Prepare for xine_mmx.h.Darren Salt
2009-11-30Trim trailing space & reduce space+tab.Darren Salt
2008-07-17Merge from 1.1.Darren Salt
--HG-- rename : src/xine-engine/buffer.h => include/xine/buffer.h rename : src/demuxers/demux_nsf.c => src/combined/nsf_demuxer.c rename : src/demuxers/demux_ogg.c => src/combined/xine_ogg_demuxer.c rename : src/libspucmml/xine_cmml_decoder.c => src/spu_dec/cmml_decoder.c rename : src/libspudec/xine_spu_decoder.c => src/spu_dec/spu_decoder.c rename : src/libspudvb/xine_spudvb_decoder.c => src/spu_dec/spudvb_decoder.c rename : src/libsputext/xine_sputext_decoder.c => src/spu_dec/sputext_decoder.c rename : src/libsputext/demux_sputext.c => src/spu_dec/sputext_demuxer.c
2008-07-04Use calloc to allocate the memory area for the YUV planes.Diego 'Flameeyes' Pettenò
--HG-- extra : transplant_source : %00%23%8FM%AA%B88C%FEA%7E%2C%D3%F5%29%8F%28%AC%D7_
2007-12-19Update all the code to the new headers layout.Diego 'Flameeyes' Pettenò
2007-11-10Delete most of the CVS $Id$/$Log$ lines.Darren Salt
--HG-- extra : transplant_source : %E0%D0%C5%8B%BEU%DD%24%5D7%1F%ADV%AD%EB%23%CBU%80%EB
2007-11-09Update FSF address on non-contributed code and COPYING files.Diego 'Flameeyes' Pettenò
For contributed code, leave whatever the version we last synced for is using to make simpler future syncs.
2006-07-17- avoid crashes when init_yuv_planes has one of its allocations failingBastien Nocera
See http://bugzilla.gnome.org/show_bug.cgi?id=338833 CVS patchset: 8135 CVS date: 2006/07/17 18:31:24
2006-06-20Fix generic warnings.Diego 'Flameeyes' Pettenò
CVS patchset: 8063 CVS date: 2006/06/20 00:35:07
2006-02-14Make input-only pointers point to const data.Darren Salt
CVS patchset: 7900 CVS date: 2006/02/14 19:12:16
2005-07-03warning fixMiguel Freitas
CVS patchset: 7636 CVS date: 2005/07/03 20:22:10
2005-05-07*BUGFIX*František Dvořák
gcc4 patches from Dams Nadé (livna.org) and Keenan Pepper. CVS patchset: 7527 CVS date: 2005/05/07 09:11:37
2005-01-23**BUGFIX**James Stembridge
Fix cropping and zooming CVS patchset: 7367 CVS date: 2005/01/23 23:01:12
2003-12-09update copyright year (and we have to do it again in 3 weeks... ;-) )Daniel Caujolle-Bert
CVS patchset: 5879 CVS date: 2003/12/09 00:02:28
2003-09-16Removed headers that were serving no adding anything necessary to the build.Stephen Torri
CVS patchset: 5389 CVS date: 2003/09/16 02:03:16
2003-08-25AMD64 support patch by Adrian SchroeterMichael Roitzsch
CVS patchset: 5308 CVS date: 2003/08/25 14:32:37
2003-07-27- removed xine-engine/locale.c as it is unused, fix static functions in theBastien Nocera
engine and the utils, removed unused variables CVS patchset: 5219 CVS date: 2003/07/27 12:47:23
2003-07-12add yv12_to_yuy2_mmxextMiguel Freitas
CVS patchset: 5148 CVS date: 2003/07/12 04:34:39
2003-07-12add yuy2_to_yv12 conversionMiguel Freitas
CVS patchset: 5146 CVS date: 2003/07/12 03:10:15
2003-06-22implement simple interpolation for 4:2:0 -> 4:2:2 upsamplingMiguel Freitas
use mmxext non-temporal hints and pavgb CVS patchset: 5086 CVS date: 2003/06/22 15:03:43
2003-06-03progressive_frame flag may be used to select how to convert yv12->yuy2Miguel Freitas
CVS patchset: 5003 CVS date: 2003/06/03 03:33:15
2003-06-02that should fix compilation problems with some gcc / cflags combinationMiguel Freitas
CVS patchset: 4996 CVS date: 2003/06/02 00:03:58
2003-05-31provide yv12 to yuy2 conversionMiguel Freitas
CVS patchset: 4993 CVS date: 2003/05/31 13:54:27
2003-02-02added YUV411P -> YV12 converterMike Melanson
CVS patchset: 4083 CVS date: 2003/02/02 06:07:20
2003-01-01revert to old (and apparently much more reliable) transfer methodMike Melanson
CVS patchset: 3744 CVS date: 2003/01/01 19:32:28
2002-12-22fix MMX color converter when width is divisible by 6Mike Melanson
CVS patchset: 3638 CVS date: 2002/12/22 23:20:21
2002-12-04modified YUV9 -> YV12 converterMike Melanson
CVS patchset: 3423 CVS date: 2002/12/04 05:33:40
2002-12-01added generalized YUV9 -> YV12 conversion functionMike Melanson
CVS patchset: 3396 CVS date: 2002/12/01 07:12:41
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-24 03:15:15 +0000