Ryan-Millard/Img2Num

CautionThis issue has been claimed by @saptadeep12, so it is not recommended that you work on it. For @saptadeep12: If you would like to revoke your claim, comment /untake Context Img2Num has a Discord server, but it isn't linked anywhere on img2num.dev, in the README, or in CONTRIBUTING.md, so new contributors can't find it. Invite link: https://discord.com/invite/BHjxcCqAnU What to do Add a Discord entry to the "Community" column of the footer in docs/docusaurus.config.js (next to GitHub, Issues, Discussions). Remove the GitHub text (not the icon or link) and put a Discord icon with a link to that invite link in the website's navbar (edit it in docs/docusaurus.config.js). Add Discord to the "Questions?" section of CONTRIBUTING.md and to docs/docs/contributing/index.md. Add a Discord badge alongside the existing badges in every README.md: README.md packages/js/README.md packages/py/README.md example-apps/html-js/README.md docs/README.md Acceptance criteria The link appears

CautionThis issue has been claimed by @mrunalC27, so it is not recommended that you work on it. For @mrunalC27: If you would like to revoke your claim, comment /untake Context The JavaScript docs have separate installation, requirements and usage pages (docs/docs/js/). Python only has a single docs/docs/py/index.md with one short example. Python users need a fuller walkthrough and must mirror the JavaScript documentation in it's layout and file structure. What to do Create docs/docs/py/usage.md (and link it from docs/docs/py/index.md) covering: Loading an image as an RGBA NumPy array with both Pillow and OpenCV (OpenCV loads BGR, so show the conversion). The one-call pipeline: image_to_svg(...) and writing the result to a .svg file. Customising the pipeline with ImageToSvgConfig (e.g. kmeans={"k": 32}, min_thickness). The step-by-step pipeline: bilateral_filter → kmeans → labels_to_svg, explaining what each stage does. Common mistakes: passing RGB/BGR instead of RGBA; passin

CautionThis issue has been claimed by @sathyasri318, so it is not recommended that you work on it. For @sathyasri318: If you would like to revoke your claim, comment /untake Context example-apps/console-c/ and example-apps/console-cpp/ have no README, so someone browsing the repo can't tell what they do or how to run them. What to do Add a README.md to each folder covering: What the app demonstrates (load an image with stb_image, run the Img2Num pipeline, write PNG/SVG outputs). How to build and run it from the repo root: just build cpp, then just console-c <image> / just console-cpp <image>. Where the output files are written and what each one is. A short walkthrough of the key library calls in main.c / main.cpp. Keep it short - a page, not a tutorial. example-apps/html-js/README.md is the existing example to match.

CautionThis issue has been claimed by @Astrolyte, so it is not recommended that you work on it. For @Astrolyte: If you would like to revoke your claim, comment /untake Context example-apps/console-js-esm/index.mjs prints Usage: node index.js <image-path>, but the file is index.mjs. Both console-js-esm and console-js-cjs always write output.svg to the current working directory, so running them via just from the repo root drops the file in the root. What to do Fix the usage message in index.mjs. Accept an optional second argument for the output path in both apps (default: output.svg), and print the full path the SVG was written to. Keep the two apps' behaviour identical — they exist to show the same thing in CommonJS and ES modules. Acceptance criteria Both apps print the correct usage with no arguments. Both apps write to the given output path when one is passed. pnpm run lint:js and pnpm run format:check pass.

CautionThis issue has been claimed by @saptadeep12, so it is not recommended that you work on it. For @saptadeep12: If you would like to revoke your claim, comment /untake Context example-apps/console-cpp/main.cpp is the C++ "hello world" for the library, so it should model good modern C++. Currently: The comment // Force load as grayscale is wrong. The image is loaded with 4 channels (RGBA). There is a commented-out duplicate allocation left over. Buffers are managed with raw new[] / delete[]; std::vector would be safer and simpler. stbi_write_png(...) == 1 ? true : false can just be stbi_write_png(...) == 1. The output named console-cpp-output.png / blur_save_success is actually the bilateral-filtered image, so the names are misleading. res_svg (from labels_to_svg) is computed but never written; only res_svg2 is saved. What to do Fix the points above. For res_svg, either save it as a second SVG (as console-py does with result.svg and result2.svg) or remove it — say in the P