lunapaint / png-codec Goto Github PK

Currently decoding is done in a strict only mode, where assertions that should be warnings still throw. Ideally there would be warnings and errors where warnings are gathered and returned to the embedder and errors throw. Along with this default mode, there should be a strict mode that fails when any warning is encountered.

Might also want to add an "info" severity for when chunk types are unrecognized but flagged as optional for example.

Would be great if files like this could be created from floating-point linear data:
(this file uses Rec. ITU-R BT.2100 PQ and will display with HDR colors on supported displays, like MacBook displays or properly configured windows systems, on Chrome)

I saw you in the 1.69 Release Party and was interested in your terminal.
I was wondering what kind of prompt engine are you using and if it is oh-my-posh would you mind sharing the theme please.

Added in Extensions to the PNG 1.2 Specification, v1.2.0.

http://www.libpng.org/pub/png/spec/register/pngext-1.4.0-pdg.html

Currently I use a git submodule to consume the lib, not sure I got the esm module right and the typings don't declare a module currently.

Currently a bunch of unit tests are skipped because either alpha and/or hue values don't end up matching the bmp converted in pngsuite. This is probably some optimization when saving the bmp but it would be ideal to have exact information.

Chunks:

• acTL: The Animation Control Chunk
• fcTL: The Frame Control Chunk
• fdAT: The Frame Data Chunk

https://wiki.mozilla.org/APNG_Specification

Generally I don't like using code coverage for large projects, but this is probably a good case since testing is extensive and it would help identify any edge cases not yet which could be added as extensions to pngsuite. Could then also add it to the claims on the readme

Currently the library assumes byteOffset is 0 of the backing buffer which can cause the wrong data to get loaded: microsoft/vscode#140632

This causes problems in particular when the buffer is given to a DataView because it doesn't consider ArrayBuffer.byteOffset.

Eg. width, height, bit depth, color type, etc.

Added in Extensions to the PNG 1.2 Specification, v1.2.0.

http://www.libpng.org/pub/png/spec/register/pngext-1.4.0-pdg.html

It's messy passing around all the options:

Would be better if that was just handleWarning(ctx, new ChunkError(...));

Added in Extensions to the PNG 1.2 Specification, v1.2.0.

http://www.libpng.org/pub/png/spec/register/pngext-1.4.0-pdg.html

IDecodedImage.warnings vs IDecodedImage.info for example.

Only remaining chunk in https://www.w3.org/TR/2003/REC-PNG-20031110/

Added in Extensions to the PNG 1.2 Specification, v1.2.0.

http://www.libpng.org/pub/png/spec/register/pngext-1.4.0-pdg.html

From http://fileformats.archiveteam.org/wiki/PNG

* Not doing to implement exIf as it's for test impls
** gIFt is deprecated

Added in Extensions to the PNG 1.2 Specification, v1.3.0.

http://www.libpng.org/pub/png/spec/register/pngext-1.4.0-pdg.html

In order to support custom/private png formats, or just chunks that aren't supported yet, the library should have some way of injecting "chunk decoders" that would provide this. For example with this feature before apng is done (#10) it should be possible to extend the lib to support apng with this feature.

@Tyriar Wow this lib looks really nice, grats for getting it done that sophisticated, must have been alot of work. I def. will look into it.

First I have a few questions about proper usage:

• In api.d.ts you state for decodePng:

• Note that it's best to drop references to both metadata and rawChunks as soon as they are no
• longer needed as they may take up a significant amount of memory depending on the image.

Does that mean, that the decoder carries the raw data along, thus should be removed manually from the returned IDecodedPng to free some memory?

• For terminal output I'm only interested in pixel data (rgba) + dimension notion. I see that is contained IImage32 and IImage64. Is the pixel data there always fully RGBA colored, or is there a catch with some image modes (e.g. paletted contains idx, thus needs another indirection to resolve to real colors)?
• The pixel being RGBA8888 - is that RGBA32 or ABGR32 aligned on LE? Not sure yet, if I'll need 32bit access pattern at all, but I found that being way faster than single channel handling in the sixel lib.
• Whats the deal with 32 vs. 64, what exactly determines the bit depth of channels and can I somehow tell the decoder to always output IImage32 or would I have to do the color reduction afterwards? Dont want to go the 16bit channel route for now, as it just puts the memory under even more stress.
• Later on I want to use the encoder for serialization. Are there any hints/pitfalls with PNG encoding in general (see me as a PNG noob here)?
• About those promises - at which level is encoding/decoding async? Is it timer based/cooperative, or some real worker concurrency?
• Is it possible to feed the decoder from arbitrary chunks (stream decoding)?

Sorry for so many questions, plz dont feel bugged by that, I dont need detailled answers but just some yes/no or a code pointer here and there.

Btw #15 would be a killer feature - imho APNG is a very nice, but sadly totally underrated format.

Renaming tsconfig.all.json to tsconfig.json will fix this

Added in Extensions to the PNG 1.2 Specification, v1.2.0.

http://www.libpng.org/pub/png/spec/register/pngext-1.4.0-pdg.html

Added in Extensions to the PNG 1.2 Specification, v1.2.0.

http://www.libpng.org/pub/png/spec/register/pngext-1.4.0-pdg.html

Added in Extensions to the PNG 1.2 Specification, v1.4.0.

http://www.libpng.org/pub/png/spec/register/pngext-1.4.0-pdg.html
http://png-dsig.sourceforge.net/

This image (edf5c1b0aa5b01eea5017290a286a173.png) has an extra byte after IEND which currently fails with error EOF while reading chunk length: