Reducing storage of similar PNGs by compressing them into a video and retrieving them losslessly--possibility or dumb idea?

My app stores and transports lots of groups of similar PNGs. These aren't compressed well by official algorithms like .lzfse, .lz4, .lzbitmap... not even bz2, but I realized that they are well-suited for compression by video codecs since they're highly similar to one another.

I ran an experiment where I compressed a dozen images into an HEVCWithAlpha .mov via AVAssetWriter, and the compression ratio was fantastic, but when I retrieved the PNGs via AVAssetImageGenerator there were lots of artifacts which simply wasn't acceptable. Maybe I'm doing something wrong, or maybe I'm chasing something that doesn't exist.

Is there a way to use video compression like a specialized archive to store and retrieve PNGs losslessly while retaining alpha? I have no intention of using the videos except as condensed storage.

Any suggestions on how to reduce storage size of many large PNGs are also welcome. I also tried using HEVC instead of PNG via the new UIImage.hevcData(), but the decompression/processing times were just insane (5000%+ increase), on top of there being fatal errors when using async.

That's probably it, given how touchy CMake seems to be

I'm currently stuck because I can't get jpegli to compile, and apparently its wired into the package. It just absolutely refuses to be compiled. I suspect it has something to do with

-- Could NOT find JPEG (missing: JPEG_LIBRARY JPEG_INCLUDE_DIR) 

But I don't know where to begin because, while installing libjpeg-turbo on this would probably lead to the warning going away, it would likely lead to cross-compiling issues (that thing Quinn was talking about).

Apparently I'm not the only one with issues compiling jpegli: https://github.com/libjxl/libjxl/issues/3440

I've also tried a slew of different hacks, including isolating it and forcing it to compile, but I'm stuck on this error:

CMake Error at jpegli.cmake:46 (target_link_libraries):
  Target "jpegli-static" links to:

    Threads::Threads

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Anyways, I'll figure something out, like precisely excising it from libjxl

wmk's Misadventures in Compiling C++, Finale (?)

JXL is working on my iPhone after I got rid of libjpegli. The weeklong tumble down the rabbit hole of C++ compilation is finally over; and thus ends this impromptu blog I started writing for debugging purposes and to keep myself sane.

At the end of this I look back and realize how much I've been spoiled by Xcode, where compiling is just a mindless habit. Having to figure out CMake after being raised on Xcode is like getting chucked into the slums after having lived all your life in an ivory tower being pampered by servants who aren't perfect, but get the job done.

I've done some preliminary tests on encoding, decoding, and animation and everything seems to be working fine. The code in https://github.com/awxkee/jxl-coder-swift works even with TaskGroups, which allows me to turbocharge everything.

JXL so far seems to be absolutely worth the effort.

Now I just need to fiddle with the parameters to optimize performance for my app, and actually examine the animation output.

@endecotp I cannot thank you enough for introducing me to JXL and sticking with me until I got it working. I was about to spend perhaps hundreds of dollars, but in the end all I spent was $2.99 on an Upwork job post. If the opportunity ever arises, I'd definitely return the favor.

P.S. Upwork is a dumpster fire.

Great that you finally got it working!

Reducing storage of similar PNGs by compressing them into a video and retrieving them losslessly--possibility or dumb idea?
 
 
Q