PBKDF2-HMAC-SHA-256
number of iterations desired = 1024
length of the salt in bytes = 16
length of the derived key in bytes = 4096
Ok - PBKDF2-HMAC-SHA-256 is a solid choice, though if you're running on any modern 64-bit CPU, I would strongly recommend PBKDF2-HMAC-SHA-512 instead, because SHA-512 requires 64-bit operations that reduce the margin of a GPU based attacker's advantage, since modern GPU's don't do 64-bit as well.
16 bytes of salt is fine, as long as it is cryptographically random and is unique per password.
4096 bytes of output is ACTIVELY BAD! SHA-256 has a native output size of 32 bytes. PBKDF2/RFC2898 states that in this case, you'll first to 1024 iterations to get the first 32 bytes, then another 1024 iterations for the next 32 bytes, and so on for 128 times in total.
So, you did 131072 iterations total, and got 4096 bytes of output. The attacker is going to do 1024 iterations total, and compare their 32 bytes of output to the first 32 bytes of your output - if those are the same, they guessed correctly! You just gave every attacker a 128:1 advantage!
Instead, if you're happy with the speed, you should do 131072 iterations with 32 bytes of output - you will spend the SAME amount of time you are now (so it's free!), and your attackers will need to spend 128 times more time than they do now!
Never get more output for password hashing than the native output of your hash function, i.e. 20 bytes for SHA-1, 32 for SHA-256, 64 for SHA-512. You can optionally store less, but it doesn't save you any computations. I would recommend storing at least 28 bytes of output (224 bits, which is twice 112 bits, the nominal security of 3DES).
Note that output length values are pure binary output - BEFORE you BASE64 or hexify them, if you do (personally, I'd store the raw binary - it uses less space, and requires one less conversion).