[argyllcms] Re: apt upgrade and BT.2020 volume calculation
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sat, 13 Apr 2019 13:03:44 +1000
Bergquist Johan wrote:
Hi,
I haven’t yet upgraded to v2.1 but I’m very pleased to see that it now also contains RGB
cube surface patch generation. I tried to upgrade via apt-get upgrade but it’s not yet
available in the Ubuntu standard repository (I could install v2.0.0 with apt-get install,
though). Any idea when it becomes available or is there another apt repository?
or don't wait for the distro's to catch up, and download the binaries from
<
http://www.argyllcms.com/downloadlinux.html>.
I need to calculate the overlap with BT.2020 so I first run the command iccgamut -v -n -d
50 2020.icc, where 2020.icc is the “magic” ICCv2 profile downloaded from
https://github.com/saucecontrol/Compact-ICC-Profiles.
Or use the one that ArgyllCMS provides in ref/Rec2020.icm
The volume I get with iccgamut is
2,042,183 CIELab units but it differs significantly from calculations performed with other
packages, for example ColorThink v3.0.5 (1,803,050). The volume of an official v4 2020.icc
(shipped with MacOS) calculated by ColorThink is 1,831,880.
Any ideas on why iccgamut gives a different volume?
Intent may make a slight difference since it scales around 0,0,0 (i.e. absolute vs.
relative colorimetric).
Otherwise it will probably be about the surface algorithm. The iccgamut
algorithm is
general but not perfectly precise (i.e. it copes with non-monotonic and
inter-pentrating
surfaces, the latter being quite common in CMYK devices).
I also that profiling some laser displays cannot use CIELab PCS so it is necessary to
switch PCS to XYZ. Is the volume calculation then still performed in CIELab?
Yes. (Unless of course you select J*a*b*)
Does the “segmented maximum algorithm” handle concave hulls? Some other volume calculation
algorithms such as those based on Delaunay triangulation do not.
It does within limits. Deeply concave won't be tracked perfectly.
[ All general concave capable surface algorithms have some sort of fudge factor
to
set a threshold between surface and concavity. I actually have a much more
precise
cLUT gamut hull algorithm embedded in the profile inversion code that uses
the cLUT
cell structure, but I haven't put the hooks in to allow it to be used to
generate
a .gam file. It isn't foolproof though either. It seems a difficult problem to
efficiently decide if a cell triangle is "inside" or "outside" ]
Cheers,
Graeme Gill.
Other related posts:
