Magica WASM builds

[cancerberoSgx]

@KnicKnic Just want you to know I was lately playing with my own ImageMagick WASM builds and I finally was successful. Now I have 5mb working wasm with these project's libraries plus webp, freetype, fftw (fast fourier), turbo-jpeg, openjpeg. I'm now working on integrating a couple more since now I think I'm understanding the process better.

https://github.com/cancerberoSgx/magica/tree/master/magick-wasm

But most importantly, besides a couple of exceptions, I'm using the original / latest repositories of IM and libraries without having to hack any files (like configure.ac). The exceptions were libpng (which I needed to include your changes to latest versions) and libjpeg (using your clone).

For libpng, I'm planning to PR ImageMagick/png repo with your changes using EMSCRIPTEN macros appropriately. Unfortunately, I can figure out what where your changes for libjpeg to do the same, if you more or less remember what did you needed to change there please tell me - the commits of your clone repo are kind of useless...

At last there is a script to clone my project magica, replace magick.wasm with the generated one and run magica's tests to check everything is OK.

Now I'm working on make this more configurable, both IM configuration and libraries opt-in. also change magica's tests to be smarter and check if the apability/format they use is available or not so they don¡t blindly change.

Well, I would like this project (WASM-ImageMagick) to use some of this - but my scripts are currently too different to this's so I want to discuss with you first what are your thoughts.

Also I would like to contribute some of this also to Magick.Native too.

Thanks

[KnicKnic]

I tried to make the commits clear for libjpeg. Here is the log

commit fbaf3bf05b91207ca0a8c96fabc7aa39795b8d78 (HEAD -> master, origin/master, origin/HEAD)
Author: KnicKnic <[email protected]>
Date:   Fri Jul 6 23:47:14 2018 -0700

    remove all trace routines due to mismatch function pointer types in wasm

commit 84d775c0cf6319a54168d361116f7082a18539db
Author: KnicKnic <[email protected]>
Date:   Fri Jul 6 23:43:05 2018 -0700

    Update to 9c of 14-Jan-2018 from http://www.ijg.org/

[cancerberoSgx]

commit 84d775c0cf6319a54168d361116f7082a18539db
Author: KnicKnic [email protected]

This is the one that's not clear. There is some new files and changes I can see, but the rest of the files (180) seems to be just the same (with different indentation ?)

Right now I'm fine using your version. But from what I heard, jpeg-turbo is much faster (x5) than libjpeg and unfortunately it didn't worked for me. I will try again and comment here the error that, if any probably means it needs to be patched like you did for libjpeg.

Also I keep working on https://github.com/cancerberoSgx/magica/tree/master/magick-wasm and now build scripts are generated from templates that accept a context like:

export interface Context {
  type?: 'debug'|'production'
  /** 
   * the greater the more memory it consumes 
   */
  quantumDepth?: '8'|'16'|'32',
  /** 
   * High resolution for pixel transformation. Impacts speed. Default value: false
   */
  noHdri?: boolean
  /**
   * Name of the folder inside `outputFolder` where scripts will be generated 
   */
}

Will keep working on a CLI tool so it's easier to use/install. Probably I will end up moving this to a separate project - would be awesome if this could be integrated somehow into your project.

Also I will try to parametrize libraries and add more. Then I will modify magica's tests to be smarter and don't blindly fail when a format/capability is not supported.

Would like to know your opinions / suggestions.

Thanks

[KnicKnic]

84d775c0cf6319a54168d361116f7082a18539db As I said in the commit, this is just updating the source code to the 9c version(they are not my changes) the library only has a stale mirror in github so I took the most recent drop at the time and applied it. I then fixed it for wasm in the other commit. I am not really interested in trying to fix turbo as well (but i have no problem using it if someone fixes it).

I think it would be best to generate the build context using cmake and not type script. I am ok with taking a typescript generator if you don’t have time to learn cmake

[cancerberoSgx]

I think it would be best to generate the build context using cmake and not type script. I am ok with taking a typescript generator if you don’t have time to learn cmake

Makes sense. cmake is a new language for me but seems to be the right technology for this. Will take note for the future, right now I want to focus on making things work - since I'm not very capable with bash neither I decided this "javascript - templates" approach and custom command line tool. Since it ends up generating shell scripts is not a hard dependency - we can migrate different versions of this sh outputs to cmake later.

I would like to know your opinion about "release types" - These are some examples I'm considering:

• production: focus on optimize speed, memory and output size, in that order. Unfriendly for tracing / debugging issues
• debug: has lots of metadata to debug issues - unoptimized - very big, source maps and emcc debugger support - slow to compile
• incremental : builds the wasm as fast as possible - for port developers - combined with --noClean and other flags can build only concrete libraries and reuse existing PREFIX output - even skipping ImageMagick config and build and just linking it. (Could use autoconf --cache-file - I made it work and improves speed but was more a pain right now).

Examples:

magick-wasm --type production --libraries zlib,libpng,libjpeg--quantumDepth 8 --noHdri --dir prod_png-jpeg_Q8

magick-wasm --type production --dir prod_defaults

# This will compile only webp and not even reconfigure/build ImageMagick, just make the final link only. if the folder webp_build_issue doesn't exists (the first time) it will build everything
magick-wasm --type incremental --noClean --libraries webp --skipImageMagickConfig --skipImageMagickBuild --dir webp_build_issue

I have some of this implemented, but most parts are just ideas/proposals - Would love to know if this makes sense to you or if it's too much or unnecessary.

[cancerberoSgx]

@KnicKnic An update about progress in magica's wasm build and libraries (all included default magica's wasm and have tests to verify they work) :

• lcms (tested with two format of profiles)
• openjpeg
• raw
• autotrace (works but I decided not to include it in magica)

Failed to build libde265 and libheif because undefined symbols and include files not found (like cpu.h) - I didn't have much time to research why though.

Also I would like to know if I should include https://github.com/dlemstra/Magick.Native/tree/master/src/Magick.Native since I really not understand which features or improvements that could have in our context (browser). Do you have any insights ?

Well these are current build features and delegates I have (also the wasm is now 8mb):

convert -version
Version: ImageMagick 7.0.8-60 Q16 x86_64 2019-08-06 https://imagemagick.org
Copyright: © 1999-2019 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher HDRI 
Delegates (built-in): fftw freetype jng jp2 jpeg lcms png raw tiff webp zlib

also I'm building the production wasm with a couple of more emcc flags which frankly i'm not 100% sure of(feedback is welcome) and I'm thinking of adding -fPIC as Native does:

-O3 --llvm-lto 3 --llvm-opts 3 -fno-rtti -fno-exceptions -s DISABLE_EXCEPTION_CATCHING=1 -s NODEJS_CATCH_EXIT=0 -s ASSERTIONS=0 -s AGGRESSIVE_VARIABLE_ELIMINATION=1

Also I had trouble adding closure though emcc in the build (it renames globals like FS which breaks magica) - i think this is an emcc issue though will try to discuss there)

as said before I would like to include this (or at least freetype , webp, lcms and perhaps fftw) since those are useful, bit as said I would need to change the build.sh a lot (mostly adding --prefix and referencing files from there). Are you working on this or have some plans on this ?

[KnicKnic]

as said before I would like to include this (or at least freetype , webp, lcms and perhaps fftw) since those are useful, bit as said I would need to change the build.sh a lot (mostly adding --prefix and referencing files from there). Are you working on this or have some plans on this ?

Since people have asked for freetype and lcms they are obvious things to include. Webp is another common one I could see people wanting. I say we just add what people ask for.

Me I am interested in only tiff, jpeg, and png. But due to using service workers to cache the wasm I am less caring about the size of the download due to not having mobile use cases.

[cancerberoSgx]

I agree, I will try to reserve some time for a PR, the easy thing would be to just replace build.sh with my scripts as they are - that will change the build radically. To integrate wha I have in the existing build.sh could be hard to do - so do you agree to just replace build.sh ? thanks

[KnicKnic]

I agree, I will try to reserve some time for a PR, the easy thing would be to just replace build.sh with my scripts as they are - that will change the build radically. To integrate wha I have in the existing build.sh could be hard to do - so do you agree to just replace build.sh ? thanks

as long as CICD still works, I am fine.