kCIInputImageKey – input image. Majority of the CIFIlters have that input since after all they are meant to be used for processing images.

kCIInputExtentKey – the rectangular portion of the input image to be processed by the filter.

"inputCount" – the number of colors to produce (the K). Maximum allowed number is 128. 0 is legal but produces empty output.

"inputPasses" – number of iterations that the algorithm should run before producing output. The bigger the number the longer it runs and the more representative the resulting colors will be (generally). While 0 seems to be a legal number you’ll get some garbage out. The maximum is 20.

"inputMeans" – you have an option of providing your own colors as a starting point for the algorithm. Normally you don’t need to do it – the algorithm is smart enough to figure it out on its own. Moreover, with enough iterations the algorithm will converge on more or less the same colors regardless of its starting point. You can see it for yourself by picking colors of your choosing in the app. But who knows, maybe there are some special cases where it can be useful.

You provide the colors as an CIImage, 1 pixel high and K pixels long, where color of each pixels represents one of the colors you want to provide as a seed. The output will contain exactly the same number of colors, e.i. the dimensions of the output palette image will be exactly the same as the dimensions of that color image. Another way to think of it is to say that the filter will output the modified version of that image by replacing the color of every pixel with one of the colors it computed.

Ignore the documentation where it says that the colors can be passed “either as an image or an array of colors”. In my experimentation the CIImage was the only acceptable way to package the colors for this input.

This input is mutually exclusive with the inputCount and takes precedence – as long as you provide an image at this input the inputCount will be ignored.

"inputPerceptual" – we can only guess what this input means given total lack of documentation other than the description we can retrieve from the input’s info dictionary. Verbatim it says

“Specifies whether the k-means palette should be computed in the perceptual color space”.

Most likely when computing in perceptual color space the filter uses lightness, chroma, and hue values of the colors versus the RGB components as the basis for clustering.

Another possible (though not necessarily mutually exclusive) explanation is that when in perceptual color space the sizes of the clusters are made larger towards the brighter end of the gamut, taking into account how human eye perceives colors (you can read more about it here or just google for Perceptual Uniform Color Space or Gamma Correction). Specifically, we humans can discern more shades of darker colors than the brighter colors, so to speak, therefore the brighter colors convey less information to the human eye and can be lumped together into larger clusters. Still not clear why would you want to do that given that normally the CoreImage converts images to the linear RGB color space under the hood before they enter any CIFilter.

You can experiment by toggling this input on or off in the FilterMagic app – the colors will come out different, lighter overall and more washed out when the switch is set to YES.