Store jpegs as Jpeg XL transparently

[dali99]

As opposed to #720 this would be hardcoded into the application rather than a generic framework for running processing,

JXL has the ability to losslessly encode jpg images into jxl images, allowing ~20% space savings, these jxl images can be converted back into the original jpeg file bit for bit. This needs specific client implementation so that hydrus will preserve the hash for lookup in tag repositories.

It'd also be nice to be able to import jxls which have had this treatment and still have the hashes computed for the "underlying" legacy jpeg. Since in the future it is likely that some filehosts will begin serving jxls like this.

[Zweibach]

Since in the future it is likely that some filehosts will begin serving jxls like this.

Given that Chromium is dropping support and Firefox hasn't implemented it fully after three years I find the odds of this happening very low given the extremely low market cap of Firefox Nightly users. Format is dead, mate.

[dali99]

chromium dropping support is politically motivated (see the libaom staff being tagged in the PR) as opposed to technical, IEC 18181-4 was published less than three months ago and the format is seeing adaption in many non-browser contexts.

The format itself was finalized 6 months ago. It is somewhat insane to say it is dead at this point. I am a little pessimistic about browser support as well, but I can see it adopted server side and in many other client applications such as krita and photoshop.

The layering support has the potential to finally be a solution to the dreaded 100 alternates, and it is very good at encoding comics and grayscale content. These features make jxl an extremely good fit for the ecosysytem hydrus operates in.

Someone somewhere will make a wasm polyfill for chromium anyways.

[BlueSwordM]

Format is dead

I'm sorry, but that's just tunnel vision. Outside of browsers, JPEG-XL har far better support. Heck, even though ffmpeg supported AV1 far before JPEG-XL, ffmpeg got JPEG-XL support before AVIF.

JPEG-XL is just better built as an image format overall, and the more programs support it, the better it is overall, even if the Chrome and AOM team conflicts of interest delay that a bit.

[Demez]

This would be quite nice of a feature, as I store a bunch of JPEG-XL images locally on my pc, and being able to have hydrus use JXL's would be very nice

[Zweibach]

Support for the format in Hydrus is quite different from having Hydrus convert to it automatically. See #261 for supporting more formats.

[hydrusnetwork]

Hey, while I am hopeful that JpegXL wins the format war, and as soon as there is easy support for it in PIL or OpenCV I'll add it to hydrus, I probably won't implement special hardcoded swaperoo logic to merge content specifically across here, nor will I write specific internal JpegXL conversion.

However, I am interested in moving towards generic and flexible support for these ideas. Different people have different format preferences, and I'd like to generally improve my duplicate tech over the coming years to allow this sort of convenient merging for all duplicates and all classes of easily defined technical dupes. Ideally, I can support a 'this JpegXL is actually this jpeg, now do what is sensible to merge their tags etc...' idea natively and user-friendily.

For mass conversion, I don't want to write that code myself, but I do want to open pathways to do it neatly, and I'll write the maintenance platform/pipeline to do it. I see hydrus getting a sort of 'executable manager' dialog, where you can define (and users can share) some profiles like, "this is imagemagick, with [this pattern of exe call and arguments], it can [take a pathname here] and it will output an [exact dupe] [here]', which would be a command for hydrus to make the new file and import it on the selection you commanded it to. You can think of similar things you could do with ffmpeg re-encoding or waifux2x upscaling. Then I can have a maintenance task in the background firing off those jobs and doing the auto-tagging or import/auto-dupe work and whatever, and I don't have to care about the actual calls involved, just the hydrus side of arbitrary content actions.

As a side thing, I've been thinking a while now that as we move from sRGB files to various sorts of HDR, we'll probably want a 'colour upscale' system that gives us nicer greens and fills in better dark and light colours on our old photos. Like when they colour old black and white images. Since ML is taking off, it'll probably be some version of that. I'd be interested in having my stale jpegs turned into vivid JpegXLs in five years, but I guess we'll see how good those greens actually are once we all have the monitors for them.

Anyway, so my answer here is both yes and no. I want this capability, but in a user-flexible, roundabout way. I can't promise it quick, but it is on my mind. I refuse to wade into any format war stuff personally--I'll support whatever I reasonably can, and users can do as they like.

[hydrusnetwork]

Sorry, I just noticed you specifically mentioned #720 in your first post, and my comment here is saying 'man, wouldn't it be great to have a system [like #720] instead?'. I'll be more clear--I don't want to hardcode anything here, nor take a position on formats. Although I agree that JpegXL is cool, I have to serve a variety of interests and needs, and I often don't have the brain for getting into the weeds of format differences, so I'll focus on a flexible 'whatever you want' system rather than drilling down too much.