16 ms·

A new PNG spec

• bravesoul2 1y ago
  Papua New Guniea never went away!
• LeoPanthera 1y ago
  > I know you all immediately wondered, better compression?. We're already working on that. This worries me. Because presumably, changing the compression algorithm will break backwards compatibility, which means we'll start to see "png" files that aren't actually png files. It'll be like USB-C but for images.
  • skywal_l 1y ago
    Can't you improve a compression algorithm and still produce a still valid decompression input? PNG is based on zip, there's certainly ways to improve zip without breaking backwards compatibility. That being said, they also can do dumb things however, right at the end of the sentence you quote they say: > we want to make sure we do it right. So there's hope.
    • masklinn 1y ago
      > Can't you improve a compression algorithm and still produce a still valid decompression input? PNG is based on zip, there's certainly ways to improve zip without breaking backwards compatibility. That's just changing an implementation detail of the encoder, and you don't need spec changes for that e.g. there are PNG compressors which support zopfli for extra gains on the DEFLATE (at a non-insignificant cost). This is transparent to the client as the output is still just a DEFLATE stream.
    • vhcr 1y ago
      That's what OptiPNG already does.
      • josefx 1y ago
        Doesn't OptiPNG just brute force various settings and pick the best result?
  • lifthrasiir 1y ago
    Better compression can also mean a new set of filter methods or a new interlacing algorithm. But yeah, any of them would cause an instant incompatibility. As noted in the relevant issue [1], we will need a new media type at the very least. [1] https://github.com/w3c/png/issues/39#issuecomment-2674690324 https://github.com/w3c/png/issues/39#issuecomment-2674690324
    • snvzz 1y ago
      I am hopeful whatever better compression doesn't end up multiplying memory requirements, or increase burden on cpu, especially on decompression. Now, PNG datatype for AmigaOS will need upgrading.
      • clownpenis_fart 1y ago
        [dead]
      • Arnt 1y ago
        I don't see why? If your video output is plain old RGB (like the Amiga hardware), then an unmodified decoder will handle new files without a problem. You only need a new decoder if your video output can handle more vivid colours than RGB can express.
        • Findecanor 1y ago
          An image decoded in the wrong colour space for the output will look wrong. It is not using extra bits to express the increased dynamic range: the existing numeric range is stretched and warped.
          • Arnt 1y ago
            Yes. But how bad? AIUI the way it's done is more or less the best that can be done with old video hardware, like mine and like the Amiga. It could be horrible in principle, but actually isn't.
    • 1y ago
  • colanderman 1y ago
    One could imagine a PNG file which contains a low-resolution version of the image with a traditional compression algorithm, and encodes additional higher-resolution detail using a new compression algorithm.
  • Lerc 1y ago
    It has fields to say what compression is used. Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress. The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.
    • mort96 1y ago
      > Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress. Yeah, we know. That's terrible.
    • koito17 1y ago
      > Having an extensible format and electing never to extend it seems pointless. This proves OP analogy regarding USB-C. Having PNG as some generic container for lossless bitmap compression means fragmentation in libraries, hardware support, etc. The reason being that if the container starts to support too many formats, implementations will start restricting to only the subsets the implementers care about. For instance, almost nobody fully implements MPEG-4 Part 3; the standard includes dozens of distinct codecs. Most software only targets a few profiles of AAC (specifically, the LC and HE profiles), and MPEG-1 Layer 3 audio. Next to no software bothers with e.g. ALS, TwinVQ, or anything else in the specification. Even libavcodec, if I recall correctly, does not implement encoders for MPEG-4 Part 3 formats like TwinVQ. GP's fear is exactly this -- that PNG ends up as a standard too large to fully implement and people have to manually check which subsets are implemented (or used at all).
      • bayindirh 1y ago
        JPEG is no different. Only the decoder is specified. As long as the decoder decodes what you give it to the image you wanted to see, you can implement anything. This is how imgoptim/squash/aerate/dietJPG works. By (ab)using this flexibility. Same is also true for the most advanced codecs. MPEG-* family and MP3 comes to my mind. Nothing stops PNG from defining a "set of decoders", and let implementers loose on that spec to develop encoders which generate valid files. Then developers can go to town with their creativity.
  • mrheosuper 1y ago
    Does usb-c spec break backward compatibility ?, a 2018 macbook work perfectly fine with 2025 usb c charger
    • techpression 1y ago
      I don’t know if it’s the spec or just a plethora of vendors that ignores it, but I have many things with a USB-C port that requires USB-A as source. USB-C to A to C works, yay dongles, but not just C to C. So maybe it’s not really breaking backwards compatibility, just a weird mix of a port and the communication being separate standards.
      • mrheosuper 1y ago
        because those usb-c ports do not follow the spec. If they had followed the spec from 1st day there would be no problem even now.
      • fragmede 1y ago
        it's vendors just changing the physical port but not updating the electronics. specifically, a 5.1kΩ pull-up resistors on the CC1 and/or CC pins is needed on the host (was usb-a) side in order for the c to c cable to work.
    • danielheath 1y ago
      Some things don't work unless you use the right kind of USB-C cable. EG your GPU and monitor both have a USB-C port. Plug them together with the right USB cable and you'll get images displayed. Plug them together with the wrong USB cable and you won't. USB 3 didn't have this issue - every cable worked with every port.
      • mrheosuper 1y ago
        That is not backward compatible problem. If a cable that does 100w charging when using pd2.0, but only 60w when using with pd3.1 device, then i would agree with you.
  • bmacho 1y ago
    +1 why not name it png4 or something. It's better if compatibility is obvious upfront
    • josephg 1y ago
      I think if they did that, nobody would use it. And anyway, from the article: > Many of the programs you use already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer... It might be too late to rename png to .png4 or something. It sounds like we're using the new png standard already in a lot of our software.
  • jillesvangurp 1y ago
    Old PNGs will work just fine. And forward compatibility is much less important. The main use case for PNG is web browsers and all of them seem to be on board. Using old web browsers is a bad idea. You do get these relics showing up using some old version of internet explorer. But some images not rendering is the least of their problems. The main challenge is actually going to be updating graphics tools to export the new files. And teaching people that sRGB maybe isn't good enough any more. That's going to be hard since most people have no clue about color spaces. Anyway, that gives everybody plenty of time to upgrade. By the time this stuff is widely used, it will be widely supported. So, you kind of get forward compatibility that way. Your browser already supports the new format. Your image editor probably doesn't.
    • AlienRobot 1y ago
      >The main use case for PNG is web browsers This is news to me. I'm pretty sure the main use case for PNG is lossless transparent graphics.
      • asadotzler 1y ago
        Depends on whose use cases you're considering. There are about 3.6 billion people surfing the web and experiencing PNGs. That use case, consuming PNGs, seems to dwarf the perhaps 100 million (somewhat wild guess) graphic designers, web developers, and photo editing professionals who manipulate images for publishing (in any medium) or archiving. If, on the other hand, you're considering the use cases envisioned by PNG's creators, or the use cases that interest the people processing or publishing images, yes, these people are focused on format itself and its capabilities. I suspect this particular use of "use case" isn't terribly clear. Also these two considerations are not incompatible.
    • deleted 1y ago
      [deleted]
    • hnlmorg 1y ago
      Browsers aren't the only software that work with PNGs. Far from it in fact.
  • ajnin 1y ago
    What backward compatibility are we talking about here? Backwards compatibility of images will be fine, backwards compatibility of decoders might be impacted, but the article says the major image viewers (browsers) and image editors already support the 3rd version. Better compression is only planned for the 5th version of the spec. Also if you forbid evolving existing formats, the only alternative to improve is to introduce a new format, and I argue that it would be causing even more fragmentation and be more difficult to adopt to. Look at all the drama surrounding JPEG XL.
  • altairprime 1y ago
    They could, for example, use lossy compression for the compatibility layer and then fill it in the rest of the way to lossless using incompatible new compression objects. Legacy uses will see some fidelity degradation, but they are already being stuck with sRGB downmixes, so that’s fine — and those who are bothered by it can just emit a lossless-pixels (but lossy-color and lossy-range) compatibility layer and reserve the compression benefits for the color and dynamic range. I’m not saying this is what will happen — but if I was able to construct a plausible approach to compression in ten minutes, then perhaps it’s a bit early to predict the doom of compatibility.
  • bawolff 1y ago
    I don't think that will super be an issue. How often has "progressive jpeg" ever caused problems? That's the same thing.
  • ProgramMax 1y ago
    Worry not! (Well, worry a little.) The first bit of our research is "What can we already make use of which requires no spec update? There are plenty of PNG optimizers. How much of that should go into the typical PNG libraries?" Same with parallel encoding & decoding. An older image viewer will be able to decode it on one thread without ever knowing parallel decoding was an option. Here's the worry-a-little part: Everybody immediately jumps to file size as to what image compression is better or worse. That isn't the best take, but it is what it is. So there is pressure to adopt newer technologies. We often do have a way to maintain some degree of backwards compatibility even when we do this. For example, we can store a downsampled image for old viewers. Then extra, new chunks will know "Mix that with this full scale data, using a different compression". As you can imagine, this mixing complicates things. It might not be the best option. Sooooo we're researching it :)
    • ori_b 1y ago
      My strong vote is to just not touch it. Stability is a feature.
    • HexDecOctBin 1y ago
      Downsampling will make PNG not be a lossless format. Just leave it alone, and work on a separate PNG2 or PNGX or whatever.
• LegionMammal978 1y ago
  Reading the linked blog post on the new cICP chunk type [0], it looks like the "proper HDR support" isn't something that you couldn't already do with an embedded ICC profile, but instead a much-abbreviated form of the colorspace information suitable for small image files. [0] https://svgees.us/blog/cICP.html https://svgees.us/blog/cICP.html
  • cormorant 1y ago
    "common but not representable RGB spaces like Adobe 1998 RGB or ProPhoto RGB cannot use CICP and have to be identified with ICC profiles instead." cICP is 16 bytes for identifying one out of a "list of known spaces" but they chose not to include a couple of the most common ones. Off to a great start... I wonder if it's some kind of legal issue with Adobe. That would also explain why EXIF / DCF refer to Adobe RGB only by the euphemism "optional color space" or "option file". [1] [1] https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_system#DCF_objects https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_sy...
    • spider-mario 1y ago
      CICP (H.273) originates from the video world, where Adobe RGB and ProPhoto RGB really aren’t common.
  • ProgramMax 1y ago
    PNG previously supported ICC v2. That was updated to ICC v4. However, neither of these are capable of HDR. Maybe iccMAX supports HDR. I'm not sure. In either case, that isn't what PNG supported. So something new was required for HDR.
    • LegionMammal978 1y ago
      > However, neither of these are capable of HDR. How so? As far as I can tell, the ICCv2 spec is very agnostic as to the gamut and dynamic range of the output medium. It doesn't say anything to the extent of "thou shalt not produce any colors outside the sRGB gamut, nor make the white point too bright". Unless HDR support is supposed to be something other than just the primaries, white point, and transfer function. All the breathless blogspam about HDR doesn't make it very clear what it means in terms of colorspaces.
• albert_e 1y ago
  So animated GIFs can be replaced by Animated PNGs with alpha blending with transparent backgrounds and lossless compression! Some nostalgia from 2000s websites can be revived and relived :) Curious if Animated SVGs are also a thing. I remember seeing some Javascript based SVG animations (it was a animated chatbot avatar) - but not sure if there is any standard framework.
  • andsoitis 1y ago
    > Curious if Animated SVGs are also a thing. Yes. Relevant animation elements: • <set> • <animate> • <animateTransform> • <animateMotion> See https://www.w3schools.com/graphics/svg_animation.asp https://www.w3schools.com/graphics/svg_animation.asp
    • mattigames 1y ago
      Overshadowed by CSS animations for almost all use cases.
      • lawik 1y ago
        But animated gradient outlines on text is the only use-case I care about.
        • mattigames 1y ago
          "Use case" is written without hyphen https://en.m.wikipedia.org/wiki/Use_case https://en.m.wikipedia.org/wiki/Use_case
          • fkyoureadthedoc 1y ago
            I have to differentiate myself from LLMs by using words wrong though
          • WorldMaker 1y ago
            Hyphenation of multi-word nouns is a process in English that usually happens after some time of usage as separate words. It often happens before eventually merger into a single compound word noun. Such as: "Electronic Mail" to "E Mail" to "e-mail" to "email". Given how often it is used as a jargon term in software development, I can absolutely see this usage of "use-case" here as a "vote" for the next step in the process. Will we eventually see "usecase" become common? It's possible. I think it might even be a good idea. I'm debating adding my own "votes" for the hyphen moving forward.
• adgjlsfhk1 1y ago
  I'm very curious to see how this will end up stacking up vs lossless jpegxl
  • Simran-B 1y ago
    I doubt it can get anywhere near. What is even the point of a new PNG version if there's something as advanced as JXL that is also royalty-free?
    • layer8 1y ago
      Browser support for JPEG XL is poor (basically only Safari I think), while the new PNG spec is already supported by all mainstream browsers.
      • encom 1y ago
        It's poor, only because Google is using their stranglehold on browsers, to push their own WebP trash. That company can't get broken up soon enough.
        • layer8 1y ago
          Firefox also doesn’t support JPEG XL out of the box, and Chrome does support the new PNG, so ¯\_(ツ)_/¯.
          • trallnag 1y ago
            How about renaming JPEG XL to PNG or just merging the complete spec into PNG 3.0?
          • account42 1y ago
            Firefox is there to prevent/delay the forced breakup of Googles monopoly no to provide any real competition, thanks for showing another example of that.
  • LoganDark 1y ago
• qwertox 1y ago
  > Officially supports Exif data Probably the best news here. While you already can write custom data into a header, having Exif is good. BTW: Does Exif have a magnetometer (rotation) and acceleration (gravity) field? I often wonder about why Google isn't saving this information in the images which the camera app saves. It could help so much with post-processing, like with leveling the horizon or creating panoramas.
  • andsoitis 1y ago
    There is no standard field to record readouts of a camera's accelerometers or inertial navigation system. Exif fields: https://exiv2.org/tags.html https://exiv2.org/tags.html
  • Aardwolf 1y ago
    Exif can also cause confusion for how to render the image: should its rotation be applied or not? Old decoders and new decoders now could render an image with exif rotation differently since it's an optional chunk that can be ignored, and even for new decoders, the spec lists no decoder recommendations for how to use the exif rotation It does say "It is recommended that unless a decoder has independent knowledge of the validity of the Exif data, the data should be considered to be of historical value only.", so hopefully the rotation will not be used by renderers, but it's only a vague recommendation, there's no strict "don't rotate the image" which would be the only backwards compatible way With jpeg's exif, there have also been bugs with the rotation being applied twice, e.g. desktop environment and underlying library both doing it independently
    • DidYaWipe 1y ago
      The stupid thing is that any device with an orientation sensor is still writing images the wrong way and then setting a flag, expecting every viewing application to rotate the image. The camera knows which way it's oriented, so it should just write the pixels out in the correct order. Write the upper-left pixel first. Then the next one. And so on. WTF.
      • 1y ago
• ggm 1y ago
  Somebody needs to manage human time/date approximates in a way other people in s/w will align to. "photo scanned in 2025, is about something in easter, before 1940 and after 1920"
  • SchemaLoad 1y ago
    The issue that gets me is that Google Photos and Apple photos will let you manually pick a date, but they won't actually set it in the photo EXIF, so when you move platforms. All of the images that came from scans/sent without EXIF lose their dates.
    • ggm 1y ago
      It's in sidecar files. Takeout gets them, some tools read them.
      • kccqzy 1y ago
        But there is no standardization of sidecar files, no? Whereas EXIF is pretty standard.
        • jeroenhd 1y ago
          EXIF inside of PNGs is new. You can make it work by embedding structured chunks into the file, but it's not official in any way (well, not until the new spec, at least). Sidecar files have some kind of interoperable format that at least don't break buggy PNG parsers when you open the image file. The sidecar files themselves differ in format, but at least they're usually formatted according to their extension. The usual sidecar files, XMP files, are standardised (in that they follow a certain extensible XML structure) and can (and often do) include EXIF file information.
          • SchemaLoad 1y ago
            Pretty much all the photos in Apple/Google photos are going to be JPEG and HEIF which do support EXIF. But both services basically will not touch what came out of the camera at all. If you add a description or date, it gets stored externally to the image so when you export your data, those changes are lost. Or they get dumped in a JSON file requiring you to use some custom script to handle it.
• nektro 1y ago
  cautiously optimistic. the thing that makes png so sought after is its status as frozen
• kumarvvr 1y ago
  Never heard about Animated PNGs, and I am a nerd to the core. Pleasantly surprised.
  • spauldo 1y ago
    Animation was an early feature, actually. It was called "MNG" and was developed alongside PNG. I don't know the details of why but it never really saw adoption outside of Firefox and was eventually removed even from there. APNG is different from MNG and came much later.
• Joel_Mckay 1y ago
  DaVinci Resolve also supports OpenEXR format with the added magic of LUT. PNG is popular with some Commercial Application developers, but the exposure and color problems still look 1980's awful in some use-cases. Even after spending a few grand on seats for a project, one still gets arrogant 3D clown-ware vendors telling people how they should run their pipeline with PNG hot garbage as input. People should choose EXR more often, and pick a consistent color standard. PNG does not need yet another awful encoding option. =3
  • morjom 1y ago
    What are some "consistent color standards" you'd recommend? Honest question.
    • Joel_Mckay 1y ago
      Like all complex questions, the answer is it depends on the target project and or Display. A very basic rec.709 workflow tutorial: https://www.youtube.com/watch?v=lf8COHAgHJs https://www.youtube.com/watch?v=lf8COHAgHJs The Andreas Dürr LUT pack: https://www.youtube.com/watch?v=dDKK54CeXgM https://www.youtube.com/watch?v=dDKK54CeXgM https://cinematiccookie.gumroad.com/l/bseftb?layout=profile https://cinematiccookie.gumroad.com/l/bseftb?layout=profile The calibration workflows also depend heavily on what is being rendered, source application(s), and the desired content look. There were some common free packs on github for popular programs at one time. Should still be around someplace... good luck. =3
  • DidYaWipe 1y ago
    "PNG is popular with some Commercial Application developers, but the exposure and color problems still look 1980's awful in some use-cases." What are you talking about? It's a bitmap. It has nothing to do with "exposure and color problems."
    • Joel_Mckay 1y ago
      In general, with some applications people hit the limits pretty quickly with PNG and JPG. In our use-case, the EXR format essentially meant a rendered part of the source image wouldn't be "overexposed" by the render pipeline, and layers could be later adjusted to better match in Resolve. Example: your scenes fireball simulation won't look like a fried egg photo from 1980 due to hitting 0xFF. If you've never encountered the use-case, than don't worry about the aesthetics. Seriously, many vendors also just don't care... especially after they already were paid. Best of luck =3
• tonyedgecombe 1y ago
  >After 20 years of stagnation, PNG is back with renewed vigor! After 20 years of success, we can't resist the temptation to mess with what works.
  • encom 1y ago
    Yea I'm mildly concerned about this as well. PNG's age is a feature, in a time where software development has gone to hell.
    • HelloNurse 1y ago
      Without the new HDR and color profile handling, PNG was still useful but significantly obsolete. Display hardware has progressed over a few decades, raising the bar for image files.
      • encom 1y ago
        >Display hardware has progressed It has, but WWW is still de facto sRGB, and will be for a long time still. But again, I'm not strictly opposed to evolving PNG, I just hope they don't ruin it in the process, because that's usually what happens when something gets update for a modern audience. I'll be watching with mixed optimism and concern.
        • jeroenhd 1y ago
          Plenty of JPGs on the web are already in HDR and you wouldn't notice it if you don't have a HDR capable display. The same is true for PNGs.
      • jeroenhd 1y ago
        > Display hardware has progressed The continued popularity of non-HDR 1080p screens on laptops is a bleak reminder that most people would rather save a couple hundred bucks than buy HDR capable hardware. HDR is great for TVs and a nice-to-have on phones (who mostly get it for free because OLEDs are the norm these days), but display technology only advances as much as its availability in low-cost devices.
• jbverschoor 1y ago
  What if we kind of fit JXL in PNG? That way it's more likely to be supported
• iliketrains 1y ago
  Official support for animations, yes! This feels so nostalgic to me, I have written an L-system generator with support for exporting animated PNGs 11 years ago! They were working only in Firefox, and Chrome used to have an extension for them. Too bad I had to take the website down. Back then, there were no libraries in C# for it, but it's actually quite easy to make APNG from PNGs directly by writing chunks with correct headers, no encoders needed (assuming PNGs are already encoded as input). https://github.com/NightElfik/Malsys/blob/master/src/Malsys.BitmapRenderers/Components/PngAnimationRenderer.cs https://github.com/NightElfik/Malsys/blob/master/src/Malsys.... https://marekfiser.com/projects/malsys-mareks-lsystems/ https://marekfiser.com/projects/malsys-mareks-lsystems/
  • chithanh 1y ago
    > Official support for animations, yes! While I welcome that there is now PNG with animations, I am less impressed about how Mozilla chose to push for it. Using PNG's magic numbers and pretend to existing software that it is just normal PNG? That is the same mindset that lead to HTML becoming tag soup. After all, HTML with a <blink> tag is still HTML, no? I think they could have achieved animated PNG standardization much faster with a more humble and careful approach.
• hrydgard 1y ago
  What about implementations? libpng seems pretty dead, 1.7 has been in development forever but 1.6 is still considered the stable version. Is there a current "canonical" png C/C++ library?
  • vanderZwan 1y ago
    I mean, if the spec has been stable for two decades then maybe there just hasn't been much to fix? Especially since PNG is a relatively simple image format.
    • illiac786 1y ago
      Seems that logic does not apply to jpeg though.
  • deleted 1y ago
    [deleted]
  • ethan_smith 1y ago
    For modern C/C++ PNG implementations, consider lodepng (header-only), stb_image/stb_image_write (single-file), or libspng (active fork focused on performance and security) as more actively maintained alternatives to libpng.
  • ProgramMax 1y ago
    libpng updates are either already landed or nearly landed.
• defraudbah 1y ago
  this is good news, any packages who support new png standard or planning to? rust/go/python/js?
• guilbep 1y ago
  Let's call it PPNG: Pas Portable NetWork Graphic
• b0a04gl 1y ago
  it's more to do with the obvious economic layer underneath. you give a format new life only if there's tooling and distribution muscle behind it. adobe, apple, chrome, ffmpeg etc may not get aligned at the same time. someone somewhere wants apng/hdr/png to be a standard pipe again for creative chains; maybe because video formats are too bulky for microinteraction or maybe because svg is too unsafe in sandboxed renderers. and think onboarding of animations, embedded previews, rich avatars, system wide thumbs ; all without shipping a separate codec or runtime. every time a 'dead' format comes back, it's usually because someone needed a way around a gate
  • ProgramMax 1y ago
    In general, I support the "follow the money" idea. But I don't think it applies here. I'm retired and making zero money here. (I'm actually losing money on it. Wish I had a company sponsoring me for the flights and hotels for meetups.) All participants are required to not patent any piece of it. We work hard to make sure we only reference open standards. (This one is quite tricky. We have to convince other standard orgs to make their stuff free.) I could see the argument for getting around a gate. But fwiw I don't think that's the case :)
• neepi 1y ago
  Oh no another HEIC!
• Dwedit 1y ago
  If you wanted better compression, it's called Lossless WEBP. Lossless WEBP is such a nice codec. Compared with Lossless JXL, it decompresses many times more quickly, and while JXL usually produces a smaller file, it doesn't always. Lossless AVIF is not competitive. However, lossless WEBP does not support indexed color images. If you need palettes, you're stuck with PNG for now.
  • altairprime 1y ago
    I look forward to seeing what PNG v5 does in the future with compression, especially relative to existing formats.
  • ansgri 1y ago
    How's HDR and high bit depth support? One of the things I liked about JXL is wide range of bit depths and arbitrary number of channels.
  • rurban 1y ago
    And the JXL api is a nightmare, compared to WEBP.
    • Dwedit 1y ago
      Yeah, the whole "subscribe to events then check a status result" thing is pretty bad. This is compounded by "Box" behaving differently than everything else. When I made JxlSharp (C# JXL library wrapper), I had to add a workaround in there to force Box to behave like all the other event subscriptions. And buffer sizes aren't handled in a good way. You have to provide pre-allocated memory, guessing how big it is supposed to be. Then you get a "not big enough" error. This is a guessing game, not a good design. You're forced to overshoot, then shrink the buffer afterwards. --- In different APIs, there tends to be a function you call to get the required buffer size. For example, many Win32 API functions make you call them with a buffer size of 0, then you get the actual required size back. Another possibility is having the library allocate the memory, and return the allocated buffer to you. Since cross-module memory management is hairy (different `malloc` implementations can't interoperate), some APIs let you provide the `malloc`, `realloc`, and `free` functions.
• snickerbockers 1y ago
  It was gone??? Was I the only one using it this entire time?
• meindnoch 1y ago
  Parallel compression/decompression is already possible via Z_SYNC_FLUSH.
  • Retr0id 1y ago
    Parallel decompression of Z_SYNC_FLUSH'd data is not possible without additional metadata to tell you where the sync points are.
    • meindnoch 1y ago
      True. Although this can be mitigated in a backwards compatible manner, by adding a new PNG chunk that points to the locations of the sync points.
      • Retr0id 1y ago
        Yes, such a chunk is being considered for introduction in future PNG revisions.
• sylware 1y ago
  Until everything new is "optional". Hopefully PNG won't be the target of "enshitification". We all know that for file formats, there is a very strong pressure from developers and vendors for that to happen since it favors, hard, vendor and developer lock-in. If not careful, even with a team of PHD devs won't be able to write alternatives encoders/decoders that "reasonbly" and the world will end-up with very few alternatives implementations, if not only one. I did skim through the specs, it seems most of it is related to cleanup and optional blocks, so it seems PNG is still safe, am I wrong? (asking those who did dive into the new specs deeply).
  • ProgramMax 1y ago
    Everything new is optional. This is not a breaking change. Old PNGs and software continue to work just fine. And these new changes are backwards-compatible as much as they can be. So old software can display a new PNG and be mostly correct. By that I mean, the user will still say "it is a picture of a red apple". But if the software isn't HDR, they might not get the bright highlights and inky blacks of the HDR PNG.
    • sylware 1y ago
      What is the remaining pertinent value of HDR since we are moving towards xrgb16161616 pixel format?
• antirez 1y ago
  PNG: doing very little with as much complexity as possible.
  • LeoPanthera 1y ago
    You’re going to be shocked when you find out how webp works.
    • qwertfisch 1y ago
      Because that’s a video compression format, from where only a single intra-frame is used.
• poisonborz 1y ago
  Not backwards compatible. We just add it to that nice cupboard "great advanced image formats we will forget about". Society doesn't need a new image format. I'd wager to say not any new multimedia format. Big corporate entites do, and have churning them out at a steady pace. Look at poor webp - a format pushed by the largest industry players - and the abysmal everyday use it gets, and the hate it generates.
  • Etheryte 1y ago
    I don't really think this is the case here. All major browsers already support the new spec for example. This isn't a case of oh we'll have support for it eventually, it's already there.
  • michaelmior 1y ago
    > and the abysmal everyday use it gets Estimates are that 95% of Internet users have a browser that supports WebP and that ~25% of the top million websites serve WebP images. I wouldn't call that abysmal.
    • hsbauauvhabzb 1y ago
      My file manager can’t handle them but my browser can. Edit: and good luck uploading the format to the majority of webforms that aren’t faang.
      • debugnik 1y ago
        Not even Google supports webp uploads in many of their web apps, and it's their format.
        • chillingeffect 1y ago
          Could it be a lack of resources? Or some missing expertise? Maybe they could find some interns who are familiar with it? Maybe the entire world is so obsessed w AI, we don't even care about image formats anymore.
• Padriac 1y ago
  I thought this was about Papua New Guinea.
• ksec 1y ago
  It is just a spec on something widely implemented already. Assuming Next gen PNG will still require new decoder. They could just call it PNG2. JPEG-XL already provides everything most people asked for a lossless codec. If there are any problems it is its encoding and decoding speed and resources. Current champion of Lossless image codec is HALIC. https://news.ycombinator.com/item?id=38990568 https://news.ycombinator.com/item?id=38990568
  • klabb3 1y ago
    What about transparency? That’s the main benefit of PNG imo.
    • cmiller1 1y ago
      Yes JPEG-XL has an alpha channel.
  • illiac786 1y ago
    > If there are any problems it is its encoding and decoding speed and resources. And this will improve over time, like jpg encoders and decoders did.
    • ksec 1y ago
      I hope I am very wrong but this isn't given. In the past reference encoder and decoder do not concern about speed and resources, but last 10 years have shown most reference encoder and decoder has already put considerable effort into speed optimisation. And it seems people are already looking to hardware JPEG XL implementation. ( I hope and guess this is for Lossless only )
      • illiac786 1y ago
        I would agree we will see less improvements that when comparing modern jpeg implementation and the reference one. When it comes to hardware encoding/decoding, I am not following your point I think. The fact that some are already looking at hardware implementation for JPEG XL means that….? I just know JPEG hardware acceleration is quite common, hence I am trying to understand how that makes JPEG XL different/better/worse?
• leviathan1 1y ago
  Not backwards compatible I think
  • ProgramMax 1y ago
    It is very backwards compatible. :) We worked hard to make sure it would be.
• 369548684892826 1y ago
  A fun fact about PNG, the correct pronunciation is defined in the specification > PNG is pronounced “ping” See the end of Section 1 [0] 0: https://www.w3.org/TR/REC-png.pdf https://www.w3.org/TR/REC-png.pdf
  • gred 1y ago
    That makes two image format names which I will refuse to pronounce correctly (the other being GIF [1]). [1] https://edition.cnn.com/2013/05/22/tech/web/pronounce-gif https://edition.cnn.com/2013/05/22/tech/web/pronounce-gif
    • cmiller1 1y ago
      How do you pronounce PNG?
      • gred 1y ago
        Pee En Gee
      • illiac786 1y ago
        P&G, stands for Pee & Gloat.
        • gred 1y ago
          Portable & Graphical
      • NoMoreNicksLeft 1y ago
        "Pong". Hate me, I don't care.
      • kristopolous 1y ago
        I used to call them Nogs claiming the P was silent. People believed me. Still funny.
    • ziml77 1y ago
• qwertfisch 1y ago
  Seems a bit too late? And also, JPEG XL supports all the features and uses already advanced compression (finite-state entropy, like ZStandard). It offers lossy and lossless compression, animated pictures, HDR, EXIF etc. There is just no need for a PNG update, just adopt JPEG XL.
  • Aachen 1y ago
    > advanced compression (finite-state entropy, like ZStandard) I've not tried it on images, but wouldn't zstandard be exceedingly bad at gradients? It completely fails to compress numbers that change at a fixed rate Bzip2 does that fine, not sure why https://chaos.social/@luc/114531687791022934 https://chaos.social/@luc/114531687791022934 The two variables (inner and outer loop) could be two color channels that change at different rates. Real-world data will never be a clean i++ like it is here, but more noise surely isn't going to help the algorithm compared to this clean example
    • Retr0id 1y ago
      zlib/deflate already has the same issue. It is mitigated somewhat by PNG row filters.
    • adgjlsfhk1 1y ago
      the FSE layer isn't responsible for finding these sorts of patterns in an image codec. The domain modeling turns that sort of pattern into repeated data and then the FSE goes to town on the output.
    • wongarsu 1y ago
      PNG's basic idea is to store the difference between the current pixel and the pixel above it, left of it or to the top-left (chosen once per row), then apply standard deflate compression to that. The first step basically turns gradients into repeating patterns of small numbers, which compress great. You can get decent improvements by just switching deflate for zstd
      • Aachen 1y ago
• ccarnino 1y ago
  I can't believe the standard is 20yo.
• naikrovek 1y ago
  Doesn’t PNG already support 16 bits per color channel and an arbitrary number of color channels?
  • ProgramMax 1y ago
    16-bit, yes. Arbitrary channel count, no. However, HDR is more than just bitcount.
• shitpostbot 1y ago
  [dead]
• deleted 1y ago
  [deleted]
• deleted 1y ago
  [deleted]
• aizk 1y ago
  20 years?? What took so long.
• eabeezxjc 1y ago
  we need transparent (like gif) !!!
  • ProgramMax 1y ago
    PNGs have supported transparency since day 1 :)
• elitegolfhub 1y ago
  [dead]
• cptcobalt 1y ago
  It seems like this new PNG spec just cements what exists already, great! The best codecs are the ones that work on everything. PNG and JPEG work everywhere, reliably. Try opening a HEIC or AV1 or something on a machine that doesn't natively support it down to the OS-level, and you're in for a bad time. This stuff needs to work everywhere—in every app, in the OS shell for quick-looking at files, in APIs, on Linux, etc. If a codec does not function at that level, it is not functional for wider use and should not be a default for any platform.
  • lazide 1y ago
    This new spec will make PNG even worse than HEIC or AV1 - you won’t know what codec is actually inside the PNG until you open it.
    • hulitu 1y ago
      > you won’t know what codec is actually inside the PNG until you open it. But this is a feature. Think about all those exploits made possible by this feature. Sincerely, the CIA, the MI-6, the FSB, the Mossad, etc.
      • lazide 1y ago
        The more practical concern is that like AVI you can’t tell if you can read it until you try, which makes it a nightmare especially with codec rot.
  • ecshafer 1y ago
    I work with a LOT of images in a lot of image formats, many including extremely niche formats used in specific fields. There is a massive challenge in really supporting all of these, especially when you get down to the fact that some specs are a little looser than others. Even libraries can be very rough, since sure it says on the tin it supports JPG and TIF and HEIC... but does it support a 30GB Jpeg? Does it support all possibly meta data in the file?
• remram 1y ago
  So what do we call it? PNG3? The spec is titled "Portable Network Graphics Specification (Third Edition)". Surely they aren't releasing a new, incompatible version and expecting us to pretend it's the same format...? > This updates the existing image/png Internet Media type whyyyyyyy
  • ProgramMax 1y ago
    New? Yes. Incompatible? No. We went to pretty extreme lengths to make sure old software worked with the new changes. Effectively, the limit will be the software, not the image. For example, you can imagine some old software that is unaware of color spaces and treats everything as sRGB. There is nothing we can do to make that software show a Display P3 correctly. However, we can still show the image well enough that a user understands "that is a red apple".
    • account42 1y ago
      Having images show up in washed up colors without any indication is not what I'd consider "working". This mistake has been made many times, please let's not make it again.
• joshmarinacci 1y ago
  A fun trick I do with my web based drawing tools is to save a JSON representation of your document as a comment field inside of a PNG. This way the doc you save is immediately usable as an image but can also be loaded back into the editor. Also means your downloads folder isn’t littered with unintelligible JSON files.
  • tomtom1337 1y ago
    Could you expand on this? It sounds a bit preposterous to save a text, as json, inside an image - and then expect it to be immediately usable… as an image?
    • behnamoh 1y ago
      no, GP meant they add the JSON text to the meta data of the image as comment.
    • bitpush 1y ago
      Not OP, but PNG (and most image/video formats) allows metadata and most allows arbitrary fields. Good parsers know to ignore/safely skip over fields that they are not familiar with. https://dev.exiv2.org/projects/exiv2/wiki/The_Metadata_in_PNG_files https://dev.exiv2.org/projects/exiv2/wiki/The_Metadata_in_PN... This is similar to HTTP request headers, if you're familiar with that. There are a set of standard headers (User-Agent, ETag etc) but nobody is stopping you from inventing x-tomtom and sending that along with HTTP request. And on the receiving end, you can parse and make use of it. Same thing with PNG here.
    • chown 1y ago
      Save text as JSON as comments but the file itself is a PNG so that you can use it as an image (like previewing it) as they would ignore the comments. However, the OP’s editor can load the file back, parse the comments, and get the original data and continue to edit. Just one file to maintain. Quite clever actually.
    • woodrowbarlow 1y ago
      this is useful for code that renders images (e.g. data-visualization tools). the image is the primary artifact of interest, but maybe it was generated from data represented in JSON format. by embedding the source data (invisibly) in the image, you can extract it later to modify and re-generate.
• razorfen 1y ago
  Can anyone explain how they maintain backwards compatibility on formats like this when adding features? I assume there are byte ranges managed in the format, but with things like compression, wouldn’t compressed images be unrenderable on clients that don’t support it? I suppose it would behoove servers to serve based on what the client would support.
  • jdhsddh 1y ago
    PNG is specifically designed to support this. Clients will simply skip chunks they do not understand. In this case there could be an embedded reduced colour space image next to an extended color space one
  • joshmarinacci 1y ago
    The PNG format has chunks with types. So you can add an additional chunk with a new type and existing decoders will ignore it. There is also some leeway for how encoding is done as long as you end up with a valid stream of bits at the end (called the bit stream format), so encoders can improve over time. This is common in video formats. I don’t know if a lossless image format would benefit much from that.
    • gmueckl 1y ago
      PNG is a bit unusual in that it allows a couple of alternate compressed encodings for the data that are all lossless. It is up to the encoder to choose between them (scanline by scanline, IIRC). So.this encoding algorithm leeway is implicit in a way.
  • gmueckl 1y ago
    In mynunderstanding, the actual image data encoding isn't altered in this update. It only introduces an extended color space definition for the encoded data. PNG is a highly structured file format internally. It borrows design ideas from formats like EA's Interchange File Format in that it contains lists of chunks with fixed headers encoding chunk type amd length. Decoders are expected to parse them and ignore chunk types they do not support.
• unit149 1y ago
  [dead]
• kfkdjajgjic 1y ago
  This is just rebranded MNG format that the PNG group tried to push as a ”standard” 20 years ago. Firefox removed MNG for a reason.
  • creatonez 1y ago
    I'm confused what aspect of this you're mad about. MNG is an animated format? Well, Firefox has supported APNG (Animated PNG) for the past 17 years without it ever being standardized and it has become extremely widely adopted. And... this new spec attempts to standardize it.
  • dveditz_ 1y ago
    Removed MNG and started work on APNG 20 years ago! https://bugzilla.mozilla.org/show_bug.cgi?id=257197 https://bugzilla.mozilla.org/show_bug.cgi?id=257197
• rynop 1y ago
  This is a false claim in the PR: > Many of the programs you use already support the new PNG spec: ... Photoshop, ... Photoshop does NOT support APNGs. The PR calls out APNg recognition as the 2nd bullet point of "What's new?" Am I missing something? Seems like a pretty big mistake. I was excited that an art tool with some marketshare finally supported it.
  • ProgramMax 1y ago
    Phoptoshop supports the HDR part. But you are right, it does not support the APNG part.
• ProgramMax 1y ago
  Author here. Hello everyone! Feel free to ask me anything. I'll go ahead and dispel some doubts I already see here: - It isn't really a "new format". It's an update to the existing format. - It is very backwards compatible. -- Old programs will load new PNGs to the best of their capability. A user will still know "that is a picture of a red apple". There also seems to be some confusion about how PNGs work internally. Short and sweet: - There are chunks of data. -- Chunks have a name, which says what data it contains. A program can skip a chunk it doesn't recognize. - There is only one image stream.
  • fwip 1y ago
    Do you have any examples on hand of PNGs that use the new features of the spec? It would be cool to see a little demo page with animated or HDR images, especially to download to test if our programs support them yet.
    • ProgramMax 1y ago
      Sure! Chris Lilley--one of the original PNG co-authors--has a post with an example HDR image: https://svgees.us/blog/cICP.html https://svgees.us/blog/cICP.html It is about half way down, with the birthday cake. Generally, us tech nerds have phones that are capable of displaying it well. So perhaps view the page on your phone. What you should look for is the cake, the pink tips in her hair, and the background being more vivid. For me, the pink in the cake was the big give-away. There is also the Web Platform Tests (WPT) which we use to validate browser support: https://wpt.fyi/results/png/cicp-chunk.html?label=master&label=experimental&aligned https://wpt.fyi/results/png/cicp-chunk.html?label=master&lab... Although, that image is just a boring teal. See it live in your browser here: https://wpt.live/png/cicp-chunk.html https://wpt.live/png/cicp-chunk.html For an example of APNG, you can use Wikipedia's images: https://en.wikipedia.org/wiki/APNG https://en.wikipedia.org/wiki/APNG But you have a bigger point: I should have live demonstrations of those things to help people understand.
      • fwip 1y ago
        Thanks, I appreciate all of these links. :)
• NotAnOtter 1y ago
  Can someone TLDR why I should care as someone who doesn't directly get into the weeds of this type of things? Is this written exactly for (1) people who implement/maintain this and, I say this with love, (2) nerds. Or will there be effects outside of a microscopic improvement on storage + latency.
  • spauldo 1y ago
    If you don't do much with images it's probably not anything you need to worry about. If you care about things like HDR, it means you can now use PNGs for that. If you work with graphics for a living, it's probably a good idea to learn what's changed in the standard. PNG was a huge deal when it was new, mostly because of all the headaches Unisys was giving everyone over GIF compression patents. This new standard is mostly of interest to people that have reason to care about what format their image data is in.
• jug 1y ago
  This is the first time I’ve seen HDR used to refer to wider color spaces and not extended brightness and contrast ratios.
  • ProgramMax 1y ago
    Yeah. I mentioned this elsewhere but repeating here: I designed the article to be accessible and understandable for the average person. So I took some liberties like showing only HDR primaries and not deep diving into HDR transfer functions. People understand the primaries intuitively. But you are right that a wide color image could also use those same primaries without being HDR. My goal was to be as truthful as possible while still being digestible at a glance. In the article, I linked to Chris Lilley's post which explains it more thoroughly for the technical people.
  • account42 1y ago
    Don't forget increased bit depths. You need all of these for a full HDR experience.
• nashashmi 1y ago
  Time is ripe for audio-included animated PNG files.
• bartwe 1y ago
  I'm worried that by supporting too many encodings and color spaces this will hamper adoption and unexpected unsupported files. Perhaps this is more of an encoder/decoder library issue, which hopefully will give us rec2020 rgb32/rgb10a2 encode/decode apis so we can simply use them without having to know so many details.
• 4ad 1y ago
  HDR is about, well, high dynamic range images, usually expressed with at least 10 bits of precision (although it can also be float, etc), and often, but not always encoding scene-referred data instead of image-referred data (originally it was supposed to only encode scene-referred data, but then other competing formats ignored that). It has nothing to do with the gamut and with the color primaries, although in practice HDR images use a large color space. But you can absolutely have an SDR image encoded using a large color space. So I am not sure why the author talks about color primaries when it tries to justify HDR… I still don’t know what kind of HDR images this new PNG variant can encode.