Closed leeari95 closed 10 months ago
5.18.0 -> 5.18.1
Does not add new header files or source files...The tag diff is here: https://github.com/SDWebImage/SDWebImage/compare/5.18.0..5.18.1
The only change is Package.swift
(SPM manifest file), which I bump the Swift version from 5.0->5.3
How Tuist works on Swift Package Manager framework ? I have no knowledge about that.
Guess this change cause the issue
// swift-tools-version:5.0 // swift-tools-version:5.3
But I don't know how the correct way to solve this. SDWebImage itself does not use any non-modular headers ? Always using #include "Foobar.h"
inside public headers.
Any update here? I am looking for a specific fix in version 5.18.1 of SDWebImage due to which images were showing upside down.
I didn't see any error in SDWebImage's standard unit test on integration.
If you face issue, provide the reproduce demo, so that we can try to investigate.🤔️
@rishabh876 Any demo ?
SDWebImageSwiftPMObjc.zip SDWebImageSwiftPMSwift.zip
I didn't find anything integration issue.
Xcode 14.3.1
Ok it looks like I am also using 5.18.5 that should have the fix but still the images are getting upside down while encoding. It can be reproduce
SDImageWebPCoder.shared.encodedData(with: image, format: .webP, options: [.encodeCompressionQuality: 0.8, .encodeMaxFileSize: 1024 * 1024])
That fix is for JPEG only, not the WebP encoding. Maybe new bugs
Can you create a new issue instead ? So I can create PR directly point to that. This PR seems out of date and non-related, I'll close now
@rishabh876 Create a new issue with your demo ? I can not reproduce with the description you say.
For example
https://imgur.com/a/3WdWtZU
, this is an PNG image, no EXIF orientation which effect the image orientation. And my encoding result to webp works great. You can provide the input image (to be encoded) zip archive to meThe build issue no long exists and close
Currently, I'm managing project dependencies using Tuist.
Versions: macOS
13.5.2
Xcode14.3.1
SDWebImage5.18.2
SDWebImageWebPCoder0.13.0
Build Error Details:
Upon direct testing, I found that the error mentioned above starts occurring from version 5.18.1 of SDWebImage. By locking the SDWebImage version to 5.18.0, the error no longer arises.
I'm not sure why this error is occurring due to the version difference. Please help.