How does converting character set affect hash entropy? Does mapping a large character-set hash onto a small character-set hash lower entropy for a fixed size substring?

I'm writing a python app that involves generating passwords for websites. During the application I want to convert hexidecimal hashes to alphanumeric strings, and take the first twenty characters of the output. I want to convert to alphanumeric, because most websites at least support the upper-lower alphanumeric character set.

I surjectively map the larger character set of hexadecimal bytes $\{00...\text{ff}\}$ onto the smaller set of upper and lowercase alphanumerics $\{a...z, A...Z, 0...9\}$.

The mapping is done by recycling the 62 alphanumeric elements cyclically to correspond to each element of the 256 bytes

$$00 \rightarrow a$$
$$01 \rightarrow b$$
$$\vdots$$
$$0e \rightarrow 9$$
$$0f \rightarrow a$$
$$\vdots$$

For example, if the world's most secure password - "password" - is sha512 digested as hexadecimal it is unsurprisingly - $128 \times log_2(16) = 512$ bits.

$$
\text{b109f3bbbc244eb82441917ed06d618}\\
\text{b9008dd09b3befd1b5e07394c706a8b}\\
\text{b980b1d7785e5976ec049b46df5f1326}\\
\text{af5a2ea6d103fd07c95385ffab0cacbc}\\
86\\
$$

Since each pair of hex-digits is mapped onto one alphanumeric digit, I assume the entropy of the resultant alphanumeric string is $64 \times log_2(62) = 382.5459$ bits.

$$\text{1j5bcKq8KdvcwVJpuiJj3efBGh5oYSp}\\\text{9
e1D6GB4YeFiLHtMZCUQxdfhpvjhVmWck}\\$$

The new string has half the length but ~75% of the entropy of the original string, so there is more per-character entropy in the alphanumeric projection,
making 

$$\text{1j5bcKq8Kd}$$

a better password than

$$\text{b109f3bbbc}$$

Have I made any invalid assumptions, or done the math incorrectly? Any insights into whether or not this surjective mapping is a good idea would be appreciated.
If any clarification or edits are needed I'd be happy to make them - please leave a comment below.
In general, if a function $f$ has collisions, then it may reduce entropy: $$H[f(X)] \leq H[X].$$  The inequality applies to any notion of entropy—min-entropy, Shannon entropy, Hartley entropy, Rényi entropy, etc.  This happens because if $f(x_i) = f(x_j)$ for $x_i \ne x_j$, the probability masses $\Pr[X = x_i]$ and $\Pr[X = x_j]$ both contribute toward the probability mass $\Pr[f(X) = y]$ where $y$ is the common value of $f(x_i)$ and $f(x_j)$.  In particular, the min-entropy is $$-\log_2 \max_y \sum_{x \in f^{-1}(y)} \Pr[X = x].$$  Here the outputs with the most colliding inputs are $\{\mathtt a, \mathtt b, \mathtt c, \mathtt d, \mathtt e, \mathtt f, \mathtt g, \mathtt h\}$, each having five distinct inputs ($f^{-1}(\mathtt a) = \{0,62,124,186,248\}$, etc.), so in the best case, if $X \in \{0,1,2,\dots,255\}$ has uniform distribution, the min-entropy of $f(X)$ is $-\log_2 5/256 \approx 5.678$.  For a string of independent inputs $X_1 \mathbin\| X_2 \mathbin\| \cdots \mathbin\| X_n$, the concatenation $f(X_1) \mathbin\| f(X_2) \mathbin\| \cdots \mathbin\| f(X_n)$ has min-entropy about $5.678n$.  Thus a 64-character string from this will have at most about 363 bits of min-entropy.

Note that this is a bit less than a uniform random string from the same alphabet, which has $\log_2 62$ bits of entropy per character, or about $5.954n$ bits of entropy in a string of $n$ independent characters, which for a 64-character string gives about 384 bits of min-entropy as you calculated.



There are other ways to do roughly what you're doing:


Use base64.  This is an injective map from octet strings to strings of $\{\mathtt a, \mathtt b, \mathtt c, \dots, \mathtt z, \mathtt A, \mathtt B, \mathtt C, \dots, \mathtt Z, \mathtt0, \mathtt1, \mathtt2, \dots, \mathtt9, \mathtt+, \mathtt/\}$ with optional padding.  Of course, you can change the exact character set if need be to comply with mandatory and forbidden special characters.
Use rejection sampling.  From the infinite stream $\operatorname{SHA512}(k \mathbin\| 0) \mathbin\| \operatorname{SHA512}(k \mathbin\| 1) \mathbin\| \operatorname{SHA512}(k \mathbin\| 2) \mathbin\| \dots$, take the acceptable octets (which encode, say, graphic US-ASCII characters) and reject the unacceptable ones until you have a password as long as you want.