-
-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transcoding Support + More Image Format Support (JPEGXL) #3250
base: develop
Are you sure you want to change the base?
Conversation
Fixed test and benchmark DI. Point docker-build to another hub Edit dockerfile and include jxl package.
1. Supported Image Formats came in the accept flag from the browser. 2. If jxl (or future formats, ie browser not supported AVIF, HEIF, etc) are not supported, Kavita will convert it to a suitable display format via conversion providers. 3. if it supported it will return the image as is, no conversion needed. 4. Thumbnails are always converted.
This reverts commit 7f6db24.
This reverts commit 9d48664.
1. Supported Image Formats came in the accept flag from the browser. 2. If jxl (or future formats, ie browser not supported AVIF, HEIF, etc) are not supported, Kavita will convert it to a suitable display format via conversion providers. 3. if it supported it will return the image as is, no conversion needed. 4. Thumbnails are always converted.
…gick. Rollback IOsInfo.cs
Fix GetCoverImage, trying to create a temporary image in current directory, and rename the parameter field name, that generates a wrong asumption.
Optimize Cover Creation
Removing ImageConvertors (No Longer Needed) Refactored mime types and extensions constants
Enable back docker build/push
HEIF and AVIF are superior formats compared to JpegXL and Jpeg2000. Why the hassle to support them? |
Apple might want to talk to you, while I don't want to start a format war, I want to know how much the google Support came from changing netvips to ImageMagick we don't need to add specific support/mantain for JPEG-XL. There is a secondary why, @majora2007 probably can explain it better, but netvips limits the possible CPU targets. What is added, is, we identify if your browser supports a new format A, B, C or D, and if not with transcode the image to a format that your browser/app supports. While is true that the original intent was adding JPEG-XL, let's say because my own bias, and current is in vogue. In the end, we end supporting AVIF, HEIF, JPEG-XL and JPEG2000 comics/manga, regardless your browser/app supports it or not. |
…a/Kavita into RemoveSixLaborsAndNetVips
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went through the whole PR. Please address comments and style changes.
I'm worried about EncodeFormat not being taken into consideration and I want to research a way to remove JPEG as the default format as we can use PNG instead.
API/Services/BookService.cs
Outdated
stream.Seek(0, SeekOrigin.Begin); | ||
image.SaveAsPng(stream); | ||
image.Save(stream, EncodeFormat.PNG, 100); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can leave off the 100 since it's default quality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New IImage interface, do not have default value, we can add it if you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see ever a need to not generate at 100 quality, so we should probably just leave it off entirely. If there is ever a need, it's easy to refactor the signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, if I remove the 100, I cannot control JPEG image quality required below, #3250 (comment)
if you want, I can add a default value to the interface.
FYI (ImageMagick)
100 PNG = Maximum Compression. loseless
0 PNG = No Compression. loseless
100 JPG = Loseless JPG
99 - 1 = Lossy JPG
AVIF and WEBP I think they're similar to JPG.
I saw a comment about what IDE do I use last night, but wasn't able to find it. I use Rider. We shouldn't have BOM. It's likely due to PRs submitted by the community where it might have been added. |
By default VS will save with BOM. I had this issue as well and I believe you can change this default behavior to save without BOM. |
Added Per Image Lock on conversion, to prevent multiple threads from processing the same image at the same time.
I did just that, then some other files, got BOM when they original did NOT. Swapped to Rider, for this, Rider does not touch the BOM (Nor add, nor remove) |
@maxpiva if you're on discord, can you reach out to me? I want to discuss about the quality a bit more and get a better understanding. My biggest questions are about the quality (100, 0, 99, etc) and how to know when to use what and the time delta you provided for PNG vs JPEG for transcoding, what type of image did you use and what is the quality delta between (is it noticeable to the user)? |
Added Quality From EncodedFormat Extension
Just remembering that this impacts the docker image and that might mean we need to check with unraid/lsio/qnap where they make customizations. @DieselTech can you confirm? If this is true, we will need to pair this with a release that isn't primarily bugfixes (which is what the upcoming one is). |
Working in unraid as is, using (original unraid template) but changed the image path to my docker repo. |
Note to self: #3164 should get merged in with this Transcoding PR so any Colorscape effects can happen together. |
Just an update, I'm wrapping the current canary testing. #3025 gets first priority to the canary testing (as it's likely to be a shorter test phase) then this is up. If I can, I will get this into this v0.8.4 release (as otherwise it's a bugfix release). Thanks for your patience. I think this will be a nice enhancement to Kavita and allow for much better format support in the future. |
Nice :) |
I reached out to Dani from Panels and they will add Accept headers to their requests so we don't need to always transcode. |
@maxpiva So what was the consensus of the NetVips stuff? Wondering if I can slot this in the canary (since the Koreader one needs some more work). |
@majora2007 IDK. Asked the guy how to make it possible, but have no answer, is he/she in the discord channel? Ref: if we make it work at OS level. I could code also the netvips implementation, and we can choose at build time which one to use. |
That is the maintainer of NetVips actually. They aren't in the discord. I'm not sure if it can be possible as well have native Linux builds as well. Let's move forward with canary testing for now. |
Okay the time is near. Once you get the merge conflicts out of the way, I'm good to deploy this to our canary branch and start extended testing with our dedicated testers. |
Added/Modified.
Support for JPEG-XL, JPEG 2000, HEIF and AVIF.
Dynamic transcoding to JPEG in the cache, when the browser does not have support for the image types.
Direct serving when the browser supports the new image type. (IE, MAC, IOS )
Transcoding of the thumbnails when needed.
Based on ImageMagick. (Magick.NET)
Created IIMage and IIMageFactory interfaces with their ImageMagick Implementation, decoupling image manipulations implementations from the ImageService.
Edited Dockefile, adding required library support for reading the new image formats in Linux versions. [Bumped ubuntu to oracular, because of the JPEG-XL image support]
Removed Netvips.
Removed SixLabors ImageSharp.
Change the Context Aware Thumbnail, from NetVips to SmartCrop.js C# port.
[Not Related] Update nugets to latest, Flurl Http changed the way its configured, edited accordingly.
Missing
Additional Testing methods.
Dockerfile
maxpiva/kavita:nightly