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.
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.
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.