[vdr] [PATCH] DXR3 better color management

Husterer, Thomas RD-CP1 Thomas.Husterer at heidelberg.com
Thu Apr 21 17:32:17 CEST 2005


like Luca Olivetti a week ago, I fixed the bug in the colormanager which caused
the color bleeding effekt.

Unfortunately I could not compare my changes to them of Luca Olivetti because the diff-files are not stored in the mailing-archive and i was not subscribed to this mailinglist at that time.

My changes should not change too much the original performance.
I fixed the behaviour of the color-index optimization by introduction of
A maximal x-koordinate to which this color-index is valid.
This ensures that no section regions are crossed.
To improve performance I removed the final memcopy which copied a help-buffer into the destination buffer.

After this fix I recognized that the last region was not closed and therefore the last color-index table was not sent to the spu. This resulted in a small
bad colored rectangle in the lower right corner of the channels-menu.
This is fixed by a closeRegion() at the end.

A small change in osd.c ensures that the default color of an empty bitmap
results in a well defined transparent color. Before that change i recognized to different colorindices for the transparent color.

At least I changed the color-to-section-map-algorithm.
The algorithm before had a problem with diagonal edged shapes like the charactar ´A´.
This edges could lead to a consumption of many regions with very flat sections because the sectionlimits move to the left from each line to another.
My changement uses in the first line of a Region only 3 colors for one section instead of 4. This leads to more sections in horizontal direction but it gives a chance to other colors in sequential lines.
This leads to more quadratic sections because the width decreases and the height increases.

Does anybody know how these changes can be merged into the cvs-archive of the dxr3-plugin?
(my original version is a nearly HEAD version of the cvs-archive)
Or is there any other usage for this patch?
What is with the change to osd.c? Is this necessary or am I wrong with my observation?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdr-dxr3-osd-bleed.diff
Type: application/octet-stream
Size: 5357 bytes
Desc: vdr-dxr3-osd-bleed.diff
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20050421/3d4f99f9/vdr-dxr3-osd-bleed.obj

More information about the vdr mailing list