Re: Feature requests: use Monitor colour profile, and deleting directories...

Hi,

Greg Troxel wrote:

> I think basic color support would be very nice, and I think it's
> pretty easy.  There are two reason: monitors whose output profile

Yup indeed - lcms does indeed make supporting basic colour management 
very easy, and it's fairly widely deployed now, with GIMP, Cinepaint and 
Scribus all making good use of it.

> isn't sRGB (essentially all of them), and viewing images in profiles
> other than sRGB (probably not as important; people that hard core may
> not be using gqview).  print simulation, etc. is in my view beyond
> gqview's mission - once you're doing that you probably want to start
> gimp on the picture.

I agree that print simulation is outside GQView's remit - but handling 
embedded profiles would be a big win for those with profiled scanners. 
The ability for XSane to embed a scanner profile in a TIFF is all that's 
missing from this workflow - and that would be a very easy addition to make.

> (My view is gqview's mission is to let you look at, sort, move
> etc. images, including in detail and at metadata, in a very efficient
> way, with minimal use of keystrrokes, mouse, and (human) time.  It's
> the best program I've found for this use.)

Agreed in every respect :)

> When using a profile for my Thinkpad T30, I found color and tone
> rendition were much more accurate.  The profile was made using Gretag
> Macbeth Eye-One Match with a spectrophotomer, but often monitors come
> with profiles and it's often feasible to borrow color management sw/hw.

Yeah, laptop TFTs are probably the ones that vary most wildly from sRGB 
- the difference on my ancient Dell CPx's screen is phenomenal!

> I'll sketch out what I think are incremental steps:

<snip>

> Starting on (1) is on my copious spare time todo list, but I've been
> low on that lately.

Everything you've mentioned there is already implemented in the patch 
John pointed me to last night, apart from automatically fetching the 
display profile from the X server.  I'm not sure whether there's 
provision for this in X or not - or how mature it is, if present.

Anyway, I've just fixed a bug and replaced my updated patch with a new 
version - if anyone's looked at it, please download it again...

The problem was that the code was transforming the whole image in one 
lump - but you can't guarantee that the rows of a pixbuf will be 
immediately contiguous in memory - the rowstride, and bytes-per-pixel * 
width aren't necessarily the same.  So with the new version of the 
patch, the image is transformed one row at a time.

The new version can be found at the same URL - 
http://www.blackfiveservices.co.uk/gqview-2_1_4-cm.patch.gz

All the best,
--
Alastair M. Robinson



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV