For redistribution, JPEG or AVIF or WebP. I'd choose JPEG myself... good enough compression with broad compatibility. You'll almost never run into an issue with it. AVIF and WebP are still full of gotchas, so I wouldn't deploy them without a JPEG fallback.
For sharing masters/originals, it just depends on your team's needs. Probably saving the camera RAW is a good idea, but usually there's been edits done to it, so some Photoshop or Lightroom native format, for example, or at least a TIFF if you need broader compatibility.
(edit: The answer should logically follow from the following, but as a TL;DR: yes, they must have meant jpeg or similar, although I disagree about it being such a "please don't". Feel free to, they'll take more bytes but it's not like you're losing information in the process, so you can always still switch to jpeg.)
Photos have lots of noise anyway, so a good jpeg is not going to be the limiting factor. Due to jpeg being lossy, the file size is much smaller for the type of images that pictures are (I don't know a formal definition, perhaps something with some amount of random noise? Or that there's lots of gradients with nonlinear slopes or so?).
PNGs are lossless, and encoding photos in a lossless way takes a relatively large amount of space. On the other hand, the quality degradation of running text through a jpeg encoder is noticeable even when tuning the jpeg compressor for it, so a screenshot with text is always PNG. For designed things such as icons or logos or so, the file size is small enough to be a no-brainer for getting PNG's lossless quality.
Vector, such as SVG, is the ultimate format: the highest possible quality and also the smallest! This only works when you've got access to the source (screenshots already don't work because you're capturing a blend of objects rendered as an array of pixels), and especially not suitable/possible when you're reading from a sensor such as a digital camera. This format doesn't describe pixel patterns, but rather shapes such as "draw a red line from coordinates 3,94 to 1920,1027". Because you can't always use it (you can always render an SVG as a grid of pixels and turn it into a PNG or anything else, but not the other way around), support is a bit lower and you'll see them less often, but imo it's always worth striving for when the platform allows
For browsers, there are extensions that can create SVG screenshots. They work by either copying or inlining CSS into the SVG. They don't work all the time, but worth giving a try first.
It seems to capture the HTML and convert each element to a similar one on SVG. I'm still not sure how it handles raster images (does it just embed them? Vectorize them somehow?) but it's a really cool project. Thanks for sharing!
Minor nitpick, just for clarity: Vectors aren't really the "ultimate" format, they're just a different format for storing a different kind of information.
Vectors are good for things that can be mathematically described/simplified without significant loss of information (such as curves, shapes, some gradients, etc., and compositions of those) Many logos and fonts fall into this category, for example, and some clip-art do as well. For the appropriate graphics, vectors can give you higher quality and smaller file sizes. But it's not necessarily the right choice for everything. Real pixels do hold data, and vectorizing them will typically cause some data loss. You COULD vectorize photos and illustrations (vectormagic.com is a good one for that). But you just end up with a poorer approximation of the original raster data, ending up with a bunch of pixel-like polygons, because there's not really a better approximation of that high-resolution pixel data that can be easily described in shapes and lines.
Rasters are still superior not only for photographs, but for other uses outside of basic image redistribution, such as GIS data layers (where sensor data IS what's important), bump maps and terrain maps for games, 3D voxel images for medical imaging, live-action movies (which can interpolate complex scenes between raster frames), astronomy, etc. Even if you could vectorize the sensor data in those situations, you often wouldn't/shouldn't.
> Real pixels do hold data, and vectorizing them will typically cause some data loss.
Chickens and eggs. If you have vector data already, it's better to distribute the raw vectors than to rasterize them. If you only have raster data, distribute the rasters (where viable) instead of trying to trace them. Lossy operations are lossy.
Vectors are largely preferable to rasters, but that doesn't mean you can reproduce them if you only have the rasters. Just like distributing source code is usually preferable to compiled binaries, but that doesn't mean that we just pump everything through Ghidra and call it a day.
Yeah, exactly. The takeaway IMO is that there are different formats best for different kinds of data. There's no "best" or "ultimate" format, it just depends on your use case.
If I squint hard enough, jpeg starts to look like a very esoteric spin on svg, a quilt of tiny svg-like tiles whose parameters are defined by an encoder analyzing a bitmap rather than a human visualizing a concept.
