ਫਾਰਮੈਟ ਬਾਰੇ ਬਹਿਸ ਆਮ ਤੌਰ ਉੱਤੇ ਕੋਡੈਕ ਤੋਂ ਸ਼ੁਰੂ ਹੋ ਕੇ ਬਾਹਰ ਵੱਲ ਜਾਂਦੀ ਹੈ। ਇਹ ਪੁੱਠਾ ਰਾਹ ਹੈ। ਸਹੀ ਫਾਰਮੈਟ ਦਾ ਫ਼ੈਸਲਾ ਇਸ ਗੱਲ ਤੋਂ ਹੁੰਦਾ ਹੈ ਕਿ ਤਸਵੀਰ ਵਿੱਚ ਹੈ ਕੀ, ਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਇਸ ਤੋਂ ਕਿ ਲੈਣ ਵਾਲਾ ਸਿਸਟਮ ਕੀ ਮੰਨਦਾ ਹੈ।
ਫ਼ੋਟੋਆਂ: JPEG ਜਾਂ WebP
ਲਗਾਤਾਰ ਰੰਗਾਂ ਵਾਲੀਆਂ ਤਸਵੀਰਾਂ — ਚਿਹਰੇ, ਨਜ਼ਾਰੇ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਰੰਗ ਧੀਮੇ-ਧੀਮੇ ਬਦਲਦੇ ਹਨ ਤੇ ਬਾਰੀਕ ਰੌਲਾ ਹੁੰਦਾ ਹੈ — ਨੁਕਸਾਨ ਵਾਲੇ (ਲੌਸੀ) ਕੋਡੈਕਾਂ ਨਾਲ ਚੰਗੀਆਂ ਦਬਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਭਰੇ ਹੋਏ ਹਿੱਸਿਆਂ ਵਿੱਚ ਅੱਖ ਛੋਟੀਆਂ ਗ਼ਲਤੀਆਂ ਜਰ ਲੈਂਦੀ ਹੈ। JPEG ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੈ ਕਿਉਂਕਿ ਇਸਨੂੰ ਹਰ ਕੋਈ ਮੰਨਦਾ ਹੈ। ਲੌਸੀ WebP ਉਹੀ ਦਿਸਦੀ ਗੁਣਵੱਤਾ ਸਾਫ਼ ਤੌਰ ਉੱਤੇ ਘੱਟ ਬਾਈਟਾਂ ਵਿੱਚ ਦਿੰਦਾ ਹੈ, ਸੋ ਜਿੱਥੇ ਵੀ ਮੰਜ਼ਿਲ ਇਸਨੂੰ ਮੰਨਦੀ ਹੋਵੇ, ਬਾਜ਼ੀ ਉਸੇ ਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਸ ਕੰਮ ਲਈ ToolZool ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਇੱਕ ਗੱਲ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ: ਸਾਡਾ ਕੰਪਰੈਸਰ WebP ਸਿਰਫ਼ ਆਪਣੇ ਲੌਸਲੈੱਸ ਢੰਗ ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਜੋ ਫ਼ੋਟੋ ਉੱਤੇ ਉਸ JPEG ਨਾਲੋਂ ਕਈ ਗੁਣਾ ਵੱਡੀ ਫ਼ਾਈਲ ਬਣਾਉਂਦਾ ਹੈ। ਆਕਾਰ ਦੀ ਹੱਦ ਵਾਲੀ ਫ਼ੋਟੋ ਲਈ ਇੱਥੇ JPEG ਚੁਣੋ। ਇਸ ਫ਼ਰਕ ਦਾ ਕਾਰਨ ਕੰਪਰੈਸਰ ਦੇ ਆਪਣੇ ਪੰਨੇ ਉੱਤੇ ਦਿੱਤਾ ਹੈ — ਲੌਸੀ WebP ਦਾ ਕੋਈ ਵੀ ਇਨਕੋਡਰ ਅਜਿਹਾ ਨਹੀਂ ਜਿਸਨੂੰ ਅਸੀਂ ਬਿਨਾਂ ਬੇਮੇਲ ਲਾਇਸੰਸ ਜਾਂ ਬਿਨਾਂ C ਟੂਲਚੇਨ ਦੇ ਭੇਜ ਸਕੀਏ।
ਸਪਾਟ ਗ੍ਰਾਫ਼ਿਕਸ ਤੇ ਲਿਖਤ: PNG
ਲੋਗੋ, ਆਈਕਨ, ਚਿੱਤਰ ਤੇ ਇੰਟਰਫੇਸ ਦੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਤਿੱਖੇ ਕਿਨਾਰਿਆਂ ਤੇ ਇੱਕੋ ਰੰਗ ਦੇ ਵੱਡੇ ਹਿੱਸਿਆਂ ਦੇ ਬਣੇ ਹੁੰਦੇ ਹਨ। ਲੌਸੀ ਕੋਡੈਕ ਤਿੱਖੇ ਕਿਨਾਰੇ ਮਾੜੇ ਸੰਭਾਲਦੇ ਹਨ: ਲਿਖਤ ਦੁਆਲੇ ਦਿਸਦੀ ਧੁੰਦਲੀ ਲਕੀਰ ਪੈ ਜਾਂਦੀ ਹੈ, ਤੇ ਕਿਉਂਕਿ ਉਹ ਜਿਹੜਾ ਰੌਲਾ ਪਾਉਂਦੇ ਹਨ ਉਹ ਆਪ ਹੀ ਇਨਕੋਡ ਕਰਨ ਵਿੱਚ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ, ਫ਼ਾਈਲ ਅਕਸਰ ਉਸੇ ਤਸਵੀਰ ਦੀ ਲੌਸਲੈੱਸ PNG ਨਾਲੋਂ ਵੱਡੀ ਬਣ ਜਾਂਦੀ ਹੈ।
ਪਾਰਦਰਸ਼ਤਾ ਫ਼ੈਸਲਾ ਆਪ ਕਰ ਦਿੰਦੀ ਹੈ
JPEG ਵਿੱਚ ਐਲਫ਼ਾ ਚੈਨਲ ਹੁੰਦਾ ਹੀ ਨਹੀਂ। ਪਾਰਦਰਸ਼ੀ PNG ਨੂੰ JPEG ਬਣਾਓ ਤੇ ਪਾਰਦਰਸ਼ੀ ਹਿੱਸੇ ਭਰ ਜਾਂਦੇ ਹਨ — ਆਮ ਤੌਰ ਉੱਤੇ ਕਾਲੇ, ਕਦੇ ਚਿੱਟੇ, ਤੇ ਬਹੁਤ ਘੱਟ ਉਹ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਸੀ। PNG ਤੇ WebP ਦੋਵੇਂ ਐਲਫ਼ਾ ਸੰਭਾਲਦੇ ਹਨ, ਸੋ ਜੇ ਤਸਵੀਰ ਵਿੱਚ ਪਾਰਦਰਸ਼ਤਾ ਹੈ ਤਾਂ ਸੂਚੀ ਇਨ੍ਹਾਂ ਦੋਵਾਂ ਤੱਕ ਸਿਮਟ ਜਾਂਦੀ ਹੈ।
AVIF ਕਿੱਥੇ ਫਿੱਟ ਬੈਠਦਾ ਹੈ
ਬਰਾਬਰ ਗੁਣਵੱਤਾ ਉੱਤੇ ਫ਼ਾਈਲ ਦੇ ਆਕਾਰ ਵਿੱਚ AVIF, WebP ਨੂੰ ਮਾਤ ਦਿੰਦਾ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਘੱਟ ਬਿੱਟਰੇਟ ਉੱਤੇ, ਤੇ ਅੱਜ ਦਾ ਹਰ ਬ੍ਰਾਊਜ਼ਰ ਇਸਨੂੰ ਦਿਖਾ ਸਕਦਾ ਹੈ। ਸਮੱਸਿਆ ਇਨਕੋਡਿੰਗ ਦੀ ਹੈ: ਇਹ JPEG ਜਾਂ WebP ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਹੌਲੀ ਤੇ ਕਿਤੇ ਵੱਧ ਭਾਰੀ ਹੈ, ਜਿਸਦਾ ਅਸਰ ਉਦੋਂ ਪੈਂਦਾ ਹੈ ਜਦੋਂ ਇਨਕੋਡਿੰਗ ਕਿਸੇ ਬਿਲਡ ਸਰਵਰ ਦੀ ਥਾਂ ਫ਼ੋਨ ਉੱਤੇ ਹੋ ਰਹੀ ਹੋਵੇ।
ToolZool ਅੱਜ ਨਾ AVIF ਪੜ੍ਹਦਾ ਹੈ ਤੇ ਨਾ ਲਿਖਦਾ ਹੈ। ਦੋਵਾਂ ਪਾਸਿਆਂ ਲਈ AV1 ਕੋਡੈਕ ਚਾਹੀਦਾ ਹੈ, ਤੇ ਜਿਹੜੇ ਵੀ ਸਾਂਭੇ ਜਾ ਰਹੇ ਹਨ ਉਹ ਸਾਰੇ C ਲਾਇਬ੍ਰੇਰੀਆਂ ਹਨ ਜੋ WebAssembly ਲਈ ਬਿਲਡ ਨਹੀਂ ਹੁੰਦੀਆਂ — ਸੋ AVIF ਫ਼ਾਈਲ ਨੂੰ ਪਹਿਲਾਂ ਕਿਤੇ ਹੋਰ ਬਦਲਣਾ ਪਵੇਗਾ। ਇਹੀ ਗੱਲ HEIC ਉੱਤੇ ਵੀ ਲਾਗੂ ਹੈ, ਜੋ ਬਹੁਤੇ iPhone ਮੂਲ ਰੂਪ ਵਿੱਚ ਬਣਾਉਂਦੇ ਹਨ।
ਉਹ ਸਵਾਲ ਜੋ ਬਾਕੀ ਸਭ ਉੱਤੇ ਭਾਰੂ ਹੈ
ਫਾਰਮ ਮੰਨਦਾ ਕੀ ਹੈ? ਜਿਹੜਾ ਬਿਹਤਰ ਫਾਰਮੈਟ ਠੁਕਰਾ ਦਿੱਤਾ ਜਾਵੇ, ਉਹ ਬਿਹਤਰ ਨਹੀਂ ਹੁੰਦਾ। ਪਹਿਲਾਂ ਮੰਨੇ ਜਾਣ ਵਾਲੇ ਫਾਰਮੈਟਾਂ ਦੀ ਸੂਚੀ ਪੜ੍ਹੋ, ਫੇਰ ਉਸੇ ਦੇ ਅੰਦਰ ਰਹਿ ਕੇ ਸੁਧਾਰ ਕਰੋ — ਤੇ ਜੇ ਕੋਈ ਫ਼ਾਈਲ ਪੂਰੀ ਉਤਰਦੀ ਲੱਗਣ ਦੇ ਬਾਵਜੂਦ ਵੀ ਨਾ ਮੰਨੀ ਜਾਵੇ, ਤਾਂ ਅੱਪਲੋਡ ਫਾਰਮ ਤੁਹਾਡੀ ਫ਼ਾਈਲ ਕਿਉਂ ਠੁਕਰਾਉਂਦਾ ਹੈ ਉਨ੍ਹਾਂ ਚਾਰ ਜਾਂਚਾਂ ਵਿੱਚੋਂ ਲੰਘਾਉਂਦਾ ਹੈ ਜੋ ਫਾਰਮ ਅਸਲ ਵਿੱਚ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਫਾਰਮੈਟਾਂ ਵਿਚਕਾਰ ਆਉਣਾ-ਜਾਣਾ ਹੈ ਤਾਂ ਤਸਵੀਰ ਕੰਪਰੈਸਰ JPG, PNG ਤੇ WebP ਪੜ੍ਹਦਾ ਹੈ ਤੇ JPEG, PNG ਜਾਂ ਲੌਸਲੈੱਸ WebP ਲਿਖਦਾ ਹੈ, ਸੋ ਇਸੇ ਦਾਇਰੇ ਵਿੱਚ ਉਹ ਕਨਵਰਟਰ ਦਾ ਕੰਮ ਵੀ ਦਿੰਦਾ ਹੈ।
