SUPIR

SUPIR est un système de recherche de restauration générative fondé sur SDXL et des descriptions d’image. Une texture convaincante ne prouve pas que le détail figurait dans l’original. Cette évaluation repose sur les sources officielles, consultées à nouveau le 20 septembre 2026. Aucun poids de modèle n’a été téléchargé, aucune image traitée et aucune mesure de vitesse ou de qualité reproduite. Les droits d’utilisation des checkpoints restent à clarifier.

Définir la décision avant la restauration

Formulez une question bornée : SUPIR peut-il produire, à partir d’une seule photographie dégradée que vous avez le droit de traiter, un dérivé utile à l’affichage sans modifier les faits importants pour le lecteur ? Un œil, une lettre ou une surface plus nets peuvent paraître plausibles tout en étant inventés. N’utilisez donc pas la restauration pour reconnaître une personne inconnue, lire une plaque illisible ou certifier l’authenticité. Notez les éléments visibles, incertains et ceux qui doivent rester inchangés.

L’article décrit un prior génératif mis à l’échelle, une vaste collection d’entraînement annotée par du texte, des prompts de qualité négative et un échantillonnage guidé par la restauration. Ce sont les affirmations de la méthode, pas des mesures de cette revue. Les auteurs appartiennent notamment au Shenzhen Institute of Advanced Technology, au Shanghai AI Laboratory, à l’University of Sydney, à la Hong Kong Polytechnic University, à l’ARC Lab de Tencent PCG et à la Chinese University of Hong Kong. Réduire le projet à une seule entreprise serait inexact. Conserver l’image endommagée, obtenir une autre image de référence que vous avez le droit d’utiliser ou appliquer une correction non générative peut être préférable. Affiliations des auteurs; article officiel.

Séparer composants et checkpoints

Le README nomme précisément les encodeurs CLIP de SDXL, un checkpoint de base SDXL, LLaVA CLIP et LLaVA v1.5 13B. Il relie SUPIR-v0Q et SUPIR-v0F par Baidu Netdisk et Google Drive; les checkpoints Juggernaut facultatifs sont séparés. Les binaires liés n’ont été ni téléchargés ni hachés; les fichiers GitHub Releases n’ont pas été vérifiés. Chaque composant reste une décision distincte d’acquisition et de licence; ne remplacez jamais silencieusement le fichier attendu par un miroir au nom voisin. Composants documentés

CKPT_PTH.py contient des chemins absolus locaux et les chemins YAML doivent aussi être configurés. Si Hugging Face est accessible, le README permet None pour les chemins CLIP indiqués afin de télécharger automatiquement; il ne demande pas d’effacer tous les chemins des modèles. Enregistrez séparément fichiers SDXL, CLIP, LLaVA et SUPIR avec origine, version et empreinte. Un lien README ne garantit ni intégrité, ni disponibilité durable, ni compatibilité, ni droit d’usage. Chemins à configurer

Comparer Q et F sur la même entrée

La CLI de référence utilise --SUPIR_sign Q par défaut et accepte Q ou F. Les mainteneurs présentent Q comme le réglage d’entraînement du papier à généralisation large et F comme un entraînement sur dégradation légère dont l’encodeur de première étape conserve davantage de détails. Il s’agit de leur conseil, pas d’un classement indépendant. Conseils Q/F; Sélection en ligne de commande

Comparez avec la même source, le même recadrage, la même échelle de sortie, la même graine aléatoire, les mêmes prompts positifs et négatifs et les mêmes réglages d’échantillonnage. Modifier plusieurs facteurs empêcherait d’attribuer la différence à un seul choix. Conservez aussi les candidats refusés et leur motif.

Comparez Q et F sur un témoin légèrement dégradé. À échelle identique, vérifiez si une texture déjà visible est inutilement réécrite; aucun checkpoint n’est universellement meilleur sans cette observation. Refusez tout résultat qui modifie, au-delà de la tolérance prévue, le texte, le visage ou la géométrie établie par la source. Si Q et F produisent des descriptions automatiques différentes, la paire compare le parcours complet, pas seulement les checkpoints.

Contrôler les descriptions, les prompts et les dimensions

Le script prépare une image débruitée pour sa description, avec une cible de 512 pixels sur le petit côté. Par défaut, LLaVA décrit cette image et le texte obtenu intervient dans l’échantillonnage par diffusion. Avec --no_llava, LLaVA n’est pas chargé et la description est vide, mais le débruitage préalable a toujours lieu. Les prompts positifs et négatifs restent actifs, de même que l’exigence de CUDA. Parcours de la description

Le script affiche les arguments et les descriptions dans le terminal et sauvegarde les échantillons PNG finaux. Il ne sauvegarde pas l’image débruitée utilisée pour la description. Son inspection nécessiterait l’ajout d’un export explicite au script; cette modification n’a été ni réalisée ni testée ici. Sans cet export, comparez original, description enregistrée et PNG final. Notez que le diagnostic de l’image intermédiaire est indisponible. Un journal de terminal ne remplace pas un export d’image.

Conservez les prompts complets. Si vous craignez des détails inventés, comparez une description automatique à une description vide. Ne demandez pas un fait que la source ne permet pas d’établir : « lettres bleues nettes » pourrait générer des caractères lisibles plutôt que les récupérer.

Les valeurs par défaut sont une graine de 1234, 50 étapes EDM, une intensité de guidage de 4,0, un contrôle de seconde étape de 1,0, min_size 1024 et upscale 1. L’utilitaire mémorise d’abord les dimensions de l’entrée multipliées par le facteur d’agrandissement, puis applique le minimum interne au petit côté et arrondit les dimensions de traitement à des multiples de 64. La sauvegarde revient aux dimensions mémorisées. Ainsi, une entrée de 512 × 512 avec upscale 1 est traitée à 1024 × 1024 et sauvegardée à 512 × 512. Cette conclusion vient du code, pas d’un essai exécuté. Valeurs CLI; Redimensionnement et sauvegarde

Les réglages de qualité et de fidélité du README sont des points de départ. Modifiez un seul facteur à la fois et distinguez taille de sortie prévue et hypothèses de traitement interne. Les dimensions du PNG ne révèlent pas celles du tenseur interne. Réglages des mainteneurs

Clarifier les droits sur les checkpoints avant l’essai

Le SUPIR Software License Agreement ne peut pas être résumé sans réserve par « usage non commercial autorisé ». La section 2(b) ne concède pas de droits d’utilisation, copie, modification ou distribution des composants neuronaux propriétaires sans permission écrite explicite. La section 3(a) indique séparément que les poids, biais et architectures propriétaires ne peuvent être utilisés qu’à des fins non commerciales; la section 3(b) exige un accord commercial distinct. L’articulation entre ces dispositions reste non résolue ici. LICENSE, sections 2 et 3

Cette évaluation ne décide pas quelle disposition prévaut et n’autorise aucun usage des poids Q/F. Demandez au concédant de clarifier le checkpoint exact et l’activité prévue avant de suivre le plan d’essai. Un code public et un lien de téléchargement ne prouvent pas l’autorisation. Vérifiez séparément les conditions de SDXL, LLaVA, des modèles Juggernaut facultatifs, des images d’entrée et des sorties. Une interface publique ou payante ne tranche pas ces questions.

Le README relie l’application SupPixel. Aucune image n’y a été soumise et ses conditions actuelles, sa confidentialité, ses prix et son fonctionnement n’ont pas été testés. Avant un envoi, identifiez l’opérateur et conservez les règles de traitement des données, les conditions et les droits de sortie applicables ce jour-là. La disponibilité constatée concerne le code consultable et les liens documentés, pas le téléchargement réussi des poids ni un service opérationnel. Application documentée

Préparer une comparaison limitée et traçable

Clarifiez d’abord la permission portant sur les checkpoints. Préparez ensuite une photographie que vous avez le droit de traiter et une image témoin moins dégradée. Gardez les originaux, retirez au besoin les métadonnées sensibles d’une copie de travail et notez les détails à préserver. Utilisez un environnement isolé et relevez les versions réellement installées des dépendances et pilotes. La recette Python 3.8 du README ne garantit pas la compatibilité avec chaque système actuel. Installation

Les commandes ci-dessous n’ont pas été exécutées. Elles supposent les checkpoints configurés et CUDA. Les redirections du shell conservent la sortie standard et les erreurs de chaque exécution, dont les arguments et descriptions affichés. Examinez chaque journal avant de lancer la suite; aucun succès n’est affirmé ici. Le script signale une erreur sans CUDA. Appareils et arguments

mkdir -p logs
python test.py --img_dir inputs/control --save_dir results/q --SUPIR_sign Q --seed 1234 > logs/q.log 2>&1
python test.py --img_dir inputs/control --save_dir results/f --SUPIR_sign F --seed 1234 > logs/f.log 2>&1
python test.py --img_dir inputs/control --save_dir results/no-caption --SUPIR_sign Q --seed 1234 --no_llava > logs/no-caption.log 2>&1

Ne placez que l’image prévue dans le dossier d’entrée et choisissez des noms de base distincts. Chaque PNG final est nommé <input-stem>_<sample-index>.png; pour control.png et un échantillon, le résultat Q se trouve dans results/q/control_0.png. La description affichée n’inclut pas le nom de l’entrée. Une seule image par exécution permet donc de conserver une association claire. Boucle et noms de fichiers

Comparez original, description du journal et PNG à la taille d’affichage prévue et dans les recadrages importants. Relevez format, profil colorimétrique, dimensions d’entrée et de sortie, et valeurs implicites. Les dimensions internes et les ressources exigent une mesure ou une instrumentation séparée; le journal ne les fournit pas automatiquement. Passez à l’image difficile seulement après acceptation du témoin selon la fiche. Sans export supplémentaire, non testé ici, l’image intermédiaire reste indisponible.

Accepter avec une fiche de preuves

Cette fiche est une proposition originale d’évaluation, pas un résultat de benchmark. Remplissez-la avec des observations réelles avant d’élargir le lot.

Refusez un candidat qui modifie un trait d’identité, crée un texte lisible non étayé ou déplace un bord important. Une netteté moindre peut mieux respecter l’original. Définissez la tolérance selon l’usage d’affichage, pas selon un score générique. Gardez commande complète, environnement et empreintes locales, puis distinguez les fichiers source et dérivé avec une mention de modification.

Diagnostiquer avec les éléments réellement disponibles

Examinez original, journal, choix Q/F, prompts, échantillonnage, correction de couleur et PNG avant d’augmenter les réglages. La CLI d’origine ne sauvegarde pas l’image utilisée pour la description : elle ne permet donc pas d’observer sa première divergence. Elle ne propose pas non plus d’argument pour fournir une description corrigée manuellement. Ces deux possibilités nécessiteraient une modification du script examinée et testée séparément. Options et descriptions

Ces pistes sont des hypothèses, pas des fréquences d’échec mesurées. Conservez le premier indice disponible et sa commande. Si les journaux et fichiers sauvegardés ne permettent pas d’isoler la cause, notez qu’elle reste inconnue plutôt que de prétendre avoir contrôlé une étape interne.

Mesurer les ressources et vérifier la confidentialité

Avec au moins deux GPU visibles, le script place SUPIR et LLaVA sur des appareils distincts; avec un seul, ils le partagent. Sans CUDA, le script s’arrête. Placement des modèles

L’exemple Gradio plus lent du README porte les mentions 12 Go pour la diffusion et 16 Go pour LLaVA. Elles ne constituent ni un minimum universel ni la preuve qu’un travail complet tient sur un seul GPU de 12 Go. Relevez dimensions d’entrée et sortie, Q/F, nombre d’étapes et d’échantillons, types numériques, options de tuilage, modèle du dispositif, pic mémoire et durée. Mesurez séparément téléchargement des checkpoints, démarrage, légende, échantillonnage, sauvegarde et inspection humaine. L’autoencodeur accepte fp32 ou bf16 et refuse fp16 en raison d’un chemin d’erreur NaN. La précision de diffusion est réglée séparément; toutes les combinaisons et configurations matérielles ne sont pas pour autant validées. Exemples Gradio; Types numériques

Pour les images privées ou sous licence, décidez si un traitement local est requis. L’auto-hébergement ne règle ni les droits d’entrée, ni le consentement des personnes, ni la télémétrie des dépendances. L’exemple Gradio officiel peut journaliser l’historique; examinez les journaux activés. Les offres hébergées exigent leur propre contrôle de confidentialité et de conservation. Option d’historique

Choisir la suite à partir des preuves

Continuez uniquement si un candidat contrôlé sert l’usage, garde la structure établie par la source, dispose de droits clarifiés pour le checkpoint et l’usage prévus et présente un coût de revue acceptable. Sinon arrêtez et choisissez rééchantillonnage, débruitage, retouche, meilleur scan ou original. Conservez configuration, journaux, sorties acceptées et refusées et note de divulgation.

Arrêtez aussi face à une matière critique inventée, des droits non clarifiés sur le checkpoint ou d’autres éléments nécessaires, un dépassement des ressources ou des retouches manuelles répétées. Cette revue ne classe pas SUPIR face à d’autres modèles et ne reproduit pas les expériences du papier. N’utilisez le répertoire des modèles qu’après avoir nommé la capacité manquante, puis comparez les solutions avec la même entrée autorisée et la même fiche. Un dépôt public, une image nette ou une commande terminée ne prouvent pas l’aptitude au travail.