I agree that pickle works well for storing arbitrary metadata, but my main gripe is that it isn’t like there’s an exact standard for how the metadata should be formatted. For FITS, for example, there are keywords for metadata such as the row order, CFA matrices, etc. that all FITS processing and displaying programs need to follow to properly read the image. So to make working with multi-spectral data easier, it’d definitely be helpful to have a standard set of keywords and encoding format.

It would be interesting to see if photo editing software will pick up multichannel JPEG. As of right now there are very few sources of multi-spectral imagery for consumers, so I’m not sure what the target use case would be though. The closest thing I can think of is narrowband imaging in astrophotography, but normally you process those in dedicated astronomy software (i.e. Siril, PixInsight), though you can also re-combine different wavelengths in traditional image editors.

I’ll also add that HDF5 and Zarr are good options to store arrays in Python if standardized metadata isn’t a big deal. Both of them have the benefit of user-specified chunk sizes, so they work well for tasks like ML where you may have random accesses.

I guess part of the reason is to have a standardized method for multi and hyper spectral images, especially for storing things like metadata. Simply storing a numpy array may not be ideal if you don’t keep metadata on what is being stored and in what order (i.e. axis order, what channel corresponds to each frequency band, etc.). Plus it seems like they extend lossy compression to this modality which could be useful for some circumstances (though for scientific use you’d probably want lossless).

If compression isn’t the concern, certainly other formats could work to store metadata in a standardized way. FITS, the image format used in astronomy, comes to mind.

I guess you’d measure whose GenAI models are performing the best on benchmarks (generally currently OpenAI, though top models from China are not crazy far behind), as well as metrics like number of publications at top venues (NeurIPS, ICML, and ICLR for ML, CVPR, ICC and ECCV for vision, etc.).

A lot of great papers come out of Chinese institutions so I’m not sure who would be ahead in that metric either, though.

My stance on Proton is my stance on GrapheneOS: just because the creator is bad doesn’t mean the software is bad. As long as the software is better compared to the alternatives then I seen no reason to stop using it.

I think the major difference is that for a software package or operating system like GrapheneOS, theoretically people can audit the code and verify that it is secure (of course in practice this is not something that 99% of people will ever do). So to some extent, you technically don’t have to put a ton of trust into the GrapheneOS devs, especially with features like reproducible builds allowing you to verify that the software you’re running is the same software as the repository.

For something like Proton where you’re using a service someone else is running, you sort of have to trust the provider by default. You can’t guarantee that they’re not leaking information about you, since there’s no way for you to tell what their servers are doing with your data. Accordingly, to some extent, if you don’t trust the team behind the service, it isn’t unreasonable to start doubting the service.

I work in CV and I have to agree that AMD is kind of OK-ish at best there. The core DL libraries like torch will play nice with ROCm, but you don’t have to look far to find third party libraries explicitly designed around CUDA or NVIDIA hardware in general. Some examples are the super popular OpenMMLab/mmcv framework, tiny-cuda-nn and nerfstudio for NeRFs, and Gaussian splatting. You could probably get these to work on ROCm with HIP but it’s a lot more of a hassle than configuring them on CUDA.

I think it’s been about a year? IIRC Intel only started using TSMC for their processors with Meteor Lake, which was released in late 2023.

I believe their discrete GPUs have been manufactured at TSMC for longer than that, though.