Bug 96971 - [patch] graphics/xv incorrectly handles xwd files
Summary: [patch] graphics/xv incorrectly handles xwd files
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Emanuel Haupt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-08 09:30 UTC by Peter Jeremy
Modified: 2006-07-14 16:32 UTC (History)
1 user (show)

See Also:


Attachments
file.diff (3.52 KB, patch)
2006-05-08 09:30 UTC, Peter Jeremy
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Jeremy 2006-05-08 09:30:08 UTC
	With 24/32-bit xwd files, xv swaps the red and blue channels.
	With 16-bit xwd files, the image is very dark green (almost black).

	Both problems are caused by hard-coding the channel order and
	offsets, rather than using the colour masks in the xwd header.

	xv reads the input into a 24-bit internal image, which is then
	displayed.  The lack of brightness in the 16-bit display is
	because the colour values are copied into the low-order bits of
	the internal pixmap rather than the high order bits.  The green
	hue is because the green channel has 6 bits, whereas red and
	blue only have 5 bits, making the green twice as (relatively)
	bright.
	
	Thanks to Callum Gibson for initial pointers to the bug as well
	as 16-bit dumps.

Fix: The following patch replaces the byte-swap routines as well - I
	initially suspected that the problem was at least partially
	caused by the non-portability of "union cheat".  Whilst that was
	not a problem, the resultant code is cleaner and I did not want
	to expend further effort removing the change.

	Rather than hard-coding the shift values (and the mask for 24-bit
	colour), the shift value is calculated from the mask during
	initialisation.  Since the low colour bits must be shifted left
	whilst all other shifts are right, each pixel colour is shifted
	so the MSB of the colour is in bit 31 and then shifted right 24
	bits to correctly locate the colour in an 8-bit field.
	
How-To-Repeat: 	Do a window or screen dump using xwd from a 24/32-bit TrueColor
	display.  Display the screen dump using xv.

	Do a window or screen dump using xwd from a 16-bit TrueColor
	display.  Display the screen dump using xv.
Comment 1 Edwin Groothuis freebsd_committer 2006-05-08 09:32:09 UTC
State Changed
From-To: open->feedback

Awaiting maintainers feedback
Comment 2 Ion-Mihai "IOnut" Tetcu freebsd_committer 2006-06-17 22:20:45 UTC
State Changed
From-To: feedback->open

Maintainer timeout
Comment 3 Emanuel Haupt freebsd_committer 2006-07-07 00:13:57 UTC
Responsible Changed
From-To: freebsd-ports-bugs->ehaupt

Take.
Comment 4 Emanuel Haupt freebsd_committer 2006-07-07 00:59:19 UTC
State Changed
From-To: open->feedback

Thank you for your patch. The patch unfortunately breaks the port on 4.x [1]. 
Do you think you could fix it? 

[1] http://people.freebsd.org/~ehaupt/snippets/96971/xv-3.10a_6.log
Comment 5 Emanuel Haupt freebsd_committer 2006-07-14 16:32:13 UTC
State Changed
From-To: feedback->closed

Committed, thanks!