ਜਦੋਂ ਬ੍ਰਾਊਜ਼ਰ ਤਸਵੀਰ ਛੋਟੀ ਕਰਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ

ਦਬਾਈ ਹੋਈ ਫ਼ਾਈਲ ਨੂੰ ਵਾਪਸ ਪਿਕਸਲਾਂ ਦੇ ਜਾਲ ਵਿੱਚ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਇਹ ਕੰਮ ਨੇਟਿਵ ਕੋਡ ਵਿੱਚ ਕਰਦੇ ਹਨ, ਤੇ ਜਿੱਥੇ ਪਲੇਟਫਾਰਮ ਦਿੰਦਾ ਹੋਵੇ ਉੱਥੇ ਹਾਰਡਵੇਅਰ ਦੀ ਮਦਦ ਨਾਲ; ਇਹ JPEG, PNG, WebP ਤੇ AVIF ਸੰਭਾਲਦੇ ਹਨ — ਤੇ Apple ਦੇ ਪਲੇਟਫਾਰਮਾਂ ਉੱਤੇ HEIC ਵੀ, ਕਿਉਂਕਿ ਉਹ ਡੀਕੋਡਰ ਪਹਿਲਾਂ ਹੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨਾਲ ਆਉਂਦਾ ਹੈ।

ਫ਼ਾਈਲ ਦੇ ਲਿਹਾਜ਼ ਨਾਲ ਡੀਕੋਡਿੰਗ ਵਿੱਚ ਕੋਈ ਨੁਕਸਾਨ ਨਹੀਂ ਹੁੰਦਾ: ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਉਹੀ ਪਿਕਸਲ ਮਿਲਦੇ ਹਨ ਜੋ ਫ਼ਾਈਲ ਦੱਸਦੀ ਹੈ। ਨੁਕਸਾਨ ਤਾਂ ਪਹਿਲਾਂ ਹੀ ਹੋ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ, ਉਦੋਂ ਜਦੋਂ ਜਿਸ ਕਿਸੇ ਨੇ ਉਹ ਫ਼ਾਈਲ ਬਣਾਈ ਸੀ, ਉਸਨੇ ਇਸਨੂੰ ਇਨਕੋਡ ਕੀਤਾ ਸੀ।

ਫ਼ੋਨ ਦੇ ਕੈਮਰੇ ਸੈਂਸਰ ਦੀ ਸਿੱਧੀ ਦਿਸ਼ਾ ਸਾਂਭਦੇ ਹਨ ਤੇ ਨਾਲ ਇੱਕ ਵੱਖਰਾ EXIF ਟੈਗ ਵੀ, ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਕਿੰਨਾ ਘੁਮਾਉਣਾ ਹੈ। ਜਿਹੜਾ ਸਾਫ਼ਟਵੇਅਰ ਉਸ ਟੈਗ ਨੂੰ ਅਣਗੌਲਿਆ ਕਰਦਾ ਹੈ, ਉਹ ਫ਼ੋਟੋਆਂ ਪਾਸੇ ਪਈਆਂ ਦਿਖਾਉਂਦਾ ਹੈ। ਟੈਗ ਲਾਗੂ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬਾਕੀ ਕਿਸੇ ਵੀ ਕੰਮ ਤੋਂ ਪਹਿਲਾਂ ਪਿਕਸਲਾਂ ਦਾ ਅਸਲ ਜਾਲ ਹੀ ਘੁਮਾ ਦਿੱਤਾ ਜਾਵੇ — ਜਿਸ ਤੋਂ ਬਾਅਦ ਉਸ ਟੈਗ ਦੀ ਲੋੜ ਹੀ ਨਹੀਂ ਰਹਿੰਦੀ, ਤੇ ਇਹੀ ਇੱਕ ਕਾਰਨ ਹੈ ਕਿ ਦੁਬਾਰਾ ਇਨਕੋਡ ਕਰਨ ਨਾਲ ਮੈਟਾਡਾਟਾ ਲਹਿ ਜਾਂਦਾ ਹੈ।

ਜੇ ਟੀਚੇ ਵਾਲਾ ਆਕਾਰ ਪੂਰੇ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਉੱਤੇ ਨਾ ਪੁੱਗੇ, ਤਾਂ ਤਸਵੀਰ ਛੋਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਦਿਸਦੀ ਗੁਣਵੱਤਾ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਚੁੱਪ-ਚਾਪ ਇੱਥੇ ਹੀ ਜਿੱਤਿਆ ਜਾਂ ਹਾਰਿਆ ਜਾਂਦਾ ਹੈ। ਸਸਤਾ ਬਾਕਸ ਫ਼ਿਲਟਰ ਨਾਲ ਦੇ ਪਿਕਸਲਾਂ ਦੀ ਔਸਤ ਕੱਢ ਕੇ ਸਭ ਕੁਝ ਨਰਮ ਕਰ ਦਿੰਦਾ ਹੈ; Lanczos ਫ਼ਿਲਟਰ ਵੱਧ ਦੂਰ ਤੱਕ ਦੇ ਪਿਕਸਲਾਂ ਨੂੰ ਤੋਲਦਾ ਹੈ ਤੇ ਕਿਨਾਰੇ ਤਿੱਖੇ ਰੱਖਦਾ ਹੈ।

ਰੀਸੈਂਪਲਿੰਗ ਸੱਚਮੁੱਚ ਨੁਕਸਾਨਦਾਇਕ ਹੈ — ਸੁੱਟੇ ਹੋਏ ਪਿਕਸਲ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦੇ — ਪਰ ਛੋਟੇ ਟੀਚੇ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਇਹ ਅਕਸਰ ਸਭ ਤੋਂ ਘੱਟ ਨੁਕਸਾਨਦਾਇਕ ਰਾਹ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਉਹ ਬਾਰੀਕੀ ਹਟਾ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਬਿਆਨ ਕਰਨ ਦੀ ਨਾਕਾਮ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਇਨਕੋਡਰ ਨੇ ਆਪਣਾ ਸਾਰਾ ਬਜਟ ਲਾ ਦੇਣਾ ਸੀ।

ਇਹੀ ਨੁਕਸਾਨ ਵਾਲਾ ਹਿੱਸਾ ਹੈ। JPEG ਤਸਵੀਰ ਨੂੰ ਚਮਕ-ਜਮ੍ਹਾਂ-ਰੰਗ ਵਾਲੇ ਰੂਪ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਰੰਗ ਦਾ ਕੁਝ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਸੁੱਟ ਦਿੰਦਾ ਹੈ (ਅੱਖ ਨੂੰ ਮਸਾਂ ਹੀ ਪਤਾ ਲੱਗਦਾ ਹੈ), ਤਸਵੀਰ ਨੂੰ 8×8 ਦੇ ਬਲਾਕਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ, ਹਰ ਬਲਾਕ ਨੂੰ ਫ੍ਰੀਕੁਐਂਸੀ ਦੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਤੇ ਫੇਰ ਕੁਆਂਟਾਈਜ਼ ਕਰਦਾ ਹੈ — ਭਾਵ ਉੱਚੀ ਫ੍ਰੀਕੁਐਂਸੀ ਵਾਲੀ ਬਾਰੀਕੀ ਨੂੰ ਗੋਲ ਕਰਕੇ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਗੁਣਵੱਤਾ ਵਾਲਾ ਪੈਰਾਮੀਟਰ ਇਸੇ ਗੋਲਾਈ ਦਾ ਮੋਟਾਪਣ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਦਾ ਸਭ ਕੁਝ ਬਿਨਾਂ ਨੁਕਸਾਨ ਵਾਲੀ ਐਂਟਰੌਪੀ ਕੋਡਿੰਗ ਹੈ, ਤੇ ਇਸੇ ਲਈ ਸੁਧਾਰੀ ਹੋਈ Huffman ਟੇਬਲ ਜਾਂ ਪ੍ਰੋਗਰੈਸਿਵ ਸਕੈਨ ਬਾਈਟ ਮੁਫ਼ਤ ਵਿੱਚ ਬਚਾ ਦਿੰਦੇ ਹਨ।

ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਆਪਣਾ ਇਨਕੋਡਰ ਬੰਦ ਡੱਬਾ ਹੈ: ਤੁਸੀਂ ਗੁਣਵੱਤਾ ਦਾ ਇੱਕ ਅੰਕ ਮੰਗ ਸਕਦੇ ਹੋ, ਬੱਸ। ਨਾ ਸੁਧਾਰੀਆਂ ਐਂਟਰੌਪੀ ਟੇਬਲਾਂ, ਨਾ ਬੇਸਲਾਈਨ ਜਾਂ ਪ੍ਰੋਗਰੈਸਿਵ ਦੀ ਚੋਣ, ਨਾ ਰੀਸੈਂਪਲਿੰਗ ਫ਼ਿਲਟਰ ਉੱਤੇ ਕੋਈ ਵੱਸ, ਤੇ ਨਾ ਹੀ ਬਿਨਾਂ ਅਜ਼ਮਾਏ ਇਹ ਜਾਣਨ ਦਾ ਕੋਈ ਰਾਹ ਕਿ ਕਿਸੇ ਸੈਟਿੰਗ ਤੋਂ ਕਿੰਨੇ ਬਾਈਟ ਬਣਨਗੇ।

WebAssembly ਵਿੱਚ ਕੰਪਾਈਲ ਕੀਤਾ ਕੋਡੈਕ ਇਹ ਸਭ ਵਾਪਸ ਦਿੰਦਾ ਹੈ, ਬਦਲੇ ਵਿੱਚ ਉਸਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਦੇ ਬਾਈਟ ਲੈਂਦਾ ਹੈ। ToolZool ਪੂਰੀ ਲੜੀ ਇਸੇ ਤਰ੍ਹਾਂ ਚਲਾਉਂਦਾ ਹੈ — ਡੀਕੋਡ, ਦਿਸ਼ਾ, ਰੀਸੈਂਪਲ ਤੇ ਇਨਕੋਡ, ਸਾਰੇ Rust ਵਿੱਚ ਲਿਖ ਕੇ WebAssembly ਵਿੱਚ ਕੰਪਾਈਲ ਕੀਤੇ, ਤੇ ਪਿੱਛੇ ਚੱਲਦੇ ਇੱਕ ਵਰਕਰ ਵਿੱਚ — ਨਾ ਕਿ ਡੀਕੋਡ ਦਾ ਕੰਮ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਸੌਂਪ ਕੇ। ਇਸਦੇ ਤਿੰਨ ਕਾਰਨ ਹਨ, ਤੇ ਤਿੰਨੇ ਅਮਲੀ:

• ਖੋਜ ਲਈ ਕਈ ਇਨਕੋਡ ਚਾਹੀਦੇ ਹਨ। ਪੱਕੇ ਆਕਾਰ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਉਸੇ ਤਸਵੀਰ ਨੂੰ ਪੰਜ-ਛੇ ਵਾਰ ਇਨਕੋਡ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇਨਕੋਡਰ ਆਪਣਾ ਹੋਵੇ ਤਾਂ ਹੀ ਇਹ ਸਸਤਾ ਤੇ ਭਰੋਸੇਯੋਗ ਰਹਿੰਦਾ ਹੈ।
• ਡੀਕੋਡਰ ਨੂੰ ਨਾਂਹ ਕਹਿਣੀ ਵੀ ਆਉਣੀ ਚਾਹੀਦੀ ਹੈ। ਜਿਹੜੀ ਫ਼ਾਈਲ 60,000 × 60,000 ਪਿਕਸਲ ਦਾ ਦਾਅਵਾ ਕਰਦੀ ਹੈ, ਉਸਨੂੰ ਮੈਮਰੀ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਠੁਕਰਾਉਣਾ ਪੈਂਦਾ ਹੈ, ਤੇ ਅਧੂਰੀ ਫ਼ਾਈਲ ਨੂੰ ਅੱਧੀ ਤਸਵੀਰ ਦੇਣ ਦੀ ਥਾਂ ਫ਼ੇਲ੍ਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਡੀਕੋਡਰ ਇਹ ਫ਼ੈਸਲੇ ਆਪ ਕਰਦਾ ਹੈ; ਸਾਡਾ ਹੱਦਾਂ ਸਾਫ਼ ਦੱਸਦਾ ਵੀ ਹੈ ਤੇ ਲਾਗੂ ਵੀ ਕਰਦਾ ਹੈ।
• ਇੱਕੋ ਇਨਪੁੱਟ ਤੋਂ ਹਰ ਵਾਰ ਇੱਕੋ ਨਤੀਜਾ ਬਣਨਾ ਚਾਹੀਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰਾਂ ਦੇ ਡੀਕੋਡਰ ਰੰਗ ਸੰਭਾਲਣ ਵਿੱਚ ਤੇ ਖ਼ਰਾਬ ਫ਼ਾਈਲਾਂ ਨਾਲ ਸਲੂਕ ਵਿੱਚ ਵੱਖਰੇ ਹਨ। ਜਿਹੜੀ ਲੜੀ ਦੋਵੇਂ ਸਿਰੇ ਆਪ ਸੰਭਾਲਦੀ ਹੈ, ਉਹ ਹਰ ਡਿਵਾਈਸ ਉੱਤੇ ਉਹੀ ਬਾਈਟ ਬਣਾਉਂਦੀ ਹੈ — ਤੇ ਇਹੀ ਗੱਲ ਨਤੀਜੇ ਨੂੰ ਜਾਂਚਣ ਜੋਗਾ ਬਣਾਉਂਦੀ ਹੈ।

ਕੀਮਤ ਵੀ ਸਾਫ਼ ਦੱਸ ਦੇਈਏ: ਉਹ ਇੰਜਣ ਇੱਕ ਡਾਊਨਲੋਡ ਹੈ। ਇਹ ਉਦੋਂ ਹੀ ਲਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਫ਼ਾਈਲ ਚੁਣਦੇ ਹੋ, ਸੋ ਇਸ ਵਰਗਾ ਪੰਨਾ ਪੜ੍ਹਨ ਦੀ ਕੀਮਤ ਵਿੱਚ ਉਹ ਕਦੇ ਨਹੀਂ ਆਉਂਦਾ।

ਫ਼ਾਈਲ ਦਾ ਟੀਚਾ ਆਕਾਰ ਤੈਅ ਹੋਵੇ, ਤਾਂ ਚੰਗੇ ਇਨਕੋਡਰ ਤੇ ਬਹੁਤ ਵਧੀਆ ਇਨਕੋਡਰ ਵਿਚਲਾ ਫ਼ਰਕ ਕੁਝ ਫ਼ੀਸਦੀ ਦਾ ਹੁੰਦਾ ਹੈ। ਗੁਣਵੱਤਾ ਵਾਲੇ ਸਲਾਈਡਰ ਬਾਰੇ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਤੇ ਸਹੀ ਪੱਧਰ ਲੱਭਣ ਵਿਚਲਾ ਫ਼ਰਕ ਕਿਤੇ ਵੱਡਾ ਹੈ, ਕਿਉਂਕਿ ਜਿਹੜਾ ਅੰਦਾਜ਼ਾ ਤੁਹਾਡੀ ਹੱਦ ਦੇ 60% ਉੱਤੇ ਜਾ ਕੇ ਰੁਕਦਾ ਹੈ, ਉਸਨੇ ਤੁਹਾਡੇ ਹੱਕ ਦੀ ਇੱਕ ਤਿਹਾਈ ਗੁਣਵੱਤਾ ਸੁੱਟ ਦਿੱਤੀ। ਇਹੀ ਸਾਰਾ ਖ਼ਿਆਲ ਪੱਕੇ ਆਕਾਰ ਤੱਕ ਤਸਵੀਰ ਛੋਟੀ ਕਰਨ ਪਿੱਛੇ ਹੈ, ਤੇ 50 KB ਦੀ ਹੱਦ ਤੱਕ ਪਹੁੰਚਣਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸਭ ਤੋਂ ਔਖੇ ਸਿਰੇ ਉੱਤੇ ਇਹ ਖੋਜ ਤੁਹਾਨੂੰ ਦਿੰਦੀ ਕੀ ਹੈ।