Transcoding Support + More Image Format Support (JPEGXL) #3250
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
majora2007
changed the title
|
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
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.
You can leave off the 100 since it's default quality.
There was a problem hiding this comment.
New IImage interface, do not have default value, we can add it if you want.
There was a problem hiding this comment.
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.
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
API/Services/ImageServices/IImage.cs
Outdated
| @@ -64,15 +64,15 @@ public interface IImage : IDisposable | |||
| /// <param name="filename">The name of the file to save the image to.</param> | |||
| /// <param name="format">The format to save the image in.</param> | |||
| /// <param name="quality">The quality of the saved image.</param> | |||
There was a problem hiding this comment.
Forgot to remove the quality comments. ;)
|
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. |
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