<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>.Net on Pi Stack</title>
    <link>https://www.pistack.xyz/tags/.net/</link>
    <description>Recent content in .Net on Pi Stack</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 09 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.pistack.xyz/tags/.net/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>C# Image Processing in 2026: ImageSharp vs SkiaSharp vs Magick.NET — Which One Should You Actually Use?</title>
      <link>https://www.pistack.xyz/posts/2026-09-09-csharp-image-processing-imagesharp-skiasharp-magicknet-comparison/</link>
      <pubDate>Wed, 09 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://www.pistack.xyz/posts/2026-09-09-csharp-image-processing-imagesharp-skiasharp-magicknet-comparison/</guid>
      <description>&lt;p&gt;Your .NET service just started generating user avatars, and the product owner casually asks for &amp;ldquo;thumbnails, WebP output, and maybe a watermark — should be simple, right?&amp;rdquo; Then the ticket lands with three hard requirements: no external HTTP calls to a resizing microservice, sub-100 ms p95 latency, and licensing that legal won&amp;rsquo;t flag. Suddenly &amp;ldquo;just use a library&amp;rdquo; means picking between three very different philosophies: a fully managed pixel pipeline, a native 2D canvas binding, and a 200-format Swiss-army wrapper around ImageMagick. Pick wrong and you&amp;rsquo;ll be rewriting image code — or worse, paying license fees — a year from now.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
