You might find it helpful to look up existing PNG decoders/encoders that have already been written in WebAssembly in particular, if you are looking for any more resources as to how to do it all.
This is quite helpful. I will most likely be using these resources soon as this looks like the decoding part but right now still on encoding/ rgba image to png conversion.
This source seems most in depth Implementing a Basic PNG reader the handmade way | Handmade Network . May probably follow this when I get there.
I’ve got tasks at hand, but I’ll keep up with your repo and do code review/etc until I can spend more time actively on this task.
And of course, anything you can help with would be great.
Another weekly update. Finished all raw image preprocessing operations before encoding procedures. Each of the functions push the data structure that holds the state of a single chunk so that it transfers over to the nth chunk (i.e. for indexing, the pallete gets returned for mapping the next chunk with previous chunk pixels)
Disclosure this is only for 8 bith depth channels i.e. rgba =(0-255,0-255,0-255,0-255). It is the most general use case and in the bounty introduction, it uses Buffer.Buffer<Buffer.Buffer> (see picrel below) so I assume its cool. I shall wait a week to see if there is any objection. I am praying none of you raise one as it will make my life much easier haha . But in all seriousness, i’ll wait a little and if no one objects, I will continue past this point of no return.
I’ve used Buffer.Buffer<Buffer.Buffer<#candyvalue>> ->workspace in some past work. It is a good construct for data that you need to manipulate. It also is helpful to keep things in 2MB chunks which is important if you want to ship data around the IC. candy_library/workspace.mo at main · aramakme/candy_library · GitHub
It basically creates a data structure like [[#Nat(height)],[#Nat(width)], [#Bytes(chunk1),#Bytes(chunk2)]]. It also has helper functions that will let you ship the thing to AddressedChunks that can be shipped to stable memory for upgrades and reconstituted.
Ooouu wait I see how youre using that now. That buffer <buffer> is for initial params as opposed to raw data. That actually wasn’t what I was unsure about, it was about the raw chunk format. But actually, you answered my question indirectly. I just checked the #bytes type for candy and it matches exactly what I was trying to do. Thanks. I will continue to give little updates weekly.
New update, just added alpha compaction → I forgot to do this the last update for preprocessing.
Check the github and the test folder to view my progress summary. Got a little busy the last few weeks but back to getting this done.
Now moving onto the actual encoding of the raw image preprocessing.
Been backed up this last month but I still planning to work on it. If there’s anyone that wants to fill in and work faster either to takeover or work in conjunction I’m okay with that.
Hi there! Have a bit of a background in image processing and have been thinking about exploring Motoko – just curious, but has there been any further progress on this bounty / is it still open?
Hi, I’m quite interested in this bounty. I have finished a sha3 lib in motoko by myself. And I’m a experienced rust developer in Crypto area. Before I came into crypto, I was a graduate student major in Bio Imaging(cryoEM denoise and reconstruction), so I have knowledge in image processing.
It seems like this task has already been assigned, but my understanding is that being assigned doesn’t guarantee its completion. Therefore, I would like to give it a try and do my best to complete the task. If I succeed, I would appreciate it if I could receive the bounty just like the person who was originally assigned to it.
The package you referenced, png.mo, is strictly an Adler32 implementation and is better kept seperate.
Work should first focus on implementing zlib correctly, as it is a prerequesite for png anyway. Iceypee seems to have instead taken a bottom-up approach so far.
Focusing on the subtasks, namely the independent subformats of PNG, I see that we could greatly benefit from sharing work between us three. Zlib, and hence DEFLATE, is an important step towards a working enco/deco and should reside in their own packages. In the meanwhile, someone else could independently focus on, say, filters and color modes.
Hence, I propose the following subtasks, which, if you’re down for it, each one of us should pick from and start working on.
A DEFLATE package, and later a Zlib package utilizing it, both independent from PNG itself
chunk stream parsing, filling out metadata structs
pixel encoding/decoding itself, along with filters and interlacing (if we want to support it from the start)
crc32, in its own package, and paeth filtering in its own file
We should agree on an interface to metadata, both global and chunk-wise, if we are to proceed with PNG-specific implementation seperately. I’d like to know your thoughts.
I would like to take over this project. And I am happy to share the bounty if others have independent and complete work in subtasks as piens says above. @skilesare