Low compression quality compared to cwebp CLI tool
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 25/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- objective-c, swift
- Domaine
- computer-graphics
Piste de recherche
Commencez par le point d’entrée de l’encodage sans perte de SDImageWebPCoder présenté dans le rapport et comparez sa sortie à celle de cwebp -lossless à l’aide de l’exemple fourni. Vérifiez quelles options encodeCompressionQuality, encodeWebPMethod et encodeWebPPass sont transmises, puis définissez l’achèvement comme le fait de correspondre au comportement de cwebp en matière de qualité sans perte et de taille de fichier, ou de documenter la différence d’implémentation.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Description
When using SDImageWebPCoder to encode images with lossless options, the resulting file size and compression quality appear to be worse compared to Google's cwebp command-line tool. Despite both using lossless compression settings, SDImageWebPCoder produces slightly lower quality images, with visible artifacts and banding on gradients and shadows.
I experimented with different encoding options such as: encodeCompressionQuality, encodeWebPMethod, encodeWebPPass etc. Despite these adjustments, the output quality and file size were still worse compared to cwebp -lossless. This suggests a fundamental difference in how the WebP encoding is implemented in SDImageWebPCoder versus the official WebP compression tool.
Code
SDImageWebPCoder:
if let data = SDImageWebPCoder.shared.encodedData(with: nsImage, format: .webP, options: [.encodeWebPLossless: 1]) {
try data.write(to: destination))
}
cwebp:
cwebp -lossless input.png -o output.webp
Results
- Langage dominant
- Objective-C
- Étoiles
- 278
- Forks
- 101
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de SDWebImage/SDWebImageWebPCoder
-
Difficulté 3/5 1-2 jours Accessibilité débutants 25/100
SDWebImage/SDWebImageWebPCoder#117 · 1 commentaire ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
SDWebImage/SDWebImageWebPCoder#115 · 4 commentaires ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 30/100
SDWebImage/SDWebImageWebPCoder#113 · 3 commentaires ·
-
Frames loadingOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
SDWebImage/SDWebImageWebPCoder#105 · 15 commentaires ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
SDWebImage/SDWebImageWebPCoder#78 · 2 commentaires ·
Toutes les issues de SDWebImage/SDWebImageWebPCoder
Issues similaires
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
objective-see/LuLu#930 ·
-
iOS: hidden scale bar invalidates its intrinsic content size on every layout pass of MLNMapViewOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
maplibre/maplibre-native#4723 ·
Les mainteneurs répondent en général sous 1 jour
-
[iOS, v2/Ganesh] MetalContext over-releases the system MTLDevice once per exited thread, then Metal crashesPeut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
Shopify/react-native-skia#4130 ·
-
[Type] Bug Self-hosted Webviews
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
wordpress-mobile/WordPress-iOS#26115 ·
Les mainteneurs répondent en général sous 1 jour