If APNG couldn't pick up steam and get widespread adoption, not sure how this will. But hopefully I'm wrong.
CPNG, a backwards compatible fork of PNG
81–90 of 122 posts
Re: CPNG, a backwards compatible fork of PNG
#82If APNG couldn't pick up steam and get widespread adoption, not sure how this will. But hopefully I'm wrong.
APNG is supported in every browser and all the video encoding tools I've used. It's not used all that often, but support for it is built into many software libraries.
Re: CPNG, a backwards compatible fork of PNG
#83Earlier quoted context omitted.
so all image formats should be at version 1.0 and never be improved? come on.
Once stable, yes, absolutely! There should be a reference standard that renderers adhere to. Then they should be versioned for future improvement. That doesn't mean there can't be bug and security fixes, but they should be feature-stable. There's a reason why JPEG and PNG are so popular: because they ARE stable and unchanging, in a world of failed adoption for APNG, WebP, HVEC, JPEG 2000, JPEG XL, AVIF, etc. For imag…
The news of JPEG XL’s death is greatly exaggerated.
Re: CPNG, a backwards compatible fork of PNG
#84Earlier quoted context omitted.
so all image formats should be at version 1.0 and never be improved? come on.
Once stable, yes, absolutely! There should be a reference standard that renderers adhere to. Then they should be versioned for future improvement. That doesn't mean there can't be bug and security fixes, but they should be feature-stable. There's a reason why JPEG and PNG are so popular: because they ARE stable and unchanging, in a world of failed adoption for APNG, WebP, HVEC, JPEG 2000, JPEG XL, AVIF, etc. For imag…
> There's a reason why JPEG and PNG are so popular: because they ARE stable and unchanging
PNG is on version 1.2
Re: CPNG, a backwards compatible fork of PNG
#85Earlier quoted context omitted.
PNG was always set up for extension. In particular, it has a clever way of allowing ancillary data sections to be marked as unimportant, so a decoder knows whether it can skip them or report the file as unreadable. I suspect the big thing these days would be to support brotli and zstd.
A problem that often comes up with extensible formats is that whomever comes along and implements them assumes exactly the test cases they came up with, which can often mean "just the files I have for this project" or "just the output of the encoder I have". So there will be formats that can reorder the chunks, and those minimum-viable readers will all break when they encounter a file from a different source, because…
> There were tons of old binary formats that were like this. It can happen with text, but it's less likely to, because a larger proportion of textual formats build over a container like XML or JSON to offload the text parsing, and then they end up with some pre-structured data.
Note that PNG also "build[s] over a container", since it's a descendant of IFF.
Re: CPNG, a backwards compatible fork of PNG
#86Earlier quoted context omitted.
(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 b…
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-ar…
> 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.
Re: CPNG, a backwards compatible fork of PNG
#87What is the modern power ranking on image formats? For lossless, what is typically the most efficient size wise? Decompression speed? For lossy? I am not in a situation where these micro-optimizations mean much to me, and always default to png, but curious to know where the state of the art is today.
AVIF and WebP, two modern replacements for both JPEG and GIF on the web, both support lossy and lossless encoding. WebP is mature and has more browser support, but AVIF is getting there (notably only lacking Edge support). Both can compress in either a lossy JPEG-like fashion or in a lossless PNG-like fashion. If you use a image CDN like Imgix, it'll just auto-detect and serve whatever the most optimal format is anyw…
WebP and AVIIF (and, to a much lesser extent, HEIC, which AVIF is basically a rip off of) absolutely suck for color management since they are a) virtually never original source formats, b) are video codecs. WebP technically supports two different color profile techniques (traditional embedded ICC - broken in every mainstream batch image processor I’ve tried - and nlx video-based color profiles). Unlike WebP and all the other image formats, untagged AVIF can’t be assumed to be sRGB (in part because there is no actual sRGB for video, though close variants exist) and every image processor or image editor will open it with a different base color profile assigned. WebP doesn’t even support exif, making it absolutely horrible for “lossless” operations that effectively aren’t lossless since they necessarily destroy metadata.
HEIC is also a video codec at heart but has a default color space that also isn’t sRGB (which is a good thing; it’s about time we moved on), untagged HEIC images can (though often aren’t in any default workflow) be assigned Display P3. Assigning/assuming sRGB will absolutely break your images, of course.
Re: CPNG, a backwards compatible fork of PNG
#88There’s no mention of what effect these changes have on file size. It seems to me all the non-HDR changes will blow up file sizes for all but the largest of images.
Re: CPNG, a backwards compatible fork of PNG
#89I've also been pondering a backwards-compatible fork of PNG - but rather than a fork, mine would be a subset. Specifically, it would be an as-simple-as-possible uncompressed* bitmap format, suitable for use in low-complexity embedded systems etc. (e.g. bootloaders, wink wink). By being backwards compatible, you get the added benefit of retaining compatibility with existing image viewers, but without having to impleme…
ok thats pretty wild, you would take the zlib deflate/inflate code, (for example in a library like lodepng) and then like chunk 95% of it in the garbage? so basically every block would just be uncompressed? kind of funny but it would probably work pretty well and your code size could get down way way smaller than the current typical png code.
seems like the downside is that this is "worse than nothing" compression, the image file would be bigger than the original blit of the data. for example 1024x1024x32bit color means 3 megabytes for one image. or do i miss something?
Re: CPNG, a backwards compatible fork of PNG
#90Earlier quoted context omitted.
APNG is extremely well-supported these days: https://caniuse.com/apng Fun fact: APNG is better supported than JSON.stringify
And yet I have yet to see one in the wild. It's all WebM and Gifs these days.
If you've seen a video slot machine you've seen APNGs :)