Retired: ICDevs.org Bounty #12 - PNG Encoder/Decoder - $14,000

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.

For instance there’s some interesting and useful discussion here: Space-efficient Embedding of WebAssembly in JavaScript | Matthew Petroff even though that’s a little more generic than the task at hand.

In case you hadn’t seen these, I had also found (besides the original PNG W3 spec) helpful:

Also in case you haven’t seen Quint’s work already done to this end: GitHub - aviate-labs/png.mo: [WIP] PNG Encoder/Decoder for Motoko his repos, like the examples Dfinity and associates provide, are often a good source of understanding how to code on the IC. On that note let me also point out skilesare’s work towards multi-canister scalability: GitHub - skilesare/pipelinify.mo: Move data chunks between canisters.

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.

3 Likes

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.

1 Like

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)

1 Like

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 :sweat_smile:. But in all seriousness, i’ll wait a little and if no one objects, I will continue past this point of no return.

2 Likes

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.

I’ve been considering playing with @icme 's StableBuffer GitHub - canscale/StableRBTree: Stable Red Black Trees in Motoko, but haven’t had a chance.

3 Likes

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.

1 Like

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.

4 Likes

btw, im literally reading down this spec sheet:
https://www.w3.org/TR/2003/REC-PNG-20031110/
while keeping my implementation aesthetic similar to GitHub - saschaklick/jspng: Javascript PNG image generator
in case you’re following along.

2 Likes

Any updates on this?

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.

This Bounty has increased to $14,000.

1 Like

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?

If not, would love to make a proper application!

Cheers,
Tommy

1 Like

It is open. I can request that you be assigned. You can get started. I am at ETHDenver this week, so I may be a bit out of pocket.

Awesome, ty! I’ll get a repo and more info about what I’m thinking about out tomorrow, have fun at ETHDenver!

1 Like

I’m also open if any help is needed, although it doesn’t seem like collabs are allowed. Will keep an eye.

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.

Thank you.

1 Like

Collars are fine if you guys organize it yourself and let me know.

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.

@tommy-a, @piens, @hanbu97

Any updates or desire to coordinate? Sounds like much of this might depend on @tomijaga 's work on the zip lib.

It looks like he hasn’t done any work in the last month so he may be willing to hand the bounty off to someone else. GitHub - NatLabs/deflate.mo: An Implementation of Gzip the Deflate compression algorithm

2 Likes

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

1 Like