On Sun, Jan 17, 2016 at 02:12:53AM +0100, [email protected] wrote: > commit 3bc6c69ae8ff25377848b76a25494aa4a0055544 > Author: FRIGN <[email protected]> > AuthorDate: Sun Jan 17 01:39:36 2016 +0100 > Commit: FRIGN <[email protected]> > CommitDate: Sun Jan 17 02:11:54 2016 +0100 > > Mandate "ProPhoto RGB" color space for farbfeld and handle ICC profiles > > I've literally been thinking about this for quite a while now. The > initial motivation behind defaulting to sRGB was the idea that most data > on the web was in sRGB anyway. > However, my assumption was weakened in the sense that the development > is clearly moving towards images with supplied ICC profiles and software > slowly catching up to handle this. My tests have shown that more and > more people even do that on the web, even though it's been a "tradition" > that Photoshop users "Save for Web" and convert the gamut lossy into > sRGB to bring a consistent color-"experience" even to those clients not > supporting ICC profiles and which always assume sRGB. > > What made this decision so difficult is that converting to "ProPhoto > RGB" requires some advanced knowledge on this topic, however, I came to > the conclusion to implement it given the *2ff- and ff2*-tools handle it > silently and well in the background, and given the little cms library is > actually quite okay to use. > When converting from ff to png, a proper "Pro Photo RGB" ICC V4-profile is > automatically included in the exported png by ff2png. V4 is not as > widespread as V2, but in the worst case (no V4 support somewhere) the > colors will just be a little off. > > As an added bonus, any input files for png2ff which include ICC profiles > are also correctly handled and the color space conversions are executed > as expected. > > Accordingly, the FORMAT-specification has been changed. While at it, > I added the note on alpha-multiplication. Now the format is very exact > and shouldn't leave any ambiguities. > > jpeg supports ICC profiles as well, but I hadn't had the chance to look > into it (not as trivial as PNG probably, help appreciated :)), so I'm > always assuming sRGB here. > > Rationale > --------- > It is not obvious why one would go through the lenghts of supporting > this big-gamut colorspace and not just stick with sRGB. In 99% of the > cases, there's no reason to do that, but with even more extreme > developments in the OLED-sector and other advances display hardware is > slowly getting more powerful than sRGB, asking for color information > which is suitable for the task and actually uses the full potential. > The decision in this regard was not difficult in farbfeld because we > always use 16-Bit anyway and won't have to fear posterization in a big- > gamut color-space.
Commit message reads like a diary.
