[HN Gopher] A new PNG spec
___________________________________________________________________
A new PNG spec
Author : bluedel
Score : 430 points
Date : 2025-06-24 13:01 UTC (1 days ago)
(HTM) web link (www.programmax.net)
(TXT) w3m dump (www.programmax.net)
| bravesoul2 wrote:
| Papua New Guniea never went away!
| LeoPanthera wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| That's what OptiPNG already does.
| josefx wrote:
| Doesn't OptiPNG just brute force various settings and pick
| the best result?
| lifthrasiir wrote:
| 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
| snvzz wrote:
| 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.
| Arnt wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Arnt wrote:
| We _would_ need a new media type. But the actual new features
| don 't need one, because the news don't break compatibility.
|
| https://svgees.us/blog/img/revoy-cICP-bt.2020.png uses the
| new colour space. If your software and monitor can handle it,
| you see better colour than I, otherwise, you see what I see.
| Lerc wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| cm2187 wrote:
| Video files aren't a good analogy. Before God placed VLC
| and ffmpeg on earth, you had to install a galaxy of
| codecs on your computer to get a chance to read a video
| file and you could never tell exactly what codec was
| stored in a container, nor if you had the right codec
| version. Unfortunately there is no vlc and ffmpeg for
| images (I mean there is, the likes of imagemagick, but
| the vast majority of software doesn't use them).
| bayindirh wrote:
| I lived through that era (first K-Lite Codec Pack, then
| CCCP came along), but still it holds.
|
| Proprietary or open, any visual codec is a battleground.
| Even in commercial settings, I vaguely remember people
| saying they prefer the end result of one encoder over
| another, for the same video/image format, not unlike how
| photographers judge cameras by their colors.
|
| So maybe, this flexibility to PNG will enable or
| encourage people to write better or at least unorthodox
| encoders which can be decoded by standard compliant ones.
| fc417fc802 wrote:
| I honestly don't see an issue with the mpeg-4 example.
|
| Regarding the potential for fragmentation of the png
| ecosystem the alternative is a new file format which has
| all the same support issues. Every time you author
| something you make a choice between legacy support and
| using new features.
|
| From a developer perspective, adding support for a new
| compression type is likely to be much easier than
| implementing logic for an entirely new format. It's also
| less surface area for bugs. In terms of libraries, support
| added to a dependency propagates to all consumers with zero
| additional effort. Meanwhile adding a new library for a new
| format is linear effort with respect to the number of
| programs.
| 7bit wrote:
| I never once in 25 years encountered an issue with an mp4
| Container that could Not be solved by installing either the
| divx or xvid codec. And I extensively used mp4's metatdat
| for music, even with esoteric Tags.
|
| Not Sure what youre talking abouz.
| Arnt wrote:
| He's saying that in 25 years, you used only the LC and HE
| profiles, and didn't encounter TwinVQ even once. I looked
| at my thousand-odd MPEG-4 files. They're overwhelmingly
| AAC LC, a little bit of AAC LC SBR, no TwinVQ at all.
|
| If you want to check yours: mediainfo **/*.mp4 | grep -A
| 2 '^Audio' | grep Format | sort | uniq -c
|
| https://en.wikipedia.org/wiki/TwinVQ#TwinVQ_in_MPEG-4
| tells the story of TwinVQ in MPEG-4.
| cm2187 wrote:
| But where the analogy with USB-C is very good is that just
| like USB-C, there is no way for a user to tell from the
| look of the port or the file extension what the
| capabilities are. Which even for a fairly tech savvy user
| like me is frustrating. I have a bunch of cables, some
| purchased years ago, how do I know what is fit for what?
|
| And now think of the younger generation that has grown up
| with smartphones and have been trained to not even know
| what a file is. I remember this story about senior high
| school students failing their school tests during covid
| because the school software didn't support heif files and
| they were changing the file extension to jpg to attempt to
| convert them.
|
| I have no trust the software ecosystem will adapt. For
| instance the standard libraries of the .net framework are
| fossilised in the world of multimedia as of 2008-ish. Don't
| believe heif is even supported to this day. So that's a
| whole bunch of code which, unless the developers create
| workarounds, will never support a newer png format.
| skissane wrote:
| > there is no way for a user to tell from the look of the
| port or the file extension what the capabilities are
|
| But that's typical for file extensions. Consider EXE - it
| is probably an executable, but an executable for what?
| Most commonly Windows - but which Windows version will
| this EXE run on? Maybe this EXE only works on Windows 11,
| and you are still running Windows 10. Or maybe you are
| running x86-64 Windows, but this EXE is actually for ARM
| or MIPS or Alpha. Or maybe it is for some other platform
| which uses that extension for executable files - such as
| DOS, OS/2, 16-bit Windows, Windows CE, OpenVMS, TOPS-10,
| TOPS-20, RSX-11...
|
| .html, .js, .css - suggest to use a web browser, but
| don't tell you whether they'll work with any particular
| one. Maybe they use the latest features but you use an
| old web browser which doesn't support them. Maybe they
| require deprecated proprietary extensions and so only
| work on some really old browser. Maybe this HTML page
| only works on Internet Explorer. Maybe instead of UTF-8
| it is in some obscure legacy character set which your
| browser doesn't support.
|
| .zip - supports extensible compression and encryption
| methods, your unzip utility might not support the methods
| used to compress/encrypt this particular zip file. This
| is actually normal for very old ZIP files (from the
| 1980s) - early versions of PKZIP used various deprecated
| compression mechanisms, which few contemporary unzip
| utilities support. The format was extended to 64-bit
| without changing the extension, there's still a lot of
| 32-bit only implementations out there. ZIP also supports
| platform-specific file attributes-e.g. PKZIP for z/OS
| creates ZIP files which contain metadata about mainframe
| data storage formats, unzip on another platform is going
| to have no idea what it means, but the metadata is
| actually essential to interpreting the data correctly
| (e.g. if RECFM=V you need to parse the RDWs, if RECFM=F
| there won't be any)
|
| .xml - okay, it is XML - but that tells you nothing about
| the actual schema. Maybe you were expecting this xml file
| to contain historical stock prices, but instead it is
| DocBook XML containing product documentation, and your
| market data viewer app chokes on it. Or maybe it really
| is historical stock prices, but you are using an old
| version of the app which doesn't support the new schema,
| so you can't view it. Or maybe someone generated it on a
| mainframe, but due to a misconfiguration the file came
| out in EBCDIC instead of ASCII, and your app doesn't know
| how to read EBCDIC, yet the mainframe version of the same
| app reads it fine...
|
| .doc - people assume it is legacy (pre-XML) Microsoft
| Word: every version of which changed the file format, old
| versions can't read files created with newer versions
| correctly or at all, conversely recent versions have
| dropped support for files created in older versions, e.g.
| current Office versions can't read DOC files created with
| Word for DOS any more... but back in the 1980s a lot of
| people used that extension for plain text files which
| contained documentation. And it was also used by
| incompatible proprietary word processors (e.g. IBM
| DisplayWrite) and also desktop publishing packages (e.g.
| FrameMaker, Interleaf)
|
| .xmi - I've seen this extension used for both XML Model
| Interchange (XML-based standard for exchanging UML
| diagrams) and XMIT (IBM mainframe file archive format).
| Because extensions aren't guaranteed to be unique, many
| incompatible file formats share the same extension
|
| .com - is it an MS-DOS program, or is it DCL (Digital
| Command Language)?
|
| .pic - probably some obscure image format, but there are
| dozens of possibilities
|
| .img - could be either a disk image or a visual image,
| either way dozens of incompatible formats which use that
| extension
|
| .db - nowadays most likely SQLite, but a number of
| completely incompatible database engines have also used
| this extension. And even if it is SQLite, maybe your
| version of SQLite is too old to read this file because it
| uses some features only found in newer versions. And even
| if SQLite can read it, maybe it has the wrong schema for
| your app, or maybe a newer version of the same schema
| which your old version that app doesn't support, or an
| old version of the schema which the current version of
| the app has dropped support for...
| Calzifer wrote:
| Just last week I had again some PDFs Okular could not
| open because of some more uncommon form features.
| cmiller1 wrote:
| > Consider EXE - it is probably an executable, but an
| executable for what? Most commonly Windows
|
| Has anyone ever used .exe for anything other than
| Windows?
| asgerhb wrote:
| Way back when, my prof was using his Linux machine to
| demonstrate how to use GCC. He called the end result .exe
| but that might have been for the benefit of the Windows
| users in the room. (Though Linux users being considerate
| to Windows users, or vice versa, is admittedly a rarity)
| skissane wrote:
| Prior to Windows 95, the vast majority of PC games were
| MS-DOS exe files - so anyone who played any of those
| games (whether back in their heyday, or more recently
| through DOSBox) has run an MS-DOS exe. Most people who
| ever used Lotus 1-2-3 or WordPerfect were running an MS-
| DOS exe. Both products were eventually ported to Windows,
| but were far less popular under Windows than under DOS.
|
| Under Windows 95/98/Me, most command line tools were MS-
| DOS executables. Their support for 32-bit Windows console
| apps was very poor, to the extent that the input and
| output of such apps was proxied through a 16-bit MS-DOS
| executable, conagent.exe
|
| First time in my life I ever used GNU Emacs, it was an
| OS/2 exe. That's also true for bash, ls, cat, gcc, man,
| less, etc... EMX was my gateway drug to Slackware
| cesarb wrote:
| > Has anyone ever used .exe for anything other than
| Windows?
|
| Did you know that Microsoft Windows originally ran on top
| of the much older MS-DOS, which used EXE files as one of
| its two executable formats? Most Windows users had lots
| and lots of EXE files which were not Windows executables,
| but instead DOS executables. And then came Windows 95,
| which introduced 32-bit Windows executables, but kept the
| same file extension as 16-bit Windows executables and
| 16-bit DOS executables.
| pvorb wrote:
| Extending the format just because you can - and breaking
| backwards compatibility along the way - is even more
| pointless.
|
| If you've created an extensible file format, but you never
| need to extend it, you've done everything right, I'd say.
| jajko wrote:
| What about an extensible format that would have as part of
| header an algorithm (in some recognized DSL) of how to
| decompress it (or any other step required for image
| manipulation)? I know its not so much about PNG but some
| future format.
|
| That's what I would call really extensible, but then there
| may be no limits and hacking/viruses could have easily a
| field day.
| lelanthran wrote:
| > What about an extensible format that would have as part
| of header an algorithm (in some recognized DSL) of how to
| decompress it (or any other step required for image
| manipulation)?
|
| Will sooner or later be used to implement RCEs. Even if
| you _could_ do a restriction as is done for eBPF, that
| code still has to execute.
|
| Best would be not to extend it.
| dooglius wrote:
| > Having an extensible format and electing never to extend it
| seems pointless.
|
| So then it was pointless for PNG to be extensible? Not sure
| what your argument is.
| chithanh wrote:
| > Adding another compression form should be handled by
| existing software
|
| In an ideal world, yes. In practice however, if some field
| doesn't change often, then software will start to assume that
| it never changes, and break when it does.
|
| TLS has learned this the hard way when they discovered that
| huge numbers of existing web servers have TLS version
| intolerance. So now TLS 1.2 is forever enshrined in the
| ClientHello.
| shiomiru wrote:
| The difference between valid PNG you can't decompress and
| invalid PNG is fairly irrelevant when your aim is to get an
| image onto the screen.
|
| And considering we already have plenty of more advanced
| competing lossless formats, I really don't see why "feed a
| BMP to deflate" needs a new, incompatible spin in 2025.
| fc417fc802 wrote:
| > plenty of more advanced competing lossless formats
|
| Other than JXL which still has somewhat spotty support in
| older software? TIFF comes to mind but AFAIK its size tends
| to be worse than PNG. Edit: Oh right OpenEXR as well. How
| widespread is support for that in common end user image
| viewer software though?
| Arnt wrote:
| It's a new and compatible spin.
| https://svgees.us/blog/img/revoy-cICP-bt.2020.png uses the
| important new feature and your old software can display it.
|
| More generally, PNG has a simple feature to specify what's
| needed. A file consists of a number of chunks, and one bit
| in the chunk specifies whether that chunk is required for
| display. All of the extensions I've seen in the past
| decades set that bit to "optional".
|
| For example, this update includes a chunk containing EXIF
| data. As you'd expect, the exif chunk sets that bit to
| "optional".
| HelloNurse wrote:
| Extensibility of PNG has been amply used, as intended, for
| proprietary chunks that hold application specific data (e.g.
| PICO-8 games) without bothering other software.
| Lerc wrote:
| Doesn't pico-8 store the data in the least significant bits
| of colour? Maybe it got updated to use chunks.
| colanderman wrote:
| 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.
| mrheosuper wrote:
| Does usb-c spec break backward compatibility ?, a 2018 macbook
| work perfectly fine with 2025 usb c charger
| techpression wrote:
| 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 wrote:
| 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 wrote:
| it's vendors just changing the physical port but not
| updating the electronics. specifically, a 5.1kO 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 wrote:
| 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 wrote:
| 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.
| yoz-y wrote:
| The problem is not backward compatibility but labeling. A
| USB-C cable looks universal but isn't. Some of them just
| charge, some do data, some do PD, some give you access to
| high speed. But there is no way to know.
|
| I believe the problem here is that you will have PNG
| images that "look" like you can open them but can't.
| mrheosuper wrote:
| the parent said "changing the compression algorithm will
| break backwards compatibility", which i assume is
| something works now won't work in the future. The usb-c
| spec is intentionally trying to avoid that.
| danielheath wrote:
| Today, I can save a PNG file off a random website and
| then open it.
|
| If PNG gets extended, it's entirely plausible that
| someone will view a PNG in their browser, save it, and
| then not be able to open the file they just saved.
|
| There are those who claim "backwards compatibility"
| doesn't cover "how you use it" - but roughly none of the
| people who now have to deal with broken software care
| about such semantic arguments. It used to work, and now
| it doesn't.
| johnisgood wrote:
| This is what I fear, too.
|
| Do they mention which C libraries use this spec?
| mrheosuper wrote:
| which is what usb-c spec has been avoiding so far. Even
| in USB4 spec, there are a lot of mentioning the new spec
| should be compatible with TB3 devices.
|
| USB-C spec is anything but breaking backward compatible.
| fc417fc802 wrote:
| The alternative is the website operator who wants to save
| on bandwidth instead adopts JXL or WEBP or what have you
| and ... the end user with old software still can't open
| it.
|
| It's a dichotomy. Either the provider accommodates users
| with older software or not. The file extension or
| internal headers don't change that reality.
|
| Another example, new versions of PDF can adopt all the
| bells and whistles in the world but I will still be
| saving anything intended to be long lived as 1/a which
| means I don't get to use any of those features.
| mystifyingpoi wrote:
| Cable labeling could fix 99% of the issues with USB-C
| compat. The solution should never be blaming consumer for
| buying the wrong cable. Crappy two-wire charge-only
| cables are perfectly fine for something like a night desk
| lamp. Keep the poor cables, they are okay, just tell me
| if that's the case.
| ay wrote:
| Same thing with PNG. Just call the format with new
| additions it PNGX, so the user can clearly see that the
| reason their software can't display the image is not a
| file corruption.
|
| This is just pretending that if you have a cat and a dog
| in two bags and you call it "a bag", it's one and the
| same thing...
| lelanthran wrote:
| > Cable labeling could fix 99% of the issues with USB-C
| compat.
|
| Labelling is a poor band-aid on the root problem -
| _consumer_ cables which look identical and fit
| identically should work wherever they fit.
|
| There should never have been a power-only spec for USB-C
| socket dimensions.
|
| If a cable supports both power and data, it must fit in
| all sockets. If a cable supports only power it must not
| fit into a power and data socket. If a cable supports
| only data, it should not fit into a power and data
| socket.
|
| It is possible to have designed the sockets under these
| constraints, with the caveat that they only go in one
| way. I feel that that would have been a better trade-off.
| Making them reversible means that you cannot have a
| design which enforces cable type.
| Xss3 wrote:
| So since my vape (example, i dont vape) has a power and
| data slot for charging and firmware updates, i should be
| limited to only using dual purpose cables day to day
| rather than a power only cable?
| lelanthran wrote:
| > So since my vape (example, i dont vape) has a power and
| data slot for charging and firmware updates, i should be
| limited to only using dual purpose cables day to day
| rather than a power only cable?
|
| Well, yes.
|
| Why _can 't_ you use a power+data cable for the vape (or
| whichever appliance takes both)? What's the deal-breaker
| here?
|
| The alternative is labeling, or plugging cables in to see
| if they do what you want them to do.
|
| Both are a poor user interface.
| Xss3 wrote:
| Is the same true for my laptop? Or soldering plate? Both
| take over 150w of power. Buying a power and data cable is
| expensive compared to just power, and the length of cable
| is severely limited...or the data speed impaired
| significantly. How slow does the data have to be for it
| to be non compliant?
| mystifyingpoi wrote:
| > If a cable supports only power it must not fit into a
| power and data socket
|
| That's even more confusing than the current state of
| affairs. If my phone has power and data socket, then I
| cannot use power only cable to only charge it? Presumably
| with the charger that has power only socket. So I need a
| cable with two different ends anyway. Just go micro-USB
| at this point :)
|
| Funnily enough, there is a 100% overkill way to solve
| such issues. Just use super expensive certified TB
| cables. Well... plus a A-to-C adapter for noncompliant
| devices, I guess.
| kevin_thibedeau wrote:
| Two wire cables are not in the specification, just like
| A-to-A cables aren't. The whole charging above 100mA with
| resistor hacks wasn't in the standard either until they
| had to grandfather it in. The implementers forum isn't
| responsible for non-members breaking their spec.
| globular-toast wrote:
| Some aren't even USB. Thunderbolt and DisplayPort both
| use USB-C too.
| Xss3 wrote:
| Thunderbolt meets usbc specs (and exceeds them afaik), so
| it is still usb...
| voidUpdate wrote:
| That's not just an issue with usb-c. normal usb a and b
| cables can have data or no data depending on how stingy
| the company wants to be, and you can't know until you
| test it
| Xss3 wrote:
| You can get pretty good guesses just by feel and length.
| Tiny with a super thin cable? Probably charge only.
| mystifyingpoi wrote:
| Yeah, I also don't think they've broken backwards compat
| ever. Super high end charger from 2024 can charge old
| equipment from 2014 just fine with regular 5V.
|
| What was broken was the promise of a "single cable to rule
| them all", partly due to manufacturers ignoring the
| requirements of USB-C (missing resistors or PD chips to
| negotiate voltages, requiring workarounds with A-to-C
| adapters), and a myriad of optional stuff, that might be
| supported or not, without a clear way to indicate it.
| zirgs wrote:
| Yeah - it's a mess. Some devices only charge with a charger
| that supports PD. Some other devices need a charger WITHOUT
| PD support.
| bmacho wrote:
| +1 why not name it png4 or something. It's better if
| compatibility is obvious upfront
| josephg wrote:
| 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 wrote:
| 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.
| hnlmorg wrote:
| Browsers aren't the only software that work with PNGs. Far
| from it in fact.
| AlienRobot wrote:
| >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 wrote:
| 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.
| whywhywhywhy wrote:
| > The main use case for PNG is web browsers
|
| It's not, most images you encounter on the web need better
| compression.
|
| The main PNG use case is to store lossless images locally as
| master copies that are then compressed or in workflows where
| you intend to edit and change them where compressed formats
| would degrade the more they were edited.
| ajnin wrote:
| 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 wrote:
| 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 wrote:
| I don't think that will super be an issue. How often has
| "progressive jpeg" ever caused problems? That's the same thing.
| ProgramMax wrote:
| 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 :)
| LegionMammal978 wrote:
| 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
| cormorant wrote:
| "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_sy...
| ProgramMax wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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
| mattigames wrote:
| Overshadowed by CSS animations for almost all use cases.
| lawik wrote:
| But animated gradient outlines on text is the only use-case
| I care about.
| mattigames wrote:
| "Use case" is written without hyphen
| https://en.m.wikipedia.org/wiki/Use_case
| fkyoureadthedoc wrote:
| I have to differentiate myself from LLMs by using words
| wrong though
| WorldMaker wrote:
| 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.
| albert_e wrote:
| Oh TIL - Thanks!
|
| This could possibly be used to build full fledged games like
| pong and breakout :)
| jerf wrote:
| SVG also supports Javascript, which will probably be a lot
| more useful for games.
| dveditz_ wrote:
| It supports JavaScript when used as a document, but when
| used as an "image" by a browser (IMG tag, CSS features)
| JavaScript and the loading of external resources are
| disabled.
| shakna wrote:
| Slightly related, I recently hit on this SVG animation bug in
| Chrome (that someone else found):
|
| https://shkspr.mobi/blog/2025/06/an-annoying-svg-
| animation-b...
| riffraff wrote:
| I was under the impression many gifs these days are actually
| served as soundless videos, as those basically compress better.
|
| Can animated PNG beat av1 or whatever?
| josephg wrote:
| I doubt it, given png is a lossless compression format. For
| video thats almost never what you want.
| DidYaWipe wrote:
| For animations with lots of regions of solid color it could
| do very well.
| layer8 wrote:
| APNG would be for lossless compression, and probably
| especially for animations without a constant frame rate.
| Similar to the original GIF format, with APNG you explicitly
| specify the duration of each individual frame, and you can
| also explicitly specify looping. This isn't for video, it's
| more for Flash-style animations, animated logos/icons [0], or
| UI screen recordings.
|
| [0] like for example these old Windows animations:
| https://www.randomnoun.com/wp/2013/10/27/windows-
| shell32-ani...
| fc417fc802 wrote:
| All valid points, however AV1 also supports lossless
| compression and is almost certainly going to win the file
| size competition against APNG every time.
|
| https://trac.ffmpeg.org/wiki/Encode/AV1#Losslessencoding
| meindnoch wrote:
| False, or misleading.
|
| The AV1 spec [1] does not allow RGB color spaces,
| therefore AV1 cannot preserve RGB animations in a bit-
| identical fashion.
|
| [1] https://aomediacodec.github.io/av1-spec/av1-spec.pdf
| pornel wrote:
| AV1 supports YCoCg, which encodes RGB losslessly.
|
| It is a bit-reversible rotation of the RGB cube. It makes
| the channels look more like luma and chroma that the
| codec expects.
| meindnoch wrote:
| False.
|
| 8-bit YCoCg (even when using the reversible YCoCg-R [1]
| scheme) cannot represent 8-bit RGB losslessly. The chroma
| channels would need 9 bits of precision to losslessly
| recover the original 8-bit RGB values.
|
| [1] https://www.microsoft.com/en-us/research/wp-
| content/uploads/...
| armada651 wrote:
| > Can animated PNG beat av1 or whatever?
|
| Animated PNGs can't beat GIF nevermind video compression
| algorithms.
| jeroenhd wrote:
| Once you add more than 256 different colours in total, GIF
| explodes in terms of file size. It's great for small,
| compact images with limited colour information, but it
| can't compete with APNG when the image becomes more
| detailed than what you'd find on Geocities.
| pornel wrote:
| No, APNG explodes in size in that case.
|
| In APNG it's either the same 256 colors for the whole
| animation, or you have to use 24-bit color. That makes
| the pixel data 3 times larger, which makes zlib's
| compression window effectively 3 times smaller, hurting
| compression.
|
| OTOH GIF can add 256 new colors with each frame, so it
| can exceed 256 colors without the cost of switching all
| the way to 16.7 million colors.
| Aissen wrote:
| > Animated PNGs can't beat GIF nevermind video compression
| algorithms.
|
| Not entirely true, it depends on what's being displayed,
| see a few simple tests specifically constructed to show how
| much better APNG can be vs GIF and {,lossy} webp:
| http://littlesvr.ca/apng/gif_apng_webp.html
|
| Of course I don't think it generalizes all that well...
| bmacho wrote:
| I tried these examples on ezgif, and indeed apng manages
| to be smaller than webp every single time. Weird, I was
| under the impression that webp was almost always smaller?
| Is this because GIF images are already special, or apng
| uses better compression than png?
|
| edit: using the same ezgif webp and apng on a H.264
| source, apng is suddenly 10x the size than webp. It seems
| apng is only better if the source is gif
| Aissen wrote:
| I have no idea! I actually hoped someone would show a
| much more comprehensive and serious benchmark in
| response, but that has failed to materialize.
| armada651 wrote:
| You're correct and I was considering adding a footnote
| that if you use indexed colors like a GIF then PNG can
| beat GIF due to better compression algorithms. But when
| most people think of APNG they think of lossless
| compression rather than lossy compression.
| fc417fc802 wrote:
| > many gifs these days are actually served as soundless
| videos
|
| That's not really true. Some websites lie to you by putting
| .gif in the address bar but then serving a file of a
| different type. File extensions are merely a convention and
| an address isn't a file name to begin with so the browser
| doesn't care about this attempt at end user deception one way
| or the other.
| faceplanted wrote:
| You said that's not really true and the described exactly
| how it's true, what did you mean?
| bawolff wrote:
| Its also because people like to "pause" animations, and that
| is not really an option with apng & gif.
| bigfishrunning wrote:
| why not? that's up to the program displaying the animation,
| not the animation itself -- i'm sure a pausable gif or apng
| display program is possible
| pornel wrote:
| It's absolutely possible. Browsers even routinely pause
| playback when images aren't visible on screen.
|
| They just don't have a proper UI and JS APIs exposed, and
| there's nothing stopping them from adding that.
|
| IMO browsers are just stuck with tech debt, and
| maintainin a no-longer-relevant distinction between
| "animations" and "videos". Every supported codec should
| work wherever GIF/APNG work and vice versa.
|
| It's not even a performance or complexity issue, e.g.
| browsers support AVIF "animations" as images, even though
| they're literally fully-featured AV1 videos, only wrapped
| in a "pretend I'm an image" metadata.
| joquarky wrote:
| I wish browsers still paused all animations when the user
| hits the Esc key. It's hard to read when there are
| distracting animations all over most pages.
| nextaccountic wrote:
| > They just don't have a proper UI and JS APIs exposed,
| and there's nothing stopping them from adding that.
|
| Browsers should just allow animated gifs and apngs in
| <video>
| jonhohle wrote:
| It seems crazy to think about, but I interviewed with a power
| company in 2003 that was building a web app with animated SVGs.
| bmacho wrote:
| > Curious if Animated SVGs are also a thing.
|
| SVG is just html5, it has full support for CSS, javascript with
| buttons, web workers, arbitrary fetch requests, and so on
| (obviously not supported by image viewers or allowed by
| browsers).
| bawolff wrote:
| Browsers support all that sort of thing, as long as you use
| an iframe. (Technically there are sone subtle differences
| between that and html5, but you are right its mostly the
| same)
|
| If you use an <img> tag, svgs are loaded in "restricted"
| mode. This disables scripting and external resources. However
| animation via either SMIL or CSS is still supported.
| vorgol wrote:
| It nearly got raw socket support back in the day:
| https://news.ycombinator.com/item?id=35381755
| chithanh wrote:
| When it comes to converting small video snippets to animated
| graphics, I think WEBP was much better than APNG from the
| beginning. Only if you use GIF as intermediate format then APNG
| was competitive.
|
| Nowadays, AVIF serves that purpose best I think.
| jokoon wrote:
| both GIF and PNG use zipping for compressing data, so APNG are
| not much better than GIF
| bawolff wrote:
| PNG uses deflate (same as zip) but GIF uses LZW. These are
| different algorithms. You should expect different compression
| results i would assume.
| 0points wrote:
| Remember when we unwillingly trained the generative AI:s of
| our time with an endless torrent of factoids?
| Calzifer wrote:
| (A)PNG supports semi-transparency. In GIF a pixel is either
| full transparent or full opaque.
|
| Also while true color gifs seem to be possible it is usually
| limited to 256 colors per image.
|
| For those reasons alone APNG is much better than GIF.
| theqwxas wrote:
| Some years ago I've used the Lottie (Bodymovin?) library. It
| worked great and had a nice integration: you compose your
| animation in Adobe After Effects, export it to an svg plus some
| json, and the lottie JS script would handle the animation for
| you. Anything else with (vector, web) animations I've tried is
| missing the tools or the DX for me to adopt. Curious to hear if
| there are more things like this.
|
| I'm not sure about the tools and DX around animated PNGs. Is
| that a thing?
| qingcharles wrote:
| Almost nowhere that supports uploading GIFs supports APNG or
| animated WEBP. The back end support is so low it's close to
| zero. Which is really frustrating.
| extraduder_ire wrote:
| Do you mean services that reencode gif files to webm/mp4?
| apng just works everywhere that png works, and will remain
| animated as long as it's not re-encoded.
|
| You can even have one frame that gets shown if and only if
| animation is not supported.
| adgjlsfhk1 wrote:
| I'm very curious to see how this will end up stacking up vs
| lossless jpegxl
| Simran-B wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Firefox also doesn't support JPEG XL out of the box, and
| Chrome does support the new PNG, so -\\_(tsu)_/-.
| trallnag wrote:
| How about renaming JPEG XL to PNG or just merging the
| complete spec into PNG 3.0?
| LoganDark wrote:
| For starters, you're actually able to use PNG.
| qwertox wrote:
| > 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.
| Aardwolf wrote:
| 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 wrote:
| 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.
| mavhc wrote:
| Because your non-smartphone camera doesn't have enough
| ram/speed to do that I assume (when in burst mode)
|
| If a smartphone camera is doing it, then bad camera app!
| Joel_Mckay wrote:
| Most modern camera modules have built in hardware codecs
| like mjpeg, region of interest selection, and frame
| mirror/flip options.
|
| This is particularly important on smartphones and battery
| operated devices. However, most smartphone devices simply
| save the photo the same way regardless of orientation,
| and simply add a display-rotated flag to the metadata.
|
| It can be super annoying sometimes, as one can't really
| disable the feature on many devices. =3
| Aardwolf wrote:
| Rotation for speed/efficiency/compression reasons (indeed
| with PNG's horizontal line filters it can have a
| compression reason too) should have been a flag part of
| the compressed image data format and for use by the
| encoder/decoder only (which does have caveats for
| renderers to handle partial decoding though... but the
| point is to have the behavior rigorously specified and
| encoded in the image format itself and handled by exactly
| one known place namely the decoder), not part of metadata
|
| It's basically a shame that the exif metadata contains
| things that affect the rendering
| joking wrote:
| the main reason is probably that the chip is already
| outputting the image in a lossy format, and if you
| reorder the pixels you must reencode the image which
| means degrading the image, so it's much better to just
| change the exif orientation.
| lsaferite wrote:
| > the chip is already outputting the image in a lossy
| format
|
| Could you explain this one?
| ralferoo wrote:
| One interesting thing about JPEG is that you can rotate an
| image with no quality loss. You don't need to convert each
| 8x8 square to pixels, rotate and convert back, instead you
| can transform them in the encoded form. So, rotating each
| 8x8 square is easy, and then rotating the image is just re-
| ordering the rotated squares.
| pwdisswordfishz wrote:
| That doesn't seem to apply to images that aren't
| multiples of 8 in size, does it?
| hidroto wrote:
| are there any cameras that take pictures that are not a
| multiple of 8 in width and height?
| bdavbdav wrote:
| People may crop
| justincormack wrote:
| the stored image is always a multiple of 8, with padding
| that is ignored (and heavily compressed).
| pwdisswordfishz wrote:
| But can this lossless rotation process account for
| padding not being in the usual place (lower right corner
| presumably)?
| mort96 wrote:
| I'm not sure if this is how JPEG implements it, but in
| H.264, you just have metadata which specifies a crop
| (since H.264 also encodes in blocks). From some quick
| Googling, it seems like JPEG also has EXIF data for
| cropping, so if that's the mechanism that's used to crop
| off the bottom and right portions today, there's no
| reason it couldn't also be used to crop off the top and
| left portions when losslessly rotating an image's blocks.
| dylan604 wrote:
| Slight nitpicking, but you can rotate in 90deg increments
| without loss.
| meindnoch wrote:
| Only if the image width/height is a multiple of 8. See:
| the manpage of jpegtran, especially the -p flag.
| klabb3 wrote:
| TIL, and hard agree (on face value). I've been struck by
| this with arbitrary rotation of images depending on
| application, very annoying.
|
| What are the arguments for this? It would seem easier for
| everyone to rotate and then store exif for the original
| rotation if necessary.
| kllrnohj wrote:
| > What are the arguments for this? It would seem easier
| for everyone to rotate and then store exif for the
| original rotation if necessary.
|
| Performance. Rotation during rendering is often free,
| whereas the camera would need an intermediate buffer +
| copy if it's unable to change the way it samples from the
| sensor itself.
| airstrike wrote:
| How is rotation during rendering free?
| chainingsolid wrote:
| Pretty much every pixel rendered these days was generated
| by a shader so gpu side you probably already have way
| more translation options than just a 90deg rotation
| (likely already being used for a rotation of 0deg). You'd
| likely have to write more code cpu side to handle the
| case of tell the gpu to rotate this please and handle the
| UI layout diffrence. Honestly not a lot of code.
| kllrnohj wrote:
| For anything GPU-rendered, applying a rotation matrix to
| a texture sample and/or frame-buffer write is trivially
| cheap (see also why Vulkan prerotation exists on
| Android). Even ignoring GPU-rendering, you always are
| doing a copy as part of rendering and _often_ have some
| sort of matrix operation anyway at which point
| concatenating a rotation matrix often doesn 't change
| much of anything.
| Someone wrote:
| > 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.
|
| The hardware likely is optimized for the common case, so I
| would think that can be a lot slower. It wouldn't surprise
| me, for example, if there are image sensors out there that
| can only be read out in top to bottom, left to right order.
|
| Also, with RAW images and sensors that aren't rectangular
| grids, I think that would complicate RAW images parsing.
| Code for that could have to support up to four different
| formats, depending on how the sensor is designed,
| jandrese wrote:
| Yes, but websites frequently strip all or almost all Exif data
| from uploaded images because some fields are used by stalkers
| to track people down to their real address.
| johnisgood wrote:
| And I strip Exif data, too, intentionally, for similar
| reasons.
| bspammer wrote:
| That makes sense to me for any image you want to share
| publicly, but for private images having the location and
| capture time embedded in the image is incredibly useful.
| johnisgood wrote:
| If by private you mean "never shared", I agree.
| jandrese wrote:
| If you are uploading it to a website you are sharing it.
| Even if the image is supposedly "private" you have to
| assume it will be leaked at some point. Remember, the
| cloud is just someone else's computer, and they can do
| what they want with their computer. They may also not be
| entirely competent at their job.
| johnisgood wrote:
| Yes, once something has been shared (or stolen), you lost
| control over it, be it information or an image. EXIF data
| is fine, if it never leaves your device or if your device
| is not compromised.
| andsoitis wrote:
| There is no standard field to record readouts of a camera's
| accelerometers or inertial navigation system.
|
| Exif fields: https://exiv2.org/tags.html
| bawolff wrote:
| Personally i wish people just used XMP. Exif is such a bizarre
| fotmat. Its essentially embedding a tiff image inside a png.
| Findecanor wrote:
| Does the meta-data have support for opting in/out of "AI
| training"?
|
| And is being able to read an image without an opt-in tag
| something that has to be explicitly enabled in the reference
| implementation's API?
| ggm wrote:
| 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 wrote:
| 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 wrote:
| It's in sidecar files. Takeout gets them, some tools read
| them.
| kccqzy wrote:
| But there is no standardization of sidecar files, no?
| Whereas EXIF is pretty standard.
| jeroenhd wrote:
| 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 wrote:
| 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.
| mbirth wrote:
| IIRC osxphotos has an option to merge external metadata into
| the exported file.
| luguenth wrote:
| In EXIF, you have DateTimeDigitized [0]
|
| For ambiguous dates there is the EDTF Spec[1] which would be
| nice to see more widely adopted.
|
| [0] https://www.media.mit.edu/pia/Research/deepview/exif.html
|
| [1] https://www.loc.gov/standards/datetime/
| ggm wrote:
| I remember reading about this in a web forum mainly for
| dublin core fanatics. Metadata is fascinating.
|
| Different software reacts in different ways to partial
| specifications of yyyy/mm/dd such that you can try some of
| the cute tricks but probably only one s.w. package honours
| it.
|
| And the majors ignore almost all fields other than a core set
| of one or two, disagree about their semantics, and also do
| wierd stuff with file name and atime/mtime.
| kumarvvr wrote:
| Never heard about Animated PNGs, and I am a nerd to the core.
|
| Pleasantly surprised.
| Joel_Mckay wrote:
| 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 wrote:
| What are some "consistent color standards" you'd recommend?
| Honest question.
| Joel_Mckay wrote:
| 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
|
| The Andreas Durr LUT pack:
|
| https://www.youtube.com/watch?v=dDKK54CeXgM
|
| 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 wrote:
| "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 wrote:
| 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
| ProgramMax wrote:
| 0xFF is 8-bit. PNG supports up to 16-bit. It always has.
| Plus, PNG now supports full HDR so the fireball won't look
| washed out.
|
| I think your experience is with some tool that made bad
| PNGs. That is a problem with the tool, not the format.
| Joel_Mckay wrote:
| EXR stores the color-space information differently, and
| you missed the point.
|
| Have a look at a tutorial that dives into the basic
| details, and consider learning something:
|
| https://www.youtube.com/watch?v=pLt1230dtYE
|
| https://www.youtube.com/watch?v=mb0b83MML78
|
| https://www.youtube.com/watch?v=egtnkhuUe_E
|
| PNG has its use-cases, and some people do expect that
| baked color-space garbage look given it dominates a lot
| of low-end media. Have a great day =3
| ProgramMax wrote:
| I'm trying to follow your point. But...there are problems
| with your claims. Yes, EXR stores color-space differently
| than PNG. Because EXR doesn't store color space at all.
|
| In the first video, the person loads the image and
| manually chooses a gamma transfer function with 2.2. If
| that was then saved, it would produce the washed-out
| fireball you mentioned.
|
| In the second video, the person loads the image and
| manually chooses rec.709, which is also gamma tf and also
| produces washed-out fireball. In fact, the EXR image he
| loads literally has a bright fireball and you see it get
| washed out.
|
| If you want to make claims about EXR being better than
| PNG, you need to say why storing the values as floating
| point is better than integer. But the blown-out fireball
| example is just incorrect. As evidence, I'll point to
| HDR. ANYTHING you see in an HDR movie is now 100%
| losslessly reproducible in a PNG.
| Joel_Mckay wrote:
| There is a lot of conflated contexts to unpack there...
|
| However, I still trust the ILM engineers over your pet
| project, and maligned post that reeks of LLM slop.
|
| The argument of making cow from hamburger doesn't hold
| true under our use-cases. You were shown the path, and it
| is your choice to put in the work to learn something
| important.
|
| Best of luck kid =3
| nektro wrote:
| cautiously optimistic. the thing that makes png so sought after
| is its status as frozen
| tonyedgecombe wrote:
| >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 wrote:
| 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 wrote:
| 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 wrote:
| >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 wrote:
| 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 wrote:
| > 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.
| leni536 wrote:
| PNG already supports color profiles, but probably not HDR.
| I would say that the gamut argument in the article is
| misleading, you can already encode a wider gamut.
|
| Not sure how HDR encoding works, but my impression is that
| you can set a nominal white point other than (1, 1, 1) in
| your specified colorspace. This is an extension, but
| orthogonal to specifying the colorspace itself and the
| gamut.
| ProgramMax wrote:
| You are correct. I designed the article to be very
| approachable and understandable for the normal person. As
| such, I took some liberties like only showing HDR
| primaries and ignoring transfer function. I linked to
| Chris Lilley's post to give experts a more correct
| answer.
|
| But wide color gamut was already possibly in PNG via ICC
| profiles (HDR was not). And those primaries I showed
| could have been used in a wide color image.
|
| So the image is a bit misleading or red-flag-y to experts
| who know. But to the average person, I think it is as
| truthful as I can be without getting too deep in the
| weeds.
| virtualritz wrote:
| There is nothing in display hardware today that TIFF
| couldn't handle already.
|
| For example 16bit (integer) TIFF files 'with headroom',
| i.e. where some bits were used to represent data over 1.0
| (HDR) was a common approach for VFX work in the 90's.
|
| 16bit float TIFF is also thing since 33 years. Adobe DNG is
| modeled after TIFF. High end offline renderers have
| traditionally been using TIFF (with mip-maps) to store
| textures.
|
| TIFF supports tags so primaries and white point or a known
| color space name can be stored in the file.
|
| The format is so versatile, it is used everywhere.
|
| And of course it also supports indexed color, i.e. a non-
| negotiable feature at the time PNG was introduced.
|
| PNG was meant to replace GIF. Instead of looking what was
| already there some group of "experts" and "enthusiasts"
| (quote Wikipedia) succumbed to their NIH complexes. If
| licensing/patent woes over compression algorithms had been
| a motivator, why not just add a new one to TIFF?
|
| The fact that PNG stores straight/unpremultiplied alpha
| says everything if you know anything about imaging in
| computer graphics.
|
| And the fact that the updated format spec just released
| didn't address this tells you everything you need to know
| about the group in charge of that, today.
|
| PNG is the VHS of image formats. It should have never seen
| the light day of in the first place nor the adoption it
| did.
| tonyedgecombe wrote:
| >The format is so versatile, it is used everywhere.
|
| Yeah, I love the fact that you can embed a PDF file
| inside a TIFF.
| eviks wrote:
| > [not] Officially supports Exif data
|
| How can you call this basic fail a success?
| tonyedgecombe wrote:
| Exif data might be important to you but it clearly hasn't
| stopped the adoption of png.
| Retr0id wrote:
| People crammed exif data into PNGs anyway, and now they can
| continue to do that but in conformance with the spec.
| eviks wrote:
| Yes, plenty of tech garbage floats at the top, the question
| is why would you argue that lack of basic fixes over
| decades is not stagnation, but something positive
| jbverschoor wrote:
| What if we kind of fit JXL in PNG? That way it's more likely to
| be supported
| iliketrains wrote:
| 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....
|
| https://marekfiser.com/projects/malsys-mareks-lsystems/
| chithanh wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| Seems that logic does not apply to jpeg though.
| ethan_smith wrote:
| 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 wrote:
| libpng updates are either already landed or nearly landed.
| defraudbah wrote:
| this is good news, any packages who support new png standard or
| planning to? rust/go/python/js?
| guilbep wrote:
| Let's call it PPNG: Pas Portable NetWork Graphic
| b0a04gl wrote:
| 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 wrote:
| 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 wrote:
| Oh no another HEIC!
| Dwedit wrote:
| 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 wrote:
| I look forward to seeing what PNG v5 does in the future with
| compression, especially relative to existing formats.
| ansgri wrote:
| 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 wrote:
| And the JXL api is a nightmare, compared to WEBP.
| Dwedit wrote:
| 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 wrote:
| It was gone??? Was I the only one using it this entire time?
| meindnoch wrote:
| Parallel compression/decompression is already possible via
| Z_SYNC_FLUSH.
| Retr0id wrote:
| Parallel _de_ compression of Z_SYNC_FLUSH'd data is not
| possible without additional metadata to tell you where the sync
| points are.
| meindnoch wrote:
| 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 wrote:
| Yes, such a chunk is being considered for introduction in
| future PNG revisions.
| sylware wrote:
| 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 wrote:
| 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.
| antirez wrote:
| PNG: doing very little with as much complexity as possible.
| LeoPanthera wrote:
| You're going to be shocked when you find out how webp works.
| qwertfisch wrote:
| Because that's a video compression format, from where only a
| single intra-frame is used.
| poisonborz wrote:
| 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.
| michaelmior wrote:
| > 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 wrote:
| 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 wrote:
| Not even Google supports webp uploads in many of their web
| apps, and it's their format.
| chillingeffect wrote:
| 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.
| pixl97 wrote:
| Honestly this kind of stuff happens all the time in large
| companies.
|
| Interns won't want to work on a dead end like this.
| Moreso they need to be supervised by someone that doesn't
| want to get removed by being the lowest X% usefulness in
| a company. So all these existing tools that aren't
| primary revenue generators just sit on coast mode.
| upcoming-sesame wrote:
| If you are using an image optimization service like Imgix /
| Cloudflare Image Resizing then it doesn't really matter,
| image can be uploaded as any supported format and will be
| sent to the end user according to their "Accept" header
| hsbauauvhabzb wrote:
| if you'd like to go and implement that in all the
| millions of existing web apps, go ahead?
|
| Let's also not forget the dependency mess that leaves in
| applications before we do though..
| dotancohen wrote:
| 5% of people can't view them, yet 25% of top websites use
| them?
|
| In what other industry would it be considered acceptable to
| exclude 5% of visitors/users/clients?
| sjsdaiuasgdia wrote:
| Not all businesses are attempting to reach a market of
| "every internet user globally".
| bawolff wrote:
| Can the 5% view images at all? The number of web crawlers
| have exploded recently.
| jdiff wrote:
| Yes, but it's 2% that are still using browsers without
| full support for WebP according to caniuse, which takes
| its numbers from StatCounter.
|
| https://caniuse.com/webp
|
| Note that I'm looking at "all tracked," which excludes 2%
| "other" browsers in the data whose featureset is not
| known.
| 0points wrote:
| > 5% of people can't view them, yet 25% of top websites use
| them?
|
| That's not how it works.
|
| The server declares what versions of media it has, and the
| client requests a supported media format. The same trick
| have been used for audio and video for ages too.
|
| Example: <picture> <source
| srcset="a.webp" type="image/webp"> <img
| src="fallback.jpg"> </picture>
| vbezhenar wrote:
| This problem was solved by HTTP since forever. Client
| sends `Accept` header with supported formats and server
| selects the necessary content with corresponding
| `Content-Type` header. You don't need any HTML tags for
| it.
| allendoerfer wrote:
| What about file extensions?
| jdiff wrote:
| Sometimes respected, largely ignored. URLs _very_ often
| don 't map directly to files served.
| georgyo wrote:
| File extensions are just a hint about what the file might
| be and have nothing to do with what the file actually is.
| If the server sets the MIME type, the browser will use
| that as the hint.
|
| But even beyond that, most file formats have a bit of a
| header at the start of the file that declares the actual
| format of the file. Browsers already can understand that
| and use the correct render for a file without an
| extension.
| NorwegianDude wrote:
| No, cause thats just one of the features.
|
| Images are often at different resolutions too, that way,
| depending on the pixel density of the device, and the
| physical size, the browser can select the photo that has
| high enough resolution, but not one that is needlessly
| large, while also selecting the preferred image format.
| mlok wrote:
| Maybe they offer alternatives to webp for those 5% ?
|
| See CSS image-set : https://developer.mozilla.org/en-
| US/docs/Web/CSS/image/image...
| pchangr wrote:
| I can tell you, I have personally worked with a global
| corporation and we estimated that for one of their
| websites, supporting the 3% that we exclude by using
| "modern standards" would be more costly than the amount of
| revenue they get from them. So in that case, it was a
| rational decision. And up to the 10% cut, management just
| didn't want to do the extra investment. So if something
| falls below that 10% threshold, they just don't care to get
| it fixed.
| Aachen wrote:
| > it was a rational decision. And up to the 10% cut,
| management just didn't want to do the extra investment
|
| Rational, or economical? I find it rational to help
| someone in need since I'd want others to do the same to
| me, even if it's not financially profitable for me. Imo
| more factors flow into what's rational, but I understand
| what you mean by corporate greed working this way (less
| than 10% of people are blind, neither male nor female,
| run a free operating system or can't afford a new
| computer, etc., so yep they're not profitable groups and
| for-profits don't optimise for that)
| majewsky wrote:
| You are using the notion of rationality wrong. Rational
| reasoning can only help you find how to achieve goals
| that align with your values. It is strictly worthless in
| choosing your values.
|
| If a corporation has determined that profit maximization
| is their core tenet, excluding the needs of a minority of
| users can likely be deduced in a rational manner from
| that tenet. That is precisely why values need to be
| forced onto corporate actors through regulation, e.g. in
| this case through mandatory accessibility guidelines like
| EU directive 2019/882 that enters into force this very
| week.
| eviks wrote:
| Something is off in this calculation, how did they get to
| such a high cost for such a simple thing as an
| alternative image format when the web supports
| multiple???
| dooglius wrote:
| My guess would be that the users hitting different types
| of issues are mostly the same; someone who can't view an
| alternative image format is using an obscure old browser
| or obscure OS that will inevitably have a ton of other
| issues too, and fixing only a subset of the issues would
| not make much difference.
| pasc1878 wrote:
| Any industry.
|
| e.g. cars - not everyone is physically able to drive books
| - blind people can't read music - deaf people can't hear
|
| It is a form of 80/20 or 90/10 rule the last small
| percentage costs as much as the majority.
| danillonunes wrote:
| I agree with the point you're trying to make, but your
| examples are terrible. Music industry doesn't have too
| much to do to help deaf people. It's not like they're
| deliberately making deaf-inaccessible music instead of
| relying on the old good deaf-accessible music formats.
|
| (Also, the parent comment's example is also not so good
| because as someone else pointed just because the top 25%
| websites are serving webp it does mean they're not
| serving alternative formats for those who does not
| support it, as this is quite trivial to setup)
| Geezus_42 wrote:
| Great, so I can download it, but then I have to convert it to
| a different format before half my apps will be able to use
| it.
| wltr wrote:
| Maybe the issue is with your operating system then?
| jdiff wrote:
| App support has very little to do with the operating
| system. OSes by and large will preview it just fine.
| dinkblam wrote:
| on the contrary. on macOS apps don't have to support
| image (or movie) formats. it is done by the system and
| transparently handled by the APIs. apps automatically
| gain new formats when the system adds it.
| reaperducer wrote:
| The unfortunate side effect of this convenience is that
| apps automatically _lose_ image support when macOS chases
| to no longer support them, too.
|
| One example is Sony's SRF camera raw format.
|
| Programs like Photoshop and Affinity have to bring their
| own decoders where previously none were required.
| dspillett wrote:
| And having to bring in support for formats that are
| deprecated by the OS, if they decide to keep supporting
| that format as there is sufficient demand from their
| users, is worse than having to bring in support for all
| formats rather than getting support from the OS?
|
| Having ask that in a slightly confrontational way, one of
| the reasons I started using VLC all those years ago, and
| still use it to this day, was having trouble with other
| media players that relied on OS support fail to work well
| (or at all) with some codecs, while VLC brought support
| for them, and their dog, built-in and reliable. Dragging
| your own format support libraries with you can be
| beneficial.
| wltr wrote:
| I meant Windows, as macOS and Linux are usually good with
| modern things. It's trivial to add the support if you
| don't have it. I have no idea about Windows, but I got
| this vibe of someone using Win7 in 2025 and complaining
| the world moved on and keeps moving on.
| echelon wrote:
| You can't use webp on Reddit, Instagram, and hundreds of
| other websites. Which is ironic because some of them
| serve images as webp.
| wltr wrote:
| That doesn't mean it's dead, it rather shows sheer
| incompetence of the web dev departments of these
| wonderful companies for whom webp or avif aren't images,
| I guess.
| PaulHoule wrote:
| Instagram's image uploading interface is klunky compared
| to Mastodon which is entirely unfunded.
| echelon wrote:
| This shows the unfortunate power of distribution.
|
| It doesn't matter if the alternative is technically
| superior once the majority use the mainstream thing.
| socalgal2 wrote:
| Just tested reddit. It works fine with .webp I don't have
| an instagram account
| echelon wrote:
| Try https://www.reddit.com/settings/profile
|
| There are so many uneven areas of Reddit where WebP
| doesn't work. Old reddit, profile support, mod tools,
| etc.
| kccqzy wrote:
| I'm convinced that this is because of the prevalent MVP
| culture in modern software engineering. Instead of
| holistically looking at a new feature request such as
| "support webp images" we break it down into parts (e.g.
| "serve webp" "accept webp upload here" "accept webp
| upload there") and then we call it a MVP when only the
| highest priority items are done.
| BeFlatXIII wrote:
| Or convert before you upload because the image host has
| delusions about fighting the Google monoculture by refusing
| WebP support. Even more of a head scratcher when WebM is
| their only video format.
| PaulHoule wrote:
| Blame Adobe. For what they charge for Creative Suite it
| ought to have supported it a long time ago.
|
| My webcrawler sucks down a lot of WebP images, at least it
| did before it got the smackdown from Cloudflare.
| martin_a wrote:
| Adobe Photoshop has support for WebP (through "Save as",
| not "Export") but I don't think WebP is important.
| whywhywhywhy wrote:
| But it can't open them
| martin_a wrote:
| Not sure if that's version specific, but my one can
| (version 26.7.0) without any issues or warnings. Tried
| with this sample file:
| https://www.gstatic.com/webp/gallery/1.webp
| williamscales wrote:
| Looks Photoshop has since v23.2 in 2022.
| asadotzler wrote:
| My PS can open them. Maybe update?
| lizknope wrote:
| I was about to write that Slack doesn't support webp but I
| just tested it and it does. For years I have been typing
| "convert file.webp file.jpg" and then posting that in slack
| but it looks like they have added support.
| jeroenhd wrote:
| Everything I've tried supports WebPs. It took Adobe a while
| but even Photoshop supports the format these days.
|
| Hell, for some software features (like stickers in some
| chat apps), WebP is mandatory.
|
| HEIFF files, on the other hand...
| AlienRobot wrote:
| You can't even upload webp to instagram.
| bastawhiz wrote:
| Which makes sense for an app made for photos: why would you
| capture a photograph to disk in a format made for
| distributing on the web?
| jdiff wrote:
| Indeed, why might one upload a photo to the web in a
| format made for distributing images on the web?
| bastawhiz wrote:
| I could save my photos as BMPs like early digital cameras
| did but that doesn't make it practical or reasonable. My
| camera takes pictures as RAW or HEIF files. Why would I
| save my photos to a primarily lossy codec that's
| optimized and designed for distribution rather than
| preserving fidelity?
|
| We used to do this with JPEG, in fact. And that's why
| many pictures on Facebook from pre-2018 or so all have a
| distinctive grainy look. It's artifacts on top of
| artifacts. Storage on phones isn't tight anymore, we
| don't need to store photos in a format meant to minimize
| bytes at the expense of quality.
| Sharlin wrote:
| Instagram hasn't even been primarily or even secondarily
| about photos for a long time. Indeed trying to "just"
| upload a photo is made super inconvenient these days.
| bastawhiz wrote:
| Unless you're uploading memes you've downloaded from
| elsewhere, this strictly isn't true. I'd consider myself
| an Instagram power user and the only thing that I and all
| the people I interact with is photos and videos. None of
| those are webp, or would have been worthwhile to save as
| webp as an intermediate format.
| whywhywhywhy wrote:
| completely fails the second you want to do anything more than
| load it on a webpage
|
| Photoshop still won't open it, MacOS preview opens it but
| then demands to convert it to tiff when you try to edit it
| asgerhb wrote:
| Maybe using VLC Media Player from an early age has left me
| with too high expectations. But if I have a program
| designed to view or edit a certain class of file, and it
| doesn't support a certain file format, I will blame that
| program.
| Etheryte wrote:
| 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.
| Hendrikto wrote:
| > Momentum built, and additional parties became interested.
| [...] we had representation from [...] Adobe, Apple, BBC,
| Comcast / NBCUniversal, Google, MovieLabs, and [...] W3C
|
| > Many [...] programs [...] already support the new PNG spec:
| Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve,
| Avid Media Composer...
|
| > Plus, you saw some broadcast companies in that list above.
| Behind the scenes, hardware and tooling are being updated to
| support the new PNG spec.
| 127 wrote:
| There's a big issue that all old popular image formats are
| 8-bits. 10-bits or even 12-bits would help a lot with storing
| more information and maintaining editability.
| londons_explore wrote:
| If adding more bits to an image format, please make it 'n
| bit'. Ie. the file could be 8 bit, it could be 10, it could
| be 12, it could be 60 bit!
|
| Whilst we're at it, please get rid of RGB and make it N
| channels too.
|
| Libraries can _choose_ to render that into a 3 channel, 8 bit
| buffer for legacy applications - but the data will be there
| for CMYK or HDR, or depth maps, or transparency, or focus
| stacking, or any other future feature!
| Retr0id wrote:
| PNG has supported 16-bits per channel since version 1.0 in
| 1998 (at least)
| lioeters wrote:
| > Not backwards compatible
|
| They say it's technically compatible since older image decoders
| should recognize the PNG file is using a different compression
| algorithm than the default.
|
| > Many programs already support the new PNG spec: Chrome,
| Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid
| Media Composer...
|
| This is intentionally ignoring the fact that there are
| countless PNG decoders out in the wild, many using libpng the
| standard decoder last updated 6 years ago; and they will not be
| able to read the new PNG v2 files.
|
| They should have used a different file extension, PNG2, to
| distinguish this incompatible format. Otherwise, users will be
| confused why their newly saved PNG file cannot be read by
| certain existing programs.
| JKCalhoun wrote:
| Many Mac apps do not consider the file extension but instead
| look for marker bytes within the file. While the Finder might
| use the extension to determine which app to launch ("Oh, an
| image file, let's open Preview") the app that is passed the
| file (Preview) will then look for various marker bytes to
| decide if it is a JPEG, PNG, etc.
|
| (I am told by a certain LLM that the first 8 bytes of a PNG
| are the marker bytes: "89 50 4E 47 0D 0A 1A 0A". This is
| apparently in libpng itself ... so perhaps any OS or tool
| updating to a newer pnglib will get the new format for free?)
| ape4 wrote:
| The 50 4E 47 spells "PNG"
| colejohnson66 wrote:
| Those are indeed the "magic" bytes of PNG. It's a very
| clever choice meant to ensure the transport layer didn't
| mess with it.
|
| To start, there's a byte with the upper bit set which
| ensures an "8-bit clean" transport. If it's stripped, it
| becomes a harmless tab. Then the literal "PNG" text so you
| can see it in a text editor. Then a CR-LF pair to check for
| CR-LF to LF translations. Then, a CTRL-Z to stop display on
| DOS-like systems. And finally, another LF to check for LF
| to CR-LF translations.
|
| It's a clever "magic" that basically ensures a binary
| transport layer. Things that mattered back in 1996.
|
| https://www.libpng.org/pub/png/spec/1.2/PNG-
| Rationale.html#R...
| arp242 wrote:
| libng seems to get regular updates? A release just a few days
| ago.
|
| There's a PR for APNG:
| https://github.com/pnggroup/libpng/pull/706 - it seems there
| was some work for HDR in e.g.
| https://github.com/pnggroup/libpng/pull/635 as well. Related:
| https://github.com/pnggroup/libpng/issues/507
| lioeters wrote:
| Oh cool! I was looking at this page, which looks official
| but apparently not up to date.
|
| https://www.libpng.org/pub/png/libpng.html
|
| Looks like this is the proper location for the project.
|
| https://libpng.sourceforge.io/
| Retr0id wrote:
| Which aspects are not backwards compatible?
|
| You'll never be able to faithfully represent an HDR image on a
| non-HDR system, but you'll still see an image.
| LocalH wrote:
| I miss the days of old Amiga OS 3.x, where you had installable
| "DataTypes" that any program could make use of. If we had that,
| then all such programs could at least be updated to basic
| compatibility by simply updating the datatype.
| dev_l1x_be wrote:
| > Look at poor webp
|
| What about it?
|
| "Lossless WebP is typically 26% smaller than PNG, while lossy
| WebP can be 25-34% smaller than JPEG at equivalent quality
| levels"
|
| This literally saves houndred of thousand of cost, bandwith,
| electricity every month on the internet. In fact, I strongly
| belive that this is one of the greatest contributions from
| Google to society just like ZSTD from Facebook.
|
| https://developers.google.com/speed/webp/docs/webp_study
| Timwi wrote:
| I don't think the commenter you replied to disagrees with any
| of that. They were talking about poor rates of adoption, not
| its feature set.
| dev_l1x_be wrote:
| The biggest driver of adoption are features.
|
| "WebP is used by 16.7% of all websites. This means that
| while it's a popular image format, it's not yet the
| dominant format, with JPEG still holding the majority share
| at 73.0%, according to W3Techs. However, WebP offers
| significant advantages in terms of compression and file
| size, making it a preferred choice for many web developers.
| "
| poisonborz wrote:
| Society wholeheartedly thanks Google for saving costs for
| Google
| GuB-42 wrote:
| There are some applications for a new image format, but I agree
| that what we have is generally good enough.
|
| We need good video formats however. Video makes up most of the
| global internet traffic, probably accounts for a good part of
| global storage capacity too. Even slightly better compression
| will have a massive impact.
| ProgramMax wrote:
| It is very backwards compatible. I'm not sure why you thought
| that.
|
| We jumped through quite a lot of hoops to make sure old
| software will be able to display new images. They simply won't
| display them optimally. But for the most part, that would be
| because the old software wouldn't display images optimally
| anyway. So the limit was the software, not the format.
|
| What I mean by this is old software that treats everything as
| sRGB wouldn't correctly show a Display P3 image anyway. But we
| made sure it will still display the image as correctly as it
| could.
| Padriac wrote:
| I thought this was about Papua New Guinea.
| ksec wrote:
| 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
| klabb3 wrote:
| What about transparency? That's the main benefit of PNG imo.
| cmiller1 wrote:
| Yes JPEG-XL has an alpha channel.
| illiac786 wrote:
| > 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 wrote:
| 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 wrote:
| 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?
| ksec wrote:
| In terms of PC usage, JPEG, or most image codec decoding
| are done via software and not hardware. AFAIK even AVIF
| decoding is done via software on browser.
|
| Hardware acceleration for lossless makes more sense for
| JPEG XL because it is currently very slow. As the author
| of HALIC posted some results below, JPEG XL is about 20 -
| 50x slower while requiring lots of memory _after_ memory
| optimisation. And about 10 - 20 times slower compared to
| other lossless codec. JPEG XL is already used by Camera
| and stored as DNG, but encoding resources is limiting its
| reach. Hence hardware encoder would be great.
|
| For lossy JPEG XL, not so much. Just like video codec,
| hardware encoder tends to focus on speed and it takes
| multiple iteration or 5 - 10 years before it catches up
| on quality. JPEG XL is relatively new with so many tools
| and usage optimisation which even current software
| encoder is far from reaching the codec's potential. And I
| dont want crappy quality JPEG XL hardware encoder, hence
| I much prefer an upgradeable software encoder for JPEG XL
| lossy and hardware encoder for JPEG XL Lossless.
| thesz wrote:
| HALIC discussion page [1] says otherwise.
|
| [1] https://encode.su/threads/4025-HALIC-(High-Availability-
| Loss...
|
| It looks like LEA 0.5 is the champion.
|
| And HALIC is not even close to ten in this [2] lossless image
| compression benchmark.
|
| [2] https://github.com/WangXuan95/Image-Compression-Benchmark
| poly2it wrote:
| It looks like HALIC offers very impressive decode speeds
| within its compression range.
| ksec wrote:
| And not just decoding speed but also encoding speed with
| difference of an order of magnitude. Some new results
| further down in the comments in this thread. Had it not
| been verified I would have thought it was a scam.
| voxleone wrote:
| I'm using png in a computer vision image annotation tool[0].
| The idea is to store the class labels directly in the image
| [dispensing with the side car text files], taking advantage of
| the beautiful png metadata capabilities. The next step is to
| build a specialized extension of the format for this kind of
| task.
|
| [0]https://github.com/VoxleOne/XLabel
| yyyk wrote:
| When it comes to metadata, an implementation not being widely
| implemented (yet) is not that big a problem. Select tools will
| do for meta, so this is an advancement for PNG.
| bla3 wrote:
| WebP lossless is close to state of the art and widely
| available. It's also not widely used. The takeaway seems to be
| that absolute best performance for lossless compression isn't
| that important, or at least it won't get you widely adopted.
| adzm wrote:
| Only downside is that webp lossless requires RGB colorspace
| so you can't, for example, save direct YUV frames from a
| video losslessly. AVIF lossless does support this though.
| mchusma wrote:
| I don't know that i have ever used jpg or png lossless in
| practical usage (e.g. I don't think 99.9% of mobile app or
| web usecases are for lossless). WebP lossy performance is
| just not worth it in practice, which is why WebP never took
| off IMO.
|
| Are there usecases for lossless other than archival?
| Inityx wrote:
| Asset pipelines for media creation benefit greatly from
| better compression of lossless images and video
| ProgramMax wrote:
| WebP maxes at 8-bit per channel. For HDR, you really need 10-
| or 12-bit.
|
| WebP is amazing. But if I were going to label something
| "state of the art" I would go with JPEGXL :)
| Aloisius wrote:
| I'll be honest, I ignored JPEG XL for a couple years because I
| assumed that it was merely for extra large images.
| ChrisMarshallNY wrote:
| Looks like it's basically reaffirming what a lot of folks have
| been doing, unofficially.
|
| For myself, I use PNG only for computer-generated still images.
| I tend to use good ol' JPEG for photos.
| HakanAbbas wrote:
| I don't really understand what the new PNG does better.
| Elements such as speed or compression ratio are not mentioned.
| Thanks also for your kind thoughts ksec.
|
| Apart from the widespread support in codecs, there are 3
| important elements: processing speed, compression ratio and
| memory usage. These are taken into account when making a
| decision (pareto limit). In other words, the fastest or the
| best compression maker alone does not matter. Otherwise, the
| situation can be interpreted as insufficient knowledge and
| experience about the subject.
|
| HALIC is very good in lossless image compression in terms of
| speed/compression ratio. It also uses a comic amount of memory.
| No one mentioned whether this was necessary or not. However,
| low memory usage negatively affects both the processing speed
| and the compression ratio. You can see the real performance of
| HALIC only on large-sized(20 MPixel+) images(single and multi-
| thread). An example current test is below. During operations,
| HALIC uses only about 20 MB of memory, while JXL uses more than
| 1 GB of memory.
|
| https://www.dpreview.com/sample-galleries/6970112006/fujifil...
|
| June 2025, i7 3770k, Single Thread Results
|
| ----------------------------------------------------
|
| First 4 JPG Images to PPM, Total 1,100,337,479 bytes
|
| HALIC NORMAL: 5.143s 6.398s 369,448,062 bytes
|
| HALIC FAST : 3.481s 5.468s 381,993,631 bytes
|
| JXL 0.11.1 -e1: 17.809s 28.893s 414,659,797 bytes
|
| JXL 0.11.1 -e2: 39.732s 26.195s 369,642,206 bytes
|
| JXL 0.11.1 -e3: 81.869s 72.354s 371,984,220 bytes
|
| JXL 0.11.1 -e4: 261.237s 80.128s 357,693,875 bytes
|
| ----------------------------------------------------
|
| First 4 RAW Images to PPM, Total 1.224.789.960 bytes
|
| HALIC NORMAL: 5.872s 7.304s 400,942,108 bytes
|
| HALIC FAST : 3.842s 6.149s 414,113,254 bytes
|
| JXL 0.11.1 -e1: 19.736s 32.411s 457,193,750 bytes
|
| JXL 0.11.1 -e2: 42.845s 29.807s 413,731,858 bytes
|
| JXL 0.11.1 -e3: 87.759s 81.152s 402,224,531 bytes
|
| JXL 0.11.1 -e4: 259.400s 83.041s 396,079,448 bytes
|
| ----------------------------------------------------
|
| I had a very busy time with HALAC. Now I've given him a break,
| too. Maybe I can go back to HALIC, which I left unfinished, and
| do better. That is, more intense and/or faster. Or I can make
| it work much better in synthetic images. I can also add a mode
| that is near-lossless. But I don't know if it's worth the time
| I'm going to spend on it.
| leviathan1 wrote:
| Not backwards compatible I think
| ProgramMax wrote:
| It is very backwards compatible. :) We worked hard to make sure
| it would be.
| 369548684892826 wrote:
| 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
| gred wrote:
| 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
| cmiller1 wrote:
| How do you pronounce PNG?
| gred wrote:
| Pee En Gee
| illiac786 wrote:
| P&G, stands for Pee & Gloat.
| gred wrote:
| Portable & Graphical
| NoMoreNicksLeft wrote:
| "Pong". Hate me, I don't care.
| kristopolous wrote:
| I used to call them Nogs claiming the P was silent.
|
| People believed me. Still funny.
| ziml77 wrote:
| The only logic I ever hear for using a hard G is because
| that's how Graphics is said. Yet I never hear people saying
| jay-feg.
| gred wrote:
| Also "gift".
| dspillett wrote:
| Because the creator of gifs telling the world how he pronounced
| it made such a huge difference :)
|
| Not sure I'll bother to reprogram myself from "png", "pung", or
| "pee-enn-gee".
| naikrovek wrote:
| When someone makes a baby, you call that person by their real
| name with the correct pronunciation, don't you?
|
| So why can't you do that with GIF or PNG? People that create
| things get to name them.
| airstrike wrote:
| Because PNGs won't answer back when I call them by some
| "correct" name.
| pixl97 wrote:
| Depends...
|
| You'll commonly call someone by their pronounced name out
| of respect, forced or given.
|
| In a situation where someone does something really stupid
| or annoying and the forced respect isn't there, most people
| don't.
| AllegedAlec wrote:
| > People that create things get to name them.
|
| And if they pick something dumb enough other people get to
| ignore them.
| freeopinion wrote:
| A parent may name their baby Elizabeth. Then even the
| parent might call them Liz or Beth or Betsy or Bit or Bee.
| eviks wrote:
| First, it's not a baby, that's a ridiculous comparison.
|
| But also, no, not universally even for babies, especially
| when the name is something ridiculous like X AE A-Xii where
| even parents disagree on pronunciation, or when the person
| himself uses a "non-specced" variant
| LocalH wrote:
| I've said "jif" for almost 40 years, and I'm not stopping
| anytime soon.
|
| Hard-g is _wrong_ , and those who use it are showing they
| have zero respect for others when they don't _have_ to.
|
| It's the tech equivalent to the shopping cart problem. What
| do you do when there is no incentive one way or the other? Do
| you do the _right_ thing, or do you disrespect others?
| pwdisswordfishz wrote:
| Linguistic prescriptivism is _wrong_ , and people who
| promote it are showing they have zero respect for others
| when they don't _have_ to.
| LocalH wrote:
| I agree that language is fluid. However, when it comes to
| names, I think people should have enough respect to
| pronounce things how the creator (or owner, depending on
| the situation) of the name says it should be pronounced.
| Too often people will mispronounce someone's name as a
| sign of intentional disrespect (see Kamala Harris for a
| fairly recent prominent example) and I cannot get behind
| that. You see a similar disrespect in the hard-soft
| discourse around the pronunciation of GIF. A lot of
| people use the hard g and mock the creator for thinking
| that soft g should ever have been right.
|
| Naming is probably one of the few language areas that I
| think _should_ be prescriptive, even while language at
| large is descriptive.
| Analemma_ wrote:
| I don't think technical standards merit the same level of
| "deference to the creator" as personal names. People are
| wrong about standards they created all the time (ask me
| what I think about John Gruber's "stewardship" of
| Markdown) and _should_ be corrected, a standard is meant
| for all. Obviously the pronunciation of an acronym isn't
| anywhere near as important as technical details, but I
| think the principle holds.
| asadotzler wrote:
| People are wrong about the children they create all the
| time too, and should be corrected.
| LocalH wrote:
| A child is presumably a sentient being, and at some point
| in their life should gain control of their name. In fact,
| they do, to some large degree. There are means to change
| one's legal name, or one can diverge from their legal
| name and professionally/publicly use a completely
| different name.
|
| A file format is not a sentient being. The creator's
| intent matters much more. If GIF had sentience and could
| voice a desire one way or the other, the whole discussion
| would be moot as it would clearly be disrespectful to
| intentionally mispronounce the name.
| mandmandam wrote:
| If the creator insists on a weird pronunciation, because
| of an inside joke most won't ever get, then I feel no
| responsibility in humoring them.
|
| The G in gif is for graphics. Not 'giraffics'. And most
| people in the world have no idea what Jif even is, much
| less a particular catchphrase from an old ad campaign
| that barely even connects.
| ziml77 wrote:
| And the P in JPEG is for photographic, so you better be
| saying jay-feg if you want to rely on that logic.
| joquarky wrote:
| If everyone conformed, then we would have no fun lively
| debates on things like this. That would be a boring
| world.
| xdennis wrote:
| Linguistic prescriptivism has nothing to do with it.
|
| English has both pronunciations for "gi" based on origin.
| Giraffe, giant, ginger, etc from Latin; gift, give, (and
| presumably others) from Germanic roots.
|
| Using the preferred one is just a matter of politeness.
|
| Also, it's quite ironic to prescribe "linguistic
| prescriptivism" as wrong.
| i80and wrote:
| Is this a bit?
| LocalH wrote:
| Absolutely not. See my response to your sibling comment.
| Choosy nerds choose "GIF".
| rhet0rica wrote:
| Unfortunately for your crusade, the soft-G pronunciation
| has essentially been typo-squatted since before typo-
| squatting was a thing.
|
| https://file.org/extension/jif
|
| https://fileinfo.com/extension/jiff
|
| https://www.reddit.com/r/todayilearned/comments/4rirr8/ti
| l_t...
|
| https://en.wikipedia.org/wiki/JPEG#JPEG_files
| npteljes wrote:
| As much as I hate _jif_ , thinking about it, "GPU" works
| the same - we say _gee-pee-you_ and not _gh-pee-you_.
| Garbage Collection is also _gee-cee_. So it 's only logical
| that _jif_ is the correct one - even if it 's not the
| widely accepted one.
|
| Wrt/ communication, aside from personal preference, one can
| either respect the creator, or the audience. If I stand in
| front of 10 colleagues, 10 out of them would not understand
| _jif_ , or would only get it because this issue has some
| history now. _gif_ on the other hand has no friction.
|
| Ghengis Khan for example sounds very different from its
| original Mongolian pronunciation. And there is a myriad
| others as well.
| LocalH wrote:
| The whole debate seems to be a modern phenomenon to me -
| from my anecdotal experience back in the day, it was
| never questioned by computer enthusiasts that it was
| pronounced "jif".
| eCa wrote:
| I (as a non-native English speaker) have pronounced it
| with a hard g since first i saw it (mid '90s) and many
| years before I learned how the creator preferred it to be
| pronounced.
|
| I continue to pronounce it how I prefer it, not as a
| slight, but most people here would be surprised by the
| soft g.
|
| If I ever meet him I'll attempt to pronounce it soft-g.
|
| On the other hand, even though my name exists and is
| reasonably common in English, I'm fairly certain neither
| you or the GIF creator would address me the way I
| pronounce my name. I would understand anyway, and
| wouldn't care one bit.
| npteljes wrote:
| I have the same experience - but with _gif_. Mind you, me
| and my circle are not native English speakers.
|
| The debate itself is old. "Since the 90s" Wikipedia says,
| and keep in mind the format was is from 1987 - so I would
| say the debate is on from the get-go. Appropriate, too,
| if you think back, arguing about this kind of stuff was
| pretty common. Emacs vs vim, browser wars, different
| kinds of computers, tribalism everywhere.
|
| https://en.wikipedia.org/wiki/Pronunciation_of_GIF
| bigfishrunning wrote:
| pronounce the jraphics interchange format any way you want,
| everyone knows what you're talking about anyway -- try not
| to get so worked up. It's not the shopping cart problem,
| because no-one is measurably harmed by not choosing the
| same pronunciation as you.
| LocalH wrote:
| i'll start using hard-g gif when you start saying "jfeg"
| ;)
| yuters wrote:
| Pronouncing it like that would invite confusion as the word
| ping is often used in messaging.
| eviks wrote:
| Ha, been doing it "wrong" my whole life!
| ProgramMax wrote:
| Even though I know about this, I still pronounce it as letters.
| :)
| qwertfisch wrote:
| 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 wrote:
| > 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 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 wrote:
| zlib/deflate already has the same issue. It is mitigated
| somewhat by PNG row filters.
| adgjlsfhk1 wrote:
| 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 wrote:
| 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
| illiac786 wrote:
| I really don't get it. Why, but why? It's already confusing as
| hell, why create yet another standard (variant) with no unique
| selling point?
| pmarreck wrote:
| JPEG XL is not a "variant", it is a completely new algorithm
| that is also fully backwards-compatible with every single
| JPEG already out there, of which there are probably billions
| at this point.
|
| It also has pretty much every feature desired in an image
| standard. It is future-proofed.
|
| You can losslessly re-compress a JPEG into a JPEG-XL file and
| gain space.
|
| It is a worthy successor (while also being vastly superior
| to) JPEG.
| illiac786 wrote:
| I was referring to the new PNG, not to JPEG XL.
| sdenton4 wrote:
| Looking at TFA, it's placing in the spec a few things
| that are already widely stacked onto the format (such as
| animation). This is a very sensible update, and backwards
| compatible with existing PNG.
| illiac786 wrote:
| Not sure expanding PNG capabilities is sensible, looking
| at the overall landscape of image formats.
| dveditz_ wrote:
| The capabilities are already expanded in most common
| implementations. This update is largely blessing those
| features as officially "standard".
| BobaFloutist wrote:
| Is there any risk that if I open a JPEG-XL in something
| that knows what a JPEG is but not what a JPEG-XL is and
| then save it, it'll get lossy compressed? Backwards
| compatibility is awesome, but I know that if I
| save/upload/share/copy a PNG, it shouldn't change without
| explicit edits, right?
| illiac786 wrote:
| a sw that does not know what jpeg xl is, will not be able
| to open jxl files. How would it?
|
| Not sure what the previous poster meant with "backward
| compatible" here. jxl is a different format. It can
| include every information a jpeg includes, which then
| maybe qualifies as "backward compatible" but it still is
| a different format.
| liuliu wrote:
| JPEG XL has the mode that in layman's word, allow bit-by-
| bit round-trip with JPEG.
|
| Original JPEG -> JPEG XL -> Recreated JPEG.
|
| Sha256(Original JPEG) == Sha256(Recreated JPEG).
|
| That's what people meant by "backward compatible".
| colejohnson66 wrote:
| That's not "backwards compatible", but "round tripable"
| or "lossless reencode"
| BobaFloutist wrote:
| Ah, got it. I assumed it was a losselessly compressed
| JPEG with metadata telling modern software not to
| compress differently but that older software would open
| as a normal JPEG, but I guess they meant something else
| with "backward compatible".
| dylan604 wrote:
| > You can losslessly re-compress a JPEG into a JPEG-XL file
| and gain space.
|
| Is that gained space enough to account for the fact you now
| have 2 files? Sure, you can delete the original jpg on the
| local system, but are you going to purge your entire set of
| backups?
| illiac786 wrote:
| if you do not want to delete the original jpeg, there is
| no point in converting them to jpeg xl I would say.
|
| Unless serving jxl and saving bandwidth, while increasing
| your total storage, is worth it to you.
| bmn__ wrote:
| > just
|
| https://caniuse.com/jpegxl
|
| No one can afford to "just". Five years later and it's only one
| browser! Crazy.
|
| Browser vendors must deliver, only then it's okay to admonish
| an end user or Web developer to adopt the format.
| Dylan16807 wrote:
| Adopt it anyway. Add a decoder. Don't let google bully you
| out of such a good format.
| mikae1 wrote:
| _> There is just no need for a PNG update, just adopt JPEG XL._
|
| Tell that to Google. They gave up on XL in Chrome[1] and
| essentially killed its adoption.
|
| [1] https://issues.chromium.org/issues/40168998#comment85
| rhet0rica wrote:
| From reading that, "gave up" seems to mean "deliberately
| killed it so their own WebP2 wouldn't have competition."
| Behold the monopoly at the apex of its power.
| ccarnino wrote:
| I can't believe the standard is 20yo.
| naikrovek wrote:
| Doesn't PNG already support 16 bits per color channel and an
| arbitrary number of color channels?
| ProgramMax wrote:
| 16-bit, yes. Arbitrary channel count, no. However, HDR is more
| than just bitcount.
| aizk wrote:
| 20 years?? What took so long.
| eabeezxjc wrote:
| we need transparent (like gif)
|
| !!!
| ProgramMax wrote:
| PNGs have supported transparency since day 1 :)
| cptcobalt wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| ecshafer wrote:
| 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 wrote:
| 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 wrote:
| 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".
| joshmarinacci wrote:
| 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 wrote:
| 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 wrote:
| no, GP meant they add the JSON text to the meta data of the
| image as comment.
| bitpush wrote:
| 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_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 wrote:
| 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 wrote:
| 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.
| LeifCarrotson wrote:
| They're not saving text, they're saving an idea - a "map" or
| a "CAD model" or a "video game skin" or whatever.
|
| Yes, a hypothetical user's sprinker layout "map" or whatever
| they're working on is actually composed of a few rectangles
| that represent their house, and a spline representing the
| garden border, and a circle representing the tree in the
| front yard, and a bunch of line segments that draw the pipes
| between the sprinkler heads. Yes, each of those geometric
| elements can be concisely defined by JSON text that defines
| the X and Y location, the length/width/diameter/spline
| coordinates or whatever, the color, etc. of the objects on
| the map. And yes, OP has a rendering engine that can turn
| that JSON back into an image.
|
| But when the user thinks about the map, they want to think
| about the image. If a landscaping customer is viewing a
| dashboard of all their open projects, OP doesn't want to have
| to run the rendering engine a dozen times to re-draw the
| projects each time the page loads just to show a bunch of
| icons on the screen. They just want to load a bunch of PNGs.
| You could store two objects on disk/in the database, one
| being the icon and another being the JSON, but why store two
| things when you could store one?
| meindnoch wrote:
| Check what draw.io does when you download a PNG.
| dtech wrote:
| A fun trick, but I wouldn't want to explain to users why their
| things are saved as a .png, not why their things is lost after
| they opened and saved the PNG in Paint.
| KetoManx64 wrote:
| If a user is using paint to edit their photos, they're 100%
| not going to be interested in having the source document to
| play around with.
| geekifier wrote:
| This is also how Valetudo delivers robot map data to Home
| Assistant https://hass.valetudo.cloud.
| neuronexmachina wrote:
| This would be great for things like exported Mermaid diagrams.
| paisawalla wrote:
| Are you the developer of draw.io?
| shiryel wrote:
| That is also how Krita stores brushes. Unfortunately, that can
| cause some unexpected issues when there's too much data [1][2].
|
| [1] - https://github.com/Draneria/Metallics-by-Draneria_Krita-
| Brus...
|
| [2] - https://krita-artists.org/t/memileo-impasto-
| brushes/92952/11...
| oakwhiz wrote:
| If a patch is needed for libpng to get around the issue,
| maybe Krita should vendor libpng for usability. It's not
| unreasonable for people to want to create gigantic files like
| this.
| speps wrote:
| Macromedia Fireworks did it 20 years ago, the PNG was the
| default save format. Of course, it wasn't JSON stored in
| there...
| usef- wrote:
| I was going to say the same thing. It was nice as their
| native save format could still be opened anywhere.
|
| But you did need to remember to export if you didn't want the
| extra fields increasing the file size. I remember finding
| fireworks pngs on web pages many times back then.
| IvanK_net wrote:
| Macromedia did this when saving Fireworks files into PNG.
|
| Also, Adobe saves AI files into a PDF (every AI file is a PDF
| file), and Photoshop can save PSD files into TIFF files (people
| wonder why these TIFFs have several layers in Photoshop, but
| just one layer in all other software).
| giancarlostoro wrote:
| > Macromedia did this when saving Fireworks files into PNG. I
| forgot about this..
|
| Fireworks was my favorite image editor, I don't know that
| I've ever found one I love as much as I loved Fireworks. I'm
| not a graphics guy, but Fireworks was just fantastic.
| IvanK_net wrote:
| BTW. I am the author of https://www.photopea.com , which is
| the only software that can open Fireworks files today :D If
| you have any files, try to open theim (it runs instantly in
| your browser).
|
| https://community.adobe.com/t5/fireworks-discussions/open-
| fi...
| osetnik wrote:
| > save a JSON representation of your document as a comment
| field inside of a PNG
|
| Can you compress it? I mean, theoretically there is this 'zTXt'
| chunk, but it never worked for me, therefore I'm asking.
| dragonwriter wrote:
| This is also what many AI image gen frontends do, saving the
| generation specs as comments so you can open the image and get
| prompt and settings (or, for, e.g., ComfyUI, full workflows)
| loaded to tweak.
|
| Really, I think its pretty common for tools that work with
| images generally.
| akx wrote:
| This is what stable-diffusion-webui does too (though the format
| is unfortunately plaintext); ComfyUI stores the node graph as
| JSON, etc.
| razorfen wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| joquarky wrote:
| The Amiga was quite a platform. Glad to know that it had some
| long term influence.
| kfkdjajgjic wrote:
| 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 wrote:
| 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_ wrote:
| Removed MNG and started work on APNG 20 years ago!
| https://bugzilla.mozilla.org/show_bug.cgi?id=257197
| rynop wrote:
| 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 wrote:
| Phoptoshop supports the HDR part. But you are right, it does
| not support the APNG part.
| ProgramMax wrote:
| 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 wrote:
| 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 wrote:
| Sure!
|
| Chris Lilley--one of the original PNG co-authors--has a post
| with an example HDR image: 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&lab...
|
| Although, that image is just a boring teal. See it live in
| your browser here: https://wpt.live/png/cicp-chunk.html
|
| For an example of APNG, you can use Wikipedia's images:
| 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 wrote:
| Thanks, I appreciate all of these links. :)
| jacekm wrote:
| Thank you for the examples. I tried the one with a pink
| cake. Turns out that on my machine only web browsers are
| capable of displaying the image properly. All viewers
| (IrfanView, XnView, Nomacs, Windows Photos) and editors
| (Paint .NET, GIMP) that I've tried only showed the "washed
| out" picture.
| ProgramMax wrote:
| Yeah. We were able to get buy-in from some big players.
| We cannot contact every group, though. My hope is since
| big players have bought in, others will hear the message
| and update their programs.
|
| Sooooo file some bugs :D
|
| Also, be kind to them. This literally launched yesterday.
| derefr wrote:
| So, I'm a big fan of metaformats with generalized tooling
| support. Think of e.g. Office Open XML or ePub -- you don't
| need "an OOXML parser" / "an ePub parser" to parse these;
| they're both just zipped XML, so you just need a zipfile
| library and libxml.
|
| For the lifetime of PNG so far, a PNG file has _almost, but
| just barely not_ , been a valid Interchange File Format (IFF)
| file.
|
| IFF is a great (simple to understand, simple to implement
| support for, easy to generate, easy to decode, memory-
| efficient, IO-efficient, relatively compact, highly
| compressible) metaformat, that more people should be aware of.
|
| However, up to this point, the usage of IFF has consisted of:
|
| * some old proprietary game-data and image formats from the
| 1980s that no modern person has heard of
|
| * some popular-yet-proprietary AV formats [AIFF, RIFF] that
| nobody would write a decoder for by hand anyway (because they
| would need a DSP library to handle the resulting sample-stream
| data anyway, and that library may as well offer container-
| format support too)
|
| * The object files of an open but uncommon language runtime
| (Erlang .beam files), where that runtime exposes only high-
| level domain-specific parsing tooling (`beam_lib`) rather than
| IFF-general decoding tooling
|
| * An "open-source but corporate-steered" image format that
| people are wary of allowing to gain ecosystem traction (WebP --
| which is more-specifically a document in a RIFF container)
|
| * And PNG... but non-conformantly, such that any generic IFF
| decoder that could decode the other things above, would choke
| on a PNG file.
|
| IMHO, this is a major reason that there _is_ no such thing as
| "generalized IFF tooling" today, despite the IFF metaformat
| having all the attributes required to make it the "JSON of the
| binary world". (Don't tell me about CBOR; ain't nobody hand-
| rolling a CBOR encoder out of template strings.)
|
| If you can't guess by now, my wishlist item for PNGv3, is for
| PNG files to somehow _become_ valid /conformant IFF files --
| such that the popularity of PNG could then serve as the
| bootstrap for a real IFF tooling ecosystem, and encourage
| awareness/use of IFF in new greenfield format-definition use-
| cases.
|
| ---
|
| Now, I've written PNG parsers, and generic IFF parsers too.
| I've even tried this exact unification trick before (I wanted
| an Erlang library that could parse both .beam files and PNG
| files. $10 if you can guess the use-case for that!)
|
| Because of this, I know that "making PNG valid per IFF" isn't
| really possible _by modifying the PNG format_ , while ensuring
| that the resulting format is decodable by existing PNG
| decoders. If you want all the old [esp. hardware] PNG parsers
| to be compatible with PNGv3s, then y'all can't exactly do
| anything in PNGv3 like "move the 4-byte CRC inside the chunk as
| measured by the 4-byte chunk length" or "make the CRCs into
| their own chunks that reference the preceding record".
|
| But I'm not proposing that. I'm actually proposing the
| opposite.
|
| Much of what PNGv2 did in contravention of the IFF spec, is
| honestly _a pretty good idea in general_. It 's all stuff that
| could be "upstreamed" -- from the PNG level, to the IFF level.
|
| I propose: formalizing "the variant of IFF used in PNG" as its
| own separate metaformat specification -- breaking this
| metaformat out from the PNG spec itself into its own standards
| document.
|
| This would then be the "Interchange File Format specification,
| version 2.0" (not that there was ever a formal IFFv1 spec; we
| all just kind of looked at what EA/Commodore had done, and
| copied it in our own code since it was so braindead-easy to
| implement.)
|
| This IFF 2.0 spec would formalize, at least, a version or
| "profile" of IFF for which PNGv2 images are conformant files.
| It would have chunk CRCs; chunk attribute bits encoded for
| purposes of decoders + editors via meaningful chunk-name
| letter-casing; and an allowance for some number of garbage
| bytes before the first valid chunk begins (for PNG's leading
| file signature that is not itself a valid IFF chunk.)
|
| This _could_ be as far as the IFF 2.0 spec goes -- leaving
| IFFv1 files non-decodable in IFFv2 parsers. But that 'd be a
| shame.
|
| I would suggest going further -- formalizing a second IFFv2
| "profile" against which IFFv1 documents (like AIFF or RIFF
| files) are conformant; and then specifying that "generic"
| IFFv2-conformant decoders (i.e. a hypothetical "libiff", not a
| format-specific libpng) MUST implement support for decoding
| both the IFFv1-conforming and the PNGv2-conforming profiles of
| IFF.
|
| It _could_ then be up to the IFF-decoding-tooling user (CLI
| command user, library caller) to determine which IFFv2
| "profile" to apply to a given document... _or_ the IFFv2 spec
| could also specify some heuristic algorithm for input-document
| "profile" detection. (I think it'd be pretty easy; find a
| single chunk, and if what follows its chunk-length is a CRC
| that validates that chunk, then you have the PNGv2-like
| profile. Whereas if it's not that, but is instead four bytes of
| chunk-name-valid character ranges, then you've got the
| IFFv1-like profile. [And if it's neither, then you've got a
| file with a corrupted first chunk.])
|
| ---
|
| And, if you want to go really far, you could then specify a
| third entirely-novel "profile", for use in greenfield IFF
| applications:
|
| * A few bytes of space aren't so precious; we can hash things
| much faster these days, with hardware-accelerated hashing
| instructions; and those instructions are also for hashes that
| do much better than CRC to ensure integriaty. So either replace
| the inline CRCs with CRC chunks, or with nested FORM-like
| container records (WCRC [len] [CRC4] [interior chunk]). Or just
| skip per-chunk CRCs and formalize a fHsh chunk for document-
| level integrity, embedding the output of an arbitrary hash
| algorithm specified by its registered
| https://github.com/multiformats/multihash "hash function code".
|
| * Re-widen the chunk-name-valid character set to those valid in
| IFFv1 documents, to ensure those can be losslessly re-encoded
| into this profile. To allow chunks with non-letter characters
| to have a valid attribute decoding, specify a document-level
| per-chunk-name "attributes of all chunks of this type" chunk,
| that can either be included into a given concrete format's
| header-chunk specification, or allowed at various points in the
| chunk stream per a concrete format's encoding rules (where it
| would then be expected to apply to any successor + successor-
| descendant chunks within its containing chunk's "scope.") Note
| that the goal here is to _keep_ the attribute bits in some way
| or another -- they 're very useful IMHO, and I would expect an
| IFF decoder lib to always be emitting these boolean chunk-
| attribute fields as part of each decoded chunk.
|
| * Formalize the magic signature at the beginning into a valid
| chunk, that somehow encodes 1. that this is an IFF 2.0
| "greenfield profile" document (bytes 0-3); 2. what the concrete
| format in use is (bytes 4-7). (You _could_ just copy
| /generalize what RIFF does here [where a RIFF chunk has the
| semantics of a LIST chunk but with a leading 4-byte chunk-name
| type], such that the whole document is enclosed by a root chunk
| -- though this is painful in that you need to buffer the entire
| document if you're going to calculate the root-chunk length.)
|
| I'm just spitballing; the concrete details of such a greenfield
| profile don't matter here, just the design goal -- having a
| profile into which both IFFv1 and PNGv2 documents could be
| losslessly transcoded. Ideally with as minimal change to the
| "wider and weirder/more brittle ecosystem" side [in this case
| that's IFFv1] as possible. (Compare/contrast: how HTML5
| documents are a profile of HTML that supersedes both HTML4 and
| XHTML1.1 -- supporting both unclosed tags _and_ XML-namespaced
| element names -- allowing HTML4 documents to parse "as" HTML5
| without rewrites, and XHTML1.1 documents to be transcoded to
| HTML5 by just stripping some root-level xmlns declarations and
| changing the doctype.)
| ProgramMax wrote:
| Strangely, I was familiar with AIFF and RIFF files but never
| made the connection that they're both IFF. I hadn't known
| about IFF before your post. Thank you :)
|
| W3C requires that we do not break old, conformant specs.
| Meaning if the next PNG spec would invalidate prior specs,
| they won't approve it. By extension, an old, conformant
| program will not suddenly become non-conformant.
|
| I could see a group of people formalizing IFFv2, and adapting
| PNG to it. But that would effectively be PNGIFF, not PNG. It
| would be a new spec. Because we cannot break the old one.
|
| That might be fine. But it comes with a new set of problems,
| like adoption.
|
| Soooo I like the idea but it would probably be a separate
| thing. FWIW, it would actually be nice to make a formal IFF
| spec. If there was no governing body that owns it, we can
| find an org and gather interest.
|
| I doubt W3C would be the right org for it. ISO subgroup??
| NotAnOtter wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-25 23:00 UTC)