Understanding Encryption length calculation and rounds
Computers operate on bits and bytes internally. They do not operate on (hexadecimal) characters. Characters are for human consumption.

Hexadecimals use only 4 bits out of a possible 8 in each byte, assuming 8 bit ASCII or compatible encoding. To perform any calculation such as bit shifting, addition or modular multiplication, you'd first have to convert the characters to bits. So that's not something you would perform internally to your hash function. Only if you want to make your output compatible for human readable text do you need to convert to hexadecimals (or base 64 or any other encoding of binary in text).

A color consists of 3 bytes in the common RGB scheme. That they are represented as three concatenated hexadecimal bytes is again only for human consumption. If you look at the contents of a bitmap file (.bmp) then certainly the dots / pixels are not present as hexadecimal characters. They are bits and bytes.



A block cipher and secure hash (not password hash) uses a certain number of rounds to be secure. How many rounds depends on the complexity of the inner function; some algorithms have a lot of simple rounds and some have fewer complex rounds. You probably want to have at least some 30% of headroom against the best known attacks to your function (i.e. if 7 out of 10 rounds are broken then you'd consider your function secure, if 9 out of 10 are broken then you're living too close to the knife's edge).

Yes, the number of iterations is similar to the number of rounds in functionality. However, commonly each iteration in a password hash would already create a secure result if the input password has enough entropy. That is, you would at least not be able to reverse the function and gain information about the input. Instead, the number of iterations should be as large as possible so that an adversary has to perform a lot of work (the work factor) to brute force a large amount of password hashes.