• 0 Posts
  • 19 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle
  • This will be almost impossible. The short answer is that those pictures might be 95% similar but their binary data might be 100% different.

    Long answer:

    Images are essentially a long list of pixels, each pixel is 3 numbers for Red, Green and Blue (and optionally Alpha if you’re dealing with a transparent image, but you’re talking pictures so I’ll ignore that). This is a simple but very stupid way to store the data of an image, because it’s very likely that the image will use the same color in multiple places, so you can instead list all of the colors a image uses, and then represent the pixels as the number in that list, this makes images occupy a LOT less space. Some formats add to that, because your eye can’t see the difference between two very close colors, they group all colors that are similar into one only color, making their list of colors used on the image WAY smaller, thus having the entire image be a LOT more compressed (but you might noticed we lost information in this step). Because of this it’s possible that one image choose color X in position Y, while the other choose Z in position W, the binaries are now completely different, but an image comparison tool can tell you that color X and Z are similar enough to be the same, and they account for a given percentage of the image depending on the amount minimum of the values Y and W. But outside of image software, nothing else knows that these two completely different binaries are the same. If you hadn’t loss data by compressing get images in the first place you could theoretically use data from different images to compress (but the results wouldn’t be great, since even uncompressed images won’t be as similar as you think), but images can be compressed a LOT more by losing unimportant data so the tradeoffs are not worth it, which is why JPEG is so ubiquitous nowadays.

    All of that being said, a compression algorithm specifically designed for images could take advantage of this, but no general purpose compression can, and it’s unlikely someone went to the trouble of building a compression for this specific case, when each image is already compressed there’s little to be gained by writing something that takes colors from multiple images in consideration, needing to decide if an image is similar enough to be bundled in together with that group or not, etc. This is an interesting question, and I wouldn’t br surprised to know that Google has one such algorithm to store all images you snap together that it can already know will be sequential. But for home NAS I think it’s unlikely you’ll find something.

    Besides all of this, storage is cheap, just buy an extra disk and move over some files there, that’s likely to be your best way forward anyways.










  • Yeah, I have high hopes for the project, it ticks almost every box for me. I would still prefer to be able to store tags in the actual images and use them and also be able to recover a library already in the proper folder (so in the case of a catastrophic failure, reimporting the full library is a matter of minutes not days, not to mention having to retag people, etc).

    My point is that projects should ask for donations when they’re so early in development, asking for a subscription implies you have a stable product.



  • I don’t mind this model. That being said for me Immich is great but has a fatal flaw that has prevented me from using it: it doesn’t do updates.

    For me that’s a big one, everything else I self host I have a docker compose pointing to latest, so eventually I do a pull and up and I’m done, running the latest version of the thing. In Immich this is not possible, I discovered the hard way that they are not backwards compatible and that if you do that you need to keep track of their release notes to know what you need to manually do to update.

    I haven’t settled on a self-hosted photo management because of this. In theory Immich has almost everything I want (or more specifically, all of the other solutions I found lack something), but having to keep track of releases to do manual upgrades is stupid, this is a software, it should be easy to have it check the version on start and perform migration tasks if needed.




  • That would be awesome, currently it’s 500GB for their cheaper option which starts at 23/year. I didn’t find an option to increase the bandwidth before completing the order. Also it needs to be deployed in NY (which would be possibly slow for me in Europe). Finally their isos are somewhat old, the latest Ubuntu they have is 20.04 (which has an EoL next year).

    All that being said, 23/year is very cheap for a VPS, and for people in the US that use less than 500GB/month that’s the best deal I’ve ever seen.