It seems that:
- there is a bug in generate_params
- the metrics calculation is wrong in evaluate_transform
- we don't take into account the type of transformation for their calcultations.
See the comments from the analysis made with Claude Haiku (which I agree with)
Regardons la fonction evaluate_transform en détail. Je vois plusieurs problèmes critiques:
1. Incohérence fondamentale: paramètres vs. transformations appliquées
Dans generate_params(), vous générez des vecteurs de 8 éléments avec du padding zéro selon le type de transformation:
- TRANSLATION: [tx, ty, 0, 0, 0, 0, 0, 0]
- EUCLIDEAN: [tx, ty, rotation, 0, 0, 0, 0, 0]
- HOMOGRAPHY: [tx, ty, scale₀, shear_x, shear_y, scale₁, homog_x, homog_y]
Mais dans prepare_datasets(), ces vecteurs p sont passés directement à affine_transform(). Le problème: affine_transform() de TensorFlow/Keras attend typiquement une matrice de transformation 3×3 (ou 4×4 en 3D). Comment vos vecteurs de 8 éléments sont-ils convertis en matrice?
Je ne vois pas cette conversion dans le code. Cela signifie que soit:
- Les transformations appliquées aux images ne correspondent pas à vos paramètres
p générés
- Ou il y a une conversion cachée que je ne vois pas
2. Le calcul des métriques inclut du padding inutile
params_pred = tf.reshape(p_pred, [-1])
true_params = single_params[:params_pred.shape[0]]
mse = np.mean((params_pred.numpy() - true_params)**2)
Vous comparez MSE/MAE sur les 8 éléments complets, y compris les zéros du padding! Par exemple:
- Une TRANSLATION produit [tx, ty, 0, 0, 0, 0, 0, 0]
- Si le modèle prédit aussi [tx_pred, ty_pred, 0, 0, 0, 0, 0, 0]
- La MSE inclut (0 - 0)² six fois !
Critique: Vous devriez comparer uniquement les paramètres pertinents selon le type de transformation.
3. Pas de validation du mapping paramètres ↔ transformation
Les paramètres générés doivent correspondre exactement à:
- Comment
affine_transform() les interprète
- Comment votre modèle ICA les apprend et les prédit
Sans validation, vous mesurez peut-être quelque chose de différent que ce que vous croyez. Par exemple:
- La paramétrisation utilisée pour générer les images transformées
- Différente de la paramétrisation apprise par le modèle
- = métriques non significatives
4. Utilisation d'une variabilité non contrôlée
Chaque appel à generate_params() génère des paramètres aléatoires différents. Cela complique la validation:
- Vous ne pouvez pas vérifier si le modèle apprend une transformation spécifique
- Les résultats sont très bruités
Mieux serait d'avoir un ensemble de transformations connues et reproductibles pour les tests.
Recommandations 🔧
- Clarifiez la conversion paramètres → matrice de transformation dans
prepare_datasets()
- Filtrez les métriques: comparez uniquement les paramètres pertinents (sans padding)
- Validez la cohérence: vérifiez qu'une transformation connue → prédiction → reconstruction fonctionne
- Utilisez des transformations de test fixes pour des benchmark reproductibles
Voulez-vous que je vous montre comment restructurer cette validation?
It seems that:
See the comments from the analysis made with Claude Haiku (which I agree with)
Regardons la fonction
evaluate_transformen détail. Je vois plusieurs problèmes critiques:1. Incohérence fondamentale: paramètres vs. transformations appliquées
Dans
generate_params(), vous générez des vecteurs de 8 éléments avec du padding zéro selon le type de transformation:Mais dans
prepare_datasets(), ces vecteurspsont passés directement àaffine_transform(). Le problème:affine_transform()de TensorFlow/Keras attend typiquement une matrice de transformation 3×3 (ou 4×4 en 3D). Comment vos vecteurs de 8 éléments sont-ils convertis en matrice?Je ne vois pas cette conversion dans le code. Cela signifie que soit:
pgénérés2. Le calcul des métriques inclut du padding inutile
Vous comparez MSE/MAE sur les 8 éléments complets, y compris les zéros du padding! Par exemple:
Critique: Vous devriez comparer uniquement les paramètres pertinents selon le type de transformation.
3. Pas de validation du mapping paramètres ↔ transformation
Les paramètres générés doivent correspondre exactement à:
affine_transform()les interprèteSans validation, vous mesurez peut-être quelque chose de différent que ce que vous croyez. Par exemple:
4. Utilisation d'une variabilité non contrôlée
Chaque appel à
generate_params()génère des paramètres aléatoires différents. Cela complique la validation:Mieux serait d'avoir un ensemble de transformations connues et reproductibles pour les tests.
Recommandations 🔧
prepare_datasets()Voulez-vous que je vous montre comment restructurer cette validation?