[Canary] 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
|
@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. |
|
Sorry Reopen the PR by mistake |
Q8 is a lot faster new DefineConstants Q8, Q16 and Q16HDRI can be passed to build if you want any variation, default is Q8. Q16 and Q16HDRI is desirable when the ouput screens are >8 bit, and the initial format support more than 8Bits. IE: AVIF, HEIF or JPGXL.
|
Not the right or, is the other one. Also will commit some changes that
gives us 2x and 4x transcoding speed, testing right now, will or later today
El El mar, 10 dic. 2024 a la(s) 19:21, Joe Milazzo ***@***.***>
escribió:
… Reopened #3250 <#3250>.
—
Reply to this email directly, view it on GitHub
<#3250 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAI4G3JQZRLXKMDLGWI7MRT2E5SOFAVCNFSM6AAAAABPK3SNUKVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVGYYDQMRWGMYDCNY>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
Sounds good. Once you are ready, give me a ping and I can get this deployed onto canary for our testers before I log off for the holiday season. |
Fix merge bugs. Added/Updated nugets, to remove transient security vulnarabilities from other nugets.
Merge from Develop
|
Merge from Develop. The original implementation was using Q16HDRI which is 4 times memory heavier and slower than the other implementations. Q8 - 8 Bit per channel per pixel processing on bytes. Similar to NetVips chain. Right now, the .NET Proxy Library, Magick.Net does not support Side by Side, you must choose one implementation or the other at build time, so, currently the user, cannot choose the ImageMagick Implementation to use, without us, using a custom Magick.Net that native load the correct library, depending on ours choice. Nevertheless, there is 3 new Define Constants, one can use to tailor Kavita in the future. you can add to dotnet build : /p:DefineConstants="Q8" Is nothing is included Kavita will be built with Q8. Q16 will make sense, if the user has a screen capable of more than 8 Bits per pixel, and the source has more than 8 Bit per pixel also, IE: HEIF, AVIF, JPEGXL. Some Dithering bastards, could chime in, that is also good for 8-bit sources on 10-bit screens. ;) In Regard NetVips, Supporting the new formats requires new tooling, docker needs to install netvips native, and I was unable to make it work on normal windows, since the native nuget dosn't support the extended formats, we need to make it download it and installing manually without breaking in the Windows Build stage, or do a .bat/.powershell. As you see I abstracted all the image processes into interfaces, so swapping engines (ImageMagick x NetVips) is possible, since Kavita is now totally abstracted of the Image Processing libraries we use, and NetVips implementation should be easy to do, since we need to refactor only the existing NetVips actions into the interfaces. The problem is the tooling to make NetVips viable again. So far so good on my server. |
majora2007
changed the title
|
I'm sorry @maxpiva, I created canary off the latest develop this morning and I guess there are some conflicts. Once you get them done, just dm me so I can merge and start the activities for the dedicated testers. |
|
Let me merge from Canary into this branch. Previously I merged and resolved from develop. |
|
@majora2007 FYI: Canary has differences in the frontend against develop (I just taked canary), also some version differences on Canary Kavita.Commons.csproj (not important). ` up to date, audited 725 packages in 2s 114 packages are looking for funding 5 vulnerabilities (1 low, 1 moderate, 3 high) To address all issues, run: Run
Application bundle generation failed. [1.663 seconds] X [ERROR] Angular compilation initialization failed. [plugin angular-compiler] Error: The Angular Compiler requires TypeScript >=5.4.0 and <5.6.0 but 5.7.2 was found instead. |
|
Okay bare with me. I have no idea how canary got out of sync with develop as I deleted it this morning then recreated it off develop. I recreated it off of develop. It looks like there might be a few changes that need to be fixed up from your PR (or cherrypick from before the "canary" merge and remerge). Sorry about all the trouble. |
|
wow this sounds great, i can't wait to test this out! when transcoding from jxl to a supported format, what format does it choose. at first blush it would seem like there would be no reason to not just convert to png since it's lossless, but on second thought that could be really problematic if people are on mobile and bandwidth restricted. on the other hand though encoding a lossy format to another lossy format could start to introduce artifacts. i wonder how you guys chose to address this? |
Canary testers, I need your help! This is a massive PR that swaps out the Image system in Kavita and brings Transcoding support. This is built from the nightly. Please give it a serious stress test and report back on the nightly thread.
Added
Changed
Developer