Both look almost the same. The difference lies on how you look at it.
BYOID is relying party centric - while TYOID is identity provider centric.
Let me explain this bit more.
If you have an Identity Management system that supports BYOID, that should be able to mediate different heterogeneous identity protocols and standards. To elaborate more on that, you should let people authenticate with their own Facebook credentials (OAuth 2.0), Twitter credentials (OAuth 1.0), Google / Yahoo credentials (OpenID), Salesforce credentials (SAML 2.0) and many more. The overall credential management and mapping cost is at the relying party end.
If you have an Identity Management system that supports TYOID - its identity provider centric - and you need not to rely on the capabilities of the relying party Identity Management system. Say, you got to talk to a partner system that only knows SAML based authentication. The partner service will trust your SAML IdP. When the users from your domain, want to authenticate - they will be redirected to your own IdP. Now, the users can login to the SAML IdP with their Kerberos credentials - and authenticate to the partner service via SAML.
Here, the partner service supported BYOID - by trusting the SAML2 IdP of an out side domain - and at the same time - the local Identity Management system of the out side domain supported TYOID by letting its users authenticate with their own Kerberos credentials. Similarly, it could also let users authenticate with any format of internal credentials or any social login.