WebP سے AVIF ٹرانس کوڈنگ میں SSIMULACRA2: سورس کے لیے 60 اور پہلے سے lossy فائل کے لیے 65 کیوں

میرا ابتدائی compression rule کافی سادہ تھا: AVIF کو اس کم ترین quality پر encode کرنا جو اب بھی SSIMULACRA2 target 60 پاس کرے۔ بڑے image sets میں میں ایک representative sample کو 58 تک نیچے آنے دیتا تھا، جبکہ باقی samples کو 60 یا اس سے اوپر رہنا ضروری تھا۔

PNG اور عام source images کے لیے یہ rule مناسب تھا۔ پھر مجھے ایسے WebP ملنے لگے جو میرے پاس پہنچنے سے پہلے ہی زیادہ اعلیٰ معیار کے original سے lossy compress کیے جا چکے تھے۔

higher-quality original: ~2 MB
          ↓
      lossy WebP: ~100 KB
          ↓
          AVIF

کیا دوسری conversion بھی WebP کے مقابلے میں 60 پر پاس ہو جانی چاہیے؟ شروع میں مجھے لگا کہ ہاں۔ 60 تو 60 ہی ہے۔ لیکن اصل تبدیلی score میں نہیں، reference image میں تھی۔

Metric غلط نہیں تھا؛ reference بدل چکا تھا

SSIMULACRA2 ایک reference image کو distorted image سے compare کرتا ہے اور انہی دو inputs کے درمیان perceptual difference کو score دیتا ہے۔ یہ blur، ringing اور اضافی edges جیسے compression damage پر ردعمل کے لیے بنایا گیا ہے، اور اس کے شائع شدہ evaluation material میں JPEG، WebP، AVIF اور دوسرے codecs کی distortions بھی شامل ہیں۔ SSIMULACRA2](https://github.com/cloudinary/ssimulacra2/blob/main/README.md%22>SSIMULACRA2) documentation metric اور اس کے approximate quality anchors کی وضاحت کرتی ہے۔

جب میں اچھے source سے براہ راست AVIF encode کرتا ہوں تو comparison عملاً source → AVIF ہوتا ہے۔ اس صورت میں 60 کا score اسی conversion سے پیدا ہونے والے نقصان کو بیان کرتا ہے۔

لیکن پہلے سے lossy WebP کی اصل history مختلف ہوتی ہے:

original
   ↓ first lossy encode
WebP
   ↓ second lossy encode
AVIF

SSIMULACRA2 صرف WebP → AVIF دیکھتا ہے۔ اسے اس original کا علم نہیں جو WebP سے پہلے موجود تھا۔ WebP میں پہلے سے موجود artifacts reference کا حصہ بن جاتے ہیں۔

لہٰذا 60 کا score مجھے یہ بتا سکتا ہے کہ AVIF موجودہ WebP سے بہت زیادہ دور نہیں گیا، لیکن یہ نہیں بتا سکتا کہ final AVIF کھوئے ہوئے master سے کتنا دور ہے۔

Lossy transcoding دوسرا quality budget بناتا ہے

فرض کریں original میں صاف gradient ہے۔ پہلا encoder تھوڑا banding شامل کرتا ہے، لیکن WebP اب بھی قابل قبول دکھائی دیتا ہے۔ پھر میں اسی WebP کو AVIF میں encode کرتا ہوں۔ SSIMULACRA2 AVIF encoder کی اضافی degradation کو penalize کر سکتا ہے، مگر reference میں پہلے سے موجود damage کو نہیں۔

اسی لیے پہلے سے lossy image سے encoding، بہترین دستیاب source سے direct encoding کے برابر نہیں۔ libavif](https://github.com/AOMediaCodec/libavif/discussions/2640%22>libavif) project کی discussion بھی یہی عمومی نکتہ بیان کرتی ہے کہ پہلے سے موجود compression artifacts نئی AVIF میں منتقل ہو سکتے ہیں اگر input خود پہلے سے compressed ہو۔

اس کا مطلب یہ نہیں کہ AVIF ہر WebP artifact کو لازماً بڑھا دیتا ہے یا transcoding کبھی نہیں کرنی چاہیے۔ مطلب صرف یہ ہے کہ دوسرا encoder اس وقت کام شروع کرتا ہے جب original quality budget کا کچھ حصہ پہلے ہی خرچ ہو چکا ہوتا ہے۔

وہ policy جس پر میں آخرکار پہنچا

Canonical یا high-quality source: target 60، ایک sample کا floor 58۔
Lossless WebP: target 60، floor 58۔
Known lossy derivative: target 65، floor 63۔

اہم فرق JPEG اور WebP میں نہیں، بلکہ canonical source اور known lossy derivative میں ہے۔

WebP lossless بھی ہو سکتا ہے۔ WebP](https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification%22>WebP) lossless specification ایسے mode کی وضاحت کرتی ہے جو pixel values کو بالکل reconstruct کرتا ہے، اس لیے پچھلی lossy generation موجود نہیں ہوتی۔ دوسری طرف ایسا JPEG جس کے بارے میں معلوم ہو کہ وہ کئی lossy transformations سے گزر چکا ہے، اسے بھی پہلے سے compressed WebP جتنی احتیاط چاہیے۔

65 کیوں؟

SSIMULACRA2 میں کوئی rule نہیں جو کہے کہ دوسری lossy generation کے لیے بالکل پانچ اضافی points ضروری ہیں۔ مجھے ایسا کوئی rule نہیں ملا کیونکہ وہ موجود ہی نہیں۔ 65 ایک engineering policy ہے، metric کی property نہیں۔

Published quality anchors context دیتے ہیں۔ تقریباً 50 medium یا fair quality کے آس پاس ہے، جبکہ 70 high یا good quality کے آس پاس۔ اس کا مطلب یہ ہے کہ 60 visually lossless range میں نہیں بلکہ کافی aggressive web-compression range میں ہے۔

اچھے source سے direct conversion میں چھوٹی files کے بدلے میں یہ perceptual budget قبول کرتا ہوں۔ دوسری lossy generation کے لیے میں additional distortion کا budget کم رکھنا چاہتا تھا۔

میں نے 70 پر بھی غور کیا، لیکن اس سے تمام transcoded images بہت سخت quality region میں چلی جاتیں۔ ایسی pages جہاں بہت سی images load ہوتی ہیں، خاص طور پر mobile connections پر، اضافی bytes اہم ہوتے ہیں۔ میرے پاس ثبوت نہیں تھا کہ ہر already-compressed image کو 70 تک لے جانا اس cost کو justify کرتا ہے۔ اس لیے conservative middle ground کے طور پر 65 منتخب کیا۔

65/62 کے بجائے 65/63 کیوں؟

میری original policy 60/58 تھی: ایک representative outlier main target سے دو points نیچے جا سکتا تھا۔ Main target کو 65 کرنے اور وہی policy برقرار رکھنے سے فطری طور پر 65/63 بنتا ہے۔

60 - 58 = 2
65 - 63 = 2

62 استعمال کرنے سے exception تین points کا ہو جاتا۔ Normal samples زیادہ سخت ہوتے لیکن بدترین ایک sample کو زیادہ آزادی ملتی۔ Already lossy input کے لیے خاص طور پر exception بڑھانے کی کوئی technical وجہ مجھے نہیں ملی۔

63 اور 65 میں سے کوئی magic number نہیں۔ اہم چیز policy کی اندرونی consistency ہے۔

2 MB سے 100 KB ہونا visual quality نہیں بتاتا

میں جان بوجھ کر compression ratio سے SSIMULACRA2 threshold نہیں نکالتا۔ 2 MB سے 100 KB تک آنا بہت بڑا فرق لگتا ہے، مگر file size اکیلا perceptual degradation کے بارے میں بہت کم بتاتا ہے۔

Resolution، image entropy، noise، flat areas، line art، chroma subsampling اور previous format سب compression efficiency کو بدلتے ہیں۔ Google](https://developers.google.com/speed/webp/docs/webp_study%22>Google) WebP compression study codecs کو تقریباً matched quality پر compare کرتی ہے، یہ فرض نہیں کرتی کہ ایک جیسی file size کا مطلب ایک جیسی visual quality ہے۔

اسی لیے میں 20× smaller → target 65 جیسے rules استعمال نہیں کرتا۔ میری policy میں اہم یہ ہے کہ current file known lossy derivative ہے یا نہیں، نہ کہ size reduction کتنی impressive ہے۔

اگر original موجود ہو تو میں WebP کو transcode نہیں کرتا

اگر high-quality original اور چھوٹا lossy WebP دونوں موجود ہوں تو میں AVIF براہ راست original سے encode کرتا ہوں اور normal 60/58 policy استعمال کرتا ہوں۔

preferred:
original → AVIF

avoid when possible:
original → lossy WebP → AVIF

Second-generation target کو سخت کرنے سے پہلے encode میں ضائع ہوئی information واپس نہیں آتی۔ 65 صرف AVIF کو WebP کے زیادہ قریب رکھتا ہے؛ 70 اسے اور قریب رکھے گا۔ دونوں میں سے کوئی lost original واپس نہیں بناتا۔

62 اور 63 کی بحث سے زیادہ اہم implementation bug تھا

Policy review کے دوران encoder logic میں زیادہ خطرناک مسئلہ ملا۔ Code میں format-specific target constants اور WebP کے لیے مختلف target دینے والا helper پہلے سے موجود تھا۔ اس لیے WebP کو 60 سے 65 کرنا آسان لگتا تھا۔

لیکن ایسا نہیں تھا۔ Adaptive quality decision اب بھی global target اور global worst-score threshold استعمال کر رہا تھا۔ Format-specific target بعد میں individual results کو pass یا below-target label کرنے کے لیے استعمال ہوتا تھا، مگر final AVIF quality منتخب کرنے والے decision کو لازماً control نہیں کرتا تھا۔

اس سے subtle failure پیدا ہو سکتا ہے: WebP sample صحیح طور پر target 65 سے نیچے label ہو، لیکن adaptive search پھر بھی وہی quality accept کر لے کیونکہ global pass condition اب بھی 60 ہے۔

intended WebP target: 65
actual score:         61.2

format-aware label:  below target
global search rule:  pass if target is still 60

ایسا threshold بے معنی ہے جو encoded output منتخب کرنے والے اصل decision میں شامل ہی نہ ہو۔

Threshold کو sample policy کا حصہ بنانا زیادہ محفوظ ہے

اب میں threshold کو صرف format constant کے بجائے source کی property سمجھنا پسند کرتا ہوں۔ Simplified pseudocode:

if sample is a known lossy derivative:
    target = 65
    floor  = 63
else:
    target = 60
    floor  = 58

reject if any sample is below its floor
allow at most one sample below its target

اہم بات یہ ہے کہ result کو describe کرنے والے thresholds ہی acceptance decision کو بھی control کریں۔

Sampling policy بھی اہم ہے

ہر candidate AVIF quality پر ہر image test کرنا ضروری نہیں۔ Pipeline bytes-per-pixel distribution سے زیادہ سے زیادہ دس representative JPEG، PNG یا WebP samples منتخب کرتا ہے۔

دس یا اس سے کم images والی collection میں ہر sample کو normal target حاصل کرنا چاہیے۔ بڑی collection میں ایک sample lower floor استعمال کر سکتا ہے، جبکہ باقی samples کو main target پاس کرنا ضروری ہے۔

Sampling search کو practical بناتا ہے، لیکن یہی وجہ ہے کہ outlier rule کو غیر ضروری طور پر loose نہیں کرنا چاہیے۔ منتخب samples representative ہیں، یہ proof نہیں کہ ہر unsampled image بالکل ویسا ہی behave کرے گا۔

وہ experiment جو heuristic کی جگہ لے سکتا ہے

سب سے مضبوط جواب کے لیے representative corpus کے true originals محفوظ رکھ کر complete chains test کرنا ہوں گی:

A: original → AVIF, target 60
B: original → lossy WebP → AVIF, target 60
C: original → lossy WebP → AVIF, target 63
D: original → lossy WebP → AVIF, target 65
E: original → lossy WebP → AVIF, target 70

ہر variant کے لیے final byte size، true original کے مقابلے میں SSIMULACRA2، WebP intermediate کے مقابلے میں SSIMULACRA2 اور selected encoder quality record کی جا سکتی ہے۔ مشکل images کو manually inspect کرنا بھی ضروری ہوگا۔

میں نے کافی representative preserved-original set پر یہ controlled experiment نہیں کیا، اس لیے یہ دعویٰ نہیں کر سکتا کہ 65 globally optimal ہے۔ یہ limitation اہم ہے۔

AVIF ہمیشہ ایک اور encode کو justify نہیں کرتا

اگر صرف 100 KB WebP باقی ہے اور 65/63 پاس کرنے والا AVIF 96 KB ہے تو میں conversion پر سوال اٹھاؤں گا۔ صرف 4 KB بچانے کے لیے ایک اور lossy generation اور اضافی processing complexity شاید مناسب نہ ہو۔

لیکن اگر وہی 100 KB WebP quality policy پاس کرتے ہوئے 65 KB AVIF بن جائے تو image-heavy pages پر trade-off کہیں زیادہ دلچسپ ہے۔

Codec conversion کو دو الگ سوالوں کا جواب دینا چاہیے: کیا additional distortion قابل قبول ہے، اور کیا size reduction اتنی بڑی ہے کہ واقعی فرق پڑے؟ پہلا شرط پوری ہونے سے دوسری خودکار طور پر پوری نہیں ہوتی۔

وہ rule جو میں اب استعمال کرتا ہوں

اگر میرے پاس best-quality original ہو تو میں براہ راست اسی سے encode کرتا ہوں اور اس web workload کے لیے 60/58 استعمال کرتا ہوں۔ WebP lossless ہو تو بھی 60/58۔ اگر صرف known lossy derivative باقی ہو تو stricter second-generation budget، فی الحال 65/63، استعمال کرتا ہوں۔ اگر AVIF size بہت کم نہ کرے تو موجودہ WebP برقرار رکھنے پر غور کرتا ہوں۔

اصل سبق یہ نہیں کہ WebP کو کوئی خاص SSIMULACRA2 number چاہیے۔ Full-reference quality metric صرف اسی سوال کا جواب دیتا ہے جس کی نمائندگی اس کی reference image کرتی ہے۔

اگر reference پہلے ہی information کھو چکی ہو تو high score کا مطلب “اس reference کے قریب” ہے، “اس image کے قریب جو پہلے موجود تھی” نہیں۔ جب میں نے image provenance کو compression policy کا حصہ سمجھنا شروع کیا تو thresholds arbitrary codec settings نہیں لگے؛ وہ مختلف generations of loss کے budgets بن گئے۔