[argyllcms] apt upgrade and BT.2020 volume calculation
- From: "Bergquist Johan" <johan@xxxxxx>
- To: <argyllcms@xxxxxxxxxxxxx>
- Date: Mon, 15 Apr 2019 11:32:30 +0900
or don't wait for the distro's to catch up, and download the binaries from <
<http://www.argyllcms.com/downloadlinux.html>
http://www.argyllcms.com/downloadlinux.html>.
Thanks for the link. It worked like charm although I'm struggling to get bash
scripts to recognise the path in my .bashrc file.
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>
https://github.com/saucecontrol/Compact-ICC-Profiles.
Or use the one that ArgyllCMS provides in ref/Rec2020.icm
An issue is that the white point of Rec2020 isn’t D50. I suppose that the
measured XYZ values are Bradford-transformed to D50 in the icm and gam-file
creation before calculating the volume.
I guess a workaround could be to make a fake measurement with the Rec2020.icm
and create icm and gam files from that measurement. Or should I set the default
rendering intent in colprof to something other than absolute colorimetric?
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" ]
If there is any criterion on the allowed amount of concavity, please let me
know.
Two more questions:
1. How does the surface resolution in the gam-file generation (-d
parameter in iccgamut) affect the volume/intersection calculation?
2. Intuitively, the quality of an ICC profile should become higher for a
larger number of patches. If quality is measured by the peak, average, and RMS
errors, however, I get a higher quality with fewer (evenly distributed) patches
only on the surface compared to a larger number of patches distributed evenly
across the entire RGB space. If the objective is to just calculate the
volume/intersection, is there any advantage of including patches that are not
on the surface?
Thanks,
Johan
Other related posts:
