ਸਟੈਗਨੋਗ੍ਰਾਫੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਾਰਡ ਡਰਾਈਵ ਸਪੇਸ ਬਚਾਓ

ਜਦੋਂ ਅਸੀਂ ਸਟੈਗਨੋਗ੍ਰਾਫੀ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਲੋਕ ਅੱਤਵਾਦੀਆਂ, ਪੀਡੋਫਾਈਲਾਂ, ਜਾਸੂਸਾਂ, ਜਾਂ, ਸਭ ਤੋਂ ਵਧੀਆ, ਕ੍ਰਿਪਟੋ-ਅਨਾਰਕਵਾਦੀ ਅਤੇ ਹੋਰ ਵਿਗਿਆਨੀਆਂ ਬਾਰੇ ਸੋਚਦੇ ਹਨ। ਅਤੇ ਅਸਲ ਵਿੱਚ, ਹੋਰ ਕਿਸ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਓਹਲੇ ਬਾਹਰੀ ਅੱਖਾਂ ਤੋਂ ਕੁਝ? ਇਸ ਦਾ ਇੱਕ ਆਮ ਆਦਮੀ ਨੂੰ ਕੀ ਫਾਇਦਾ ਹੋ ਸਕਦਾ ਹੈ?

ਇਹ ਇੱਕ ਹੈ ਬਾਹਰ ਕਾਮੁਕ. ਇਸ ਲਈ ਅੱਜ ਅਸੀਂ ਸਟੈਗਨੋਗ੍ਰਾਫੀ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡੇਟਾ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਾਂਗੇ। ਅਤੇ ਅੰਤ ਵਿੱਚ, ਪਾਠਕ ਫਾਈਲ ਸਿਸਟਮ ਤੇ ਮੁਫਤ ਗੀਗਾਬਾਈਟ ਦੀ ਸੰਖਿਆ ਨੂੰ ਵਧਾਉਣ ਲਈ JPEGs ਵਿੱਚ ਆਪਣੇ ਕੀਮਤੀ ਫੋਟੋ ਪੁਰਾਲੇਖਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਯੋਗ ਵੀ ਹੋਵੇਗਾ.

ਕੀ?

ਜੇ ਪਾਠਕ ਨੂੰ ਯਾਦ ਹੈ, ਸਟੈਗਨੋਗ੍ਰਾਫੀ ਅਜਿਹੇ ਅਜੀਬ ਐਲਗੋਰਿਦਮ ਹਨ ਜੋ ਇੱਕ ਜਾਣਕਾਰੀ ਦੀ ਮੌਜੂਦਗੀ ਨੂੰ ਦੂਜੇ ਅੰਦਰ ਲੁਕਾਉਣਾ ਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ। ਹੋਰ ਵੀ ਸਰਲ ਭਾਸ਼ਾ ਵਿੱਚ: ਤਸਵੀਰ + ਫਾਈਲ == ਲਗਭਗ ਇੱਕੋ ਤਸਵੀਰ, ਪਰ ਬਿਲਕੁਲ ਨਹੀਂ (ਤਸਵੀਰਾਂ ਦੀ ਬਜਾਏ ਕੁਝ ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਵਿੱਚ ਸਭ ਕੁਝ ਸਪੱਸ਼ਟ ਹੁੰਦਾ ਹੈ)। ਇਹ ਪਤਾ ਲਗਾਉਣ ਦਾ ਕੋਈ ਆਸਾਨ ਤਰੀਕਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਕਿ ਅੰਦਰ ਕੁਝ ਹੈ ਜਾਂ ਨਹੀਂ।

ਪਰ ਜੇ ਇੱਕ ਨੂੰ ਦੂਜੇ ਤੋਂ ਵੱਖਰਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਤਾਂ ਕੀ ਕੋਈ ਅੰਤਰ ਹੈ? ਉਪਭੋਗਤਾ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਉਪਭੋਗਤਾ ਗਣਿਤਿਕ ਸ਼ੁੱਧਤਾ (ਬਿੱਟਾਂ ਦੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸਮੂਹ ਦੁਆਰਾ ਪ੍ਰਤੀਬਿੰਬਿਤ) ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦਾ, ਸਿਰਫ ਉਹੀ ਜੋ ਉਸ ਦੁਆਰਾ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਆਓ ਇੱਕ ਪਿਆਰੇ ਕੁੱਤੇ ਦੀਆਂ ਤਿੰਨ ਤਸਵੀਰਾਂ ਦੇਖੀਏ:

ਸਾਵਧਾਨ, JPEG!

ਆਕਾਰ ਵਿਚ ਵੱਡੇ ਅੰਤਰ ਦੇ ਬਾਵਜੂਦ, ਕੁਝ ਲੋਕ ਤੀਜੇ ਸੰਸਕਰਣ ਦੀ ਚੋਣ ਕਰਨਗੇ. ਦੂਜੇ ਪਾਸੇ, ਪਹਿਲੀਆਂ ਦੋ ਤਸਵੀਰਾਂ ਵਿਚਲਾ ਅੰਤਰ ਇੰਨਾ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਵਿਚ ਜਾਣਕਾਰੀ ਦੀ ਮਾਤਰਾ (ਮੇਰੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ) ਬਰਾਬਰ ਹੋ ਸਕਦੀ ਹੈ.

ਇਹ ਸਿਧਾਂਤ ਪਹਿਲਾਂ ਹੀ ਪੁਰਾਣਾ ਹੈ ਅਤੇ ਕਈ ਸਾਲਾਂ ਤੋਂ ਨੁਕਸਾਨਦੇਹ ਜਾਣਕਾਰੀ ਸੰਕੁਚਨ ਵਿਧੀਆਂ ਦੁਆਰਾ ਸਰਗਰਮੀ ਨਾਲ ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਗਿਆ ਹੈ. ਪਰ ਤੋੜਨਾ ਬਿਲਡਿੰਗ ਨਹੀਂ ਹੈ; ਅਸੀਂ ਮੁੱਦੇ ਦੇ ਵਧੇਰੇ ਉੱਨਤ ਪੱਖ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਾਂ. ਕੀ ਵਾਧੂ ਆਕਾਰ ਦੀ ਜਾਣਕਾਰੀ ਨੂੰ ਏਮਬੈਡ ਕਰਨਾ ਸੰਭਵ ਹੈ N ਫਾਈਲ ਵਿੱਚ ਤਾਂ ਜੋ ਇਸਦਾ ਆਕਾਰ ਵੱਧ ਜਾਵੇ M < N, ਪਰ ਤਬਦੀਲੀਆਂ ਉਪਭੋਗਤਾ ਲਈ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਸਨ?

ਬੇਸ਼ੱਕ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਇਹ ਤੁਰੰਤ ਕੁਝ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਰਨ ਦੇ ਯੋਗ ਹੈ:

• ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਵਿਧੀ ਯੂਨੀਵਰਸਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਇਨਪੁਟ ਡੇਟਾ 'ਤੇ ਸਕਾਰਾਤਮਕ ਨਤੀਜਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਭਾਵ, ਔਸਤਨ, ਇੱਕ ਬੇਤਰਤੀਬ ਇਨਪੁਟ ਲਈ, ਸਟੋਰ ਕੀਤੀ ਜਾਣਕਾਰੀ ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਕਮੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। "ਔਸਤਨ" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਲਟ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਪ੍ਰਮੁੱਖ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
• ਦੂਜਾ, ਜਾਣਕਾਰੀ ਨੂੰ ਏਮਬੈਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੰਕੁਚਿਤ ਕੰਟੇਨਰ ਦਾ ਆਕਾਰ ਇਸ ਦੇ ਸੰਕੁਚਿਤ ਰੂਪ ਵਿੱਚ ਸੰਕੁਚਿਤ ਕੀਤੇ ਗਏ ਸੰਸ਼ੋਧਨ ਨਾਲੋਂ ਵੱਡਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਸ LSB ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ BMP ਚਿੱਤਰਾਂ ਵਿੱਚ ਬਿੱਟਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਨੂੰ ਜੋੜਨਾ ਸਟੈਗਨੋਗ੍ਰਾਫਿਕ ਕੰਪਰੈਸ਼ਨ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ, ਕਿਸੇ ਕਿਸਮ ਦੇ DEFLATE ਦੁਆਰਾ ਚਲਾਏ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਅਸਲ ਚਿੱਤਰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਛੋਟਾ ਹੋਵੇਗਾ।
• ਤੀਜਾ, ਨਤੀਜਾ ਕਲਾਸੀਕਲ ਤਰੀਕਿਆਂ ਦੁਆਰਾ ਪਹਿਲਾਂ ਹੀ ਸੰਕੁਚਿਤ ਡੇਟਾ ਦੇ ਸਬੰਧ ਵਿੱਚ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਤੁਲਨਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਉਹਨਾਂ ਦੀ ਰਿਡੰਡੈਂਸੀ ਵਿੱਚ ਅੰਤਰ ਦੇ ਸੰਭਾਵੀ ਪ੍ਰਭਾਵ ਨੂੰ ਹਟਾ ਦੇਵੇਗਾ ਅਤੇ ਆਮ ਕੇਸ ਵਿੱਚ ਵਧੇਰੇ ਕੁਸ਼ਲ ਕੰਪਰੈਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰੇਗਾ।

ਕਿੱਥੇ

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

ਇਸ ਸੰਦਰਭ ਵਿੱਚ, ਗ੍ਰਾਫਿਕਸ, ਆਡੀਓ ਅਤੇ ਵੀਡੀਓ ਫਾਈਲਾਂ ਚੰਗੇ ਉਮੀਦਵਾਰ ਹਨ। ਪਰ, ਵੱਖ-ਵੱਖ ਫਾਰਮੈਟਾਂ, ਕੋਡੇਕਸ, ਆਦਿ ਦੇ ਕਾਰਨ, ਅਭਿਆਸ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿਕਲਪ ਨਹੀਂ ਬਚਿਆ ਹੈ।

ਇਸ ਸਭ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਮੇਰੀ ਪਸੰਦ JPEG 'ਤੇ ਡਿੱਗ ਗਈ ਲਗਭਗ ਹਰ ਕਿਸੇ ਕੋਲ ਇਹ ਹੈ, ਇਹ ਵਿਅਕਤੀਗਤ ਅਤੇ ਵਪਾਰਕ ਉਦੇਸ਼ਾਂ ਲਈ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜ਼ਿਆਦਾਤਰ ਚਿੱਤਰਾਂ ਲਈ ਲਗਭਗ ਡੀ ਫੈਕਟੋ ਫਾਰਮੈਟ ਹੈ।

ਇਹ ਨਿਰਭਰ ਕਰਦਾ ਹੈ?

ਅੱਗੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਆਖਿਆ ਤੋਂ ਬਿਨਾਂ ਨੇੜੇ- ਅਤੇ ਤਕਨੀਕੀ ਚਿੱਤਰ ਅਤੇ ਵਰਣਨ ਹਨ, ਇਸਲਈ ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲੇ "ਉੱਚ ਤਕਨਾਲੋਜੀ" ਭਾਗ 'ਤੇ ਸਕ੍ਰੋਲ ਕਰਕੇ ਉਹਨਾਂ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹਨ।

ਆਮ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਕਿਤੇ ਡਾਟਾ ਏਮਬੇਡ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿੱਥੇ। ਫਾਈਲ ਸਿਸਟਮ 'ਤੇ ਵੱਖ-ਵੱਖ ਫੋਟੋਆਂ ਦੀ ਗਿਣਤੀ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਸ ਵਿੱਚੋਂ ਉਪਭੋਗਤਾ ਸਿਰਫ਼ ਕੁਝ ਹੀ ਵਰਤਣਾ ਚਾਹ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਕੰਟੇਨਰਾਂ ਦੇ ਅਜਿਹੇ ਲੋੜੀਂਦੇ ਸਮੂਹ ਨੂੰ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਕਹਾਂਗੇ।

ਇਹ ਦੋ ਮਾਮਲਿਆਂ ਵਿੱਚ ਬਣਦਾ ਹੈ: ਕੰਪਰੈਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਡੀਕੰਪ੍ਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ। ਪਹਿਲੇ ਕੇਸ ਵਿੱਚ, ਤੁਸੀਂ ਸਿਰਫ਼ ਫਾਈਲਾਂ ਦੇ ਨਾਮਾਂ ਦੇ ਇੱਕ ਸਮੂਹ (ਜਾਂ ਬਿਹਤਰ ਅਜੇ ਤੱਕ, ਉਹਨਾਂ ਲਈ ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ) ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਦੂਜੇ ਵਿੱਚ, ਕੁਝ ਹੋਰ ਭਰੋਸੇਮੰਦ ਲੋੜੀਂਦਾ ਹੈ: ਉਪਭੋਗਤਾ ਉਹਨਾਂ ਨੂੰ ਫਾਈਲ ਸਿਸਟਮ ਵਿੱਚ ਕਾਪੀ ਅਤੇ ਮੂਵ ਕਰ ਸਕਦਾ ਹੈ। , ਇਸ ਤਰ੍ਹਾਂ ਉਹਨਾਂ ਦੀ ਸਹੀ ਪਛਾਣ ਹੋਣ ਤੋਂ ਰੋਕਦੀ ਹੈ। ਇਸ ਲਈ, ਸਾਰੀਆਂ ਸੋਧਾਂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਉਹਨਾਂ ਦੇ ਹੈਸ਼ਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ (md5 ਕਾਫ਼ੀ ਹੈ)।

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

ਇਹ ਸਭ ਕਿਸੇ ਵੀ ਸਟੈਗਨੋਗ੍ਰਾਫਿਕ ਡੇਟਾ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ ਦੇ ਕਿਸੇ ਵੀ ਲਾਗੂਕਰਨ 'ਤੇ ਬਰਾਬਰ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਡੇਟਾ ਕੰਪਰੈਸ਼ਨ ਅਤੇ ਰਿਕਵਰੀ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਪੈਕਿੰਗ ਅਤੇ ਅਨਪੈਕਿੰਗ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ।

F5

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

ਇਸ ਨੂੰ ਦੇਖਦੇ ਹੋਏ, ਤੁਰੰਤ ਕੁਝ ਟਿੱਪਣੀਆਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ:

• ਜੇਪੀਈਜੀ ਫਾਈਲ ਦੇ ਆਕਾਰ ਨੂੰ ਕਿਸੇ ਕਿਸਮ ਦੇ ਵਿਨਰਾਰ ਨਾਲ ਸੰਕੁਚਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੇ ਬਿਨਾਂ ਵੀ ਅਨੁਕੂਲ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ;
• ਸਿਰਫ ਸਟੋਰ ਕੀਤੀ ਜਾਣਕਾਰੀ (ਜੋ ਕਿ ਡਿਸਕ੍ਰਿਟ ਕੋਸਾਈਨ ਟ੍ਰਾਂਸਫਾਰਮ, ਡੀਸੀਟੀ ਤੋਂ ਆਉਟਪੁੱਟ ਹੈ) ਨੂੰ ਘੱਟੋ-ਘੱਟ ਸਵੀਕਾਰਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਸੋਧਿਆ ਜਾ ਸਕਦਾ ਹੈ।
• ਉਪਭੋਗਤਾ ਲਈ ਧਿਆਨ ਦੇਣ ਯੋਗ ਉਦਯੋਗਿਕ ਪੈਮਾਨੇ 'ਤੇ ਡੇਟਾ ਨੂੰ ਨਾ ਗੁਆਉਣ ਲਈ, ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਚਿੱਤਰ ਵਿੱਚ ਘੱਟੋ ਘੱਟ ਸੋਧਾਂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ;

ਐਲਗੋਰਿਦਮ ਦਾ ਇੱਕ ਪੂਰਾ ਪਰਿਵਾਰ ਇਹਨਾਂ ਸ਼ਰਤਾਂ ਨੂੰ ਫਿੱਟ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਜਾਣੂ ਕਰ ਸਕਦੇ ਹੋ ਇਸ ਵਧੀਆ ਪੇਸ਼ਕਾਰੀ ਵਿੱਚ. ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਉੱਨਤ ਐਲਗੋਰਿਦਮ ਹੈ F5 ਐਂਡਰੀਅਸ ਵੈਸਟਫੀਲਡ ਦੁਆਰਾ, ਚਮਕ ਕੰਪੋਨੈਂਟ ਦੇ ਡੀਸੀਟੀ ਗੁਣਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋਏ (ਮਨੁੱਖੀ ਅੱਖ ਇਸ ਦੀਆਂ ਤਬਦੀਲੀਆਂ ਪ੍ਰਤੀ ਘੱਟ ਤੋਂ ਘੱਟ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੀ ਹੈ)। ਇੱਕ ਮੌਜੂਦਾ JPEG ਫਾਈਲ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਇਸਦਾ ਆਮ ਖਾਕਾ ਹੇਠਾਂ ਪ੍ਰਦਰਸ਼ਿਤ ਹੁੰਦਾ ਹੈ:

F5 ਬਲਾਕ ਮੈਟ੍ਰਿਕਸ ਏਨਕੋਡਿੰਗ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਉੱਨਤ ਏਮਬੈਡਿੰਗ ਤਕਨੀਕ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਪਾਠਕ ਉੱਪਰ ਦਿੱਤੇ ਲਿੰਕ 'ਤੇ ਇਸ ਬਾਰੇ ਅਤੇ ਖੁਦ ਐਲਗੋਰਿਦਮ ਬਾਰੇ ਹੋਰ ਜਾਣ ਸਕਦਾ ਹੈ, ਪਰ ਅਸੀਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਸ ਤੱਥ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਾਂ ਕਿ ਇਸਦੀ ਮਦਦ ਨਾਲ ਤੁਸੀਂ ਜਾਣਕਾਰੀ ਦੀ ਸਮਾਨ ਮਾਤਰਾ ਨੂੰ ਏਮਬੈਡ ਕਰਦੇ ਸਮੇਂ ਘੱਟ ਬਦਲਾਅ ਕਰ ਸਕਦੇ ਹੋ, ਵਰਤੇ ਗਏ ਕੰਟੇਨਰ ਦਾ ਆਕਾਰ ਜਿੰਨਾ ਵੱਡਾ ਹੋਵੇਗਾ। , ਅਤੇ ਐਲਗੋਰਿਦਮ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਸਿਰਫ ਸਧਾਰਨ ਹਫਮੈਨ ਅਤੇ RLE (de)ਕੋਡਿੰਗ ਓਪਰੇਸ਼ਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

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

ਜ਼ੀਰੋ (ਅਖੌਤੀ ਕਟੌਤੀ) ਦੇ ਗਠਨ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਸਟੋਰ ਕੀਤੀ ਜਾਣਕਾਰੀ ਦੀ ਗਿਣਤੀ ਇਸਦੇ ਆਕਾਰ ਦੁਆਰਾ ਘਟਾਈ ਜਾਵੇਗੀ, ਕਿਉਂਕਿ ਸਾਬਕਾ ਸੁਤੰਤਰ ਗੁਣਾਂਕ ਜ਼ੀਰੋ ਦੇ RLE ਏਨਕੋਡ ਕ੍ਰਮ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਵੇਗਾ:

ਸੋਧਾਂ

ਡਾਟਾ ਸੁਰੱਖਿਆ ਅਤੇ ਕੰਪਰੈਸ਼ਨ ਔਰਥੋਗੋਨਲ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਇਸਲਈ ਮੂਲ ਐਲਗੋਰਿਦਮ ਤੋਂ ਗੁਪਤ ਪਾਸਵਰਡ ਅਨੁਰੂਪਤਾ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਐਕਸਟਰੈਕਟ ਕਰਨਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਲਈ ਲੋੜੀਂਦੀ ਸਾਰੀ ਜਾਣਕਾਰੀ (ਕਿਸ ਕੰਟੇਨਰ ਵਰਤੇ ਗਏ ਸਨ, ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ, ਆਦਿ) ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਫਾਈਲ ਵਿੱਚ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਆਰਚੀਵਰ ਦੁਆਰਾ ਮੁਫਤ ਪੜ੍ਹਨ ਲਈ ਖੁੱਲ੍ਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਕਿਉਂਕਿ ਅਸਲ F5 ਕੰਟੇਨਰ ਦੇ ਆਕਾਰ ਦੇ 12% ਤੱਕ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਇਹ ਸੋਧ ਅਧਿਕਤਮ ਸਮਰੱਥਾ ਨੂੰ ਵੀ ਵਧਾਏਗੀ: ਪੂਰੀ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਆਕਾਰ ਦਾ "12% ਤੱਕ" "12% ਤੱਕ" ਦੇ ਜੋੜ ਤੋਂ ਵੱਧ ਜਾਂ ਬਰਾਬਰ ਹੈ। "ਇਸਦੇ ਹਰੇਕ ਤੱਤ ਤੋਂ।

ਕੋਡਿਡ ਜਨਰਲ ਸਕੀਮ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ:

ਐਲਗੋਰਿਦਮ ਖੁਦ

ਹੁਣ ਸਮਾਂ ਆ ਗਿਆ ਹੈ ਕਿ ਐਲਗੋਰਿਦਮ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਵਰਣਨ ਕਰੋ, ਤਾਂ ਜੋ ਪਾਠਕ ਨੂੰ ਹਨੇਰੇ ਵਿੱਚ ਨਾ ਰੱਖਿਆ ਜਾ ਸਕੇ:

• ਉਪਭੋਗਤਾ ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ ਅਤੇ ਇੱਕ ਖੋਜ ਰੂਟ ਡਾਇਰੈਕਟਰੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਾਈਨਰੀ ਸੰਕੁਚਿਤ ਡੇਟਾ M ਅਤੇ ਲਾਇਬ੍ਰੇਰੀ L ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ;
• ਜਿਸ ਕ੍ਰਮ ਵਿੱਚ ਉਹ FS 'ਤੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਤੱਤ MC ਬਣਾਉਂਦੇ ਹਨ:
  • ਗੁਣਾਂਕ C ਦੀ ਇੱਕ ਲੜੀ ਫਾਈਲ ਡੇਟਾ ਤੋਂ ਡੀਕੋਡ ਕੀਤੀ ਜਾਂਦੀ ਹੈ;
  • MC <- MC | ਸੀ;
• ਪੈਰਾਮੀਟਰ k ਨੂੰ ਭਿਆਨਕ ਅਸਮਾਨਤਾ ਦੇ ਅਧਾਰ ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: |M| * 8 / (count_full(MC) + count_ones(MC) * k_rate(k)) < k / ((1 << k) - 1);
• ਅੱਗੇ ਲਿਆ ਗਿਆ n = (1 << k) - 1 MC ਤੋਂ ਗੈਰ-ਜ਼ੀਰੋ ਤੱਤਾਂ ਦੇ ਘੱਟੋ-ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਬਿੱਟ ਅਤੇ ਇਸ ਨੂੰ ਲਿਖਿਆ ਗਿਆ a:
  • ਮੈਜਿਕ ਹੈਸ਼ ਫੰਕਸ਼ਨ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ f, ਇੱਕ n-ਬਿੱਟ ਸ਼ਬਦ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ a ਕੇ-ਬਿੱਟ ਤੱਕ s;
  • ਜੇ s == 0, ਫਿਰ ਕੁਝ ਵੀ ਬਦਲਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ ਅਤੇ ਐਲਗੋਰਿਦਮ ਅਗਲੇ ਗੁਣਾਂਕ ਵੱਲ ਵਧਦਾ ਹੈ;
  • ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਗੁਣਾਂਕ ਦੇ ਸੰਪੂਰਨ ਮੁੱਲ ਨੂੰ ਘਟਾਓ s-ਹੇ ਸ਼ਬਦ ਵਿੱਚ ਬਿੱਟ a;
  • ਜੇਕਰ ਕਟੌਤੀ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਕਮੀ ਆਉਂਦੀ ਹੈ (ਗੁਣਾਕ 0 ਬਣ ਜਾਂਦਾ ਹੈ), ਤਾਂ ਸ਼ੁਰੂ ਤੋਂ ਪੜਾਅ ਨੂੰ ਦੁਹਰਾਓ;
• ਸਾਰੇ ਗੁਣਾਂਕ RLE ਅਤੇ Huffman ਦੁਆਰਾ ਏਨਕੋਡ ਕੀਤੇ ਗਏ ਹਨ, ਸਰੋਤ ਫਾਈਲਾਂ ਨੂੰ ਲਿਖੇ ਗਏ ਹਨ;
• ਪੈਰਾਮੀਟਰ k ਨੂੰ ਆਰਕਾਈਵ ਫਾਈਲ ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ;
• ਇੱਕ MD5 ਹੈਸ਼ ਦੀ ਗਣਨਾ ਹਰੇਕ ਫਾਈਲ L ਤੋਂ ਉਹਨਾਂ ਦੇ ਅਸਲ ਸਥਾਨ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਆਰਕਾਈਵ ਫਾਈਲ ਵਿੱਚ ਲਿਖੀ ਜਾਂਦੀ ਹੈ।

ਉੱਚ ਤਕਨੀਕ

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

ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ libjpeg, pcre ਅਤੇ tinydir ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਸੁਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਲਈ ਅਸੀਂ ਉਹਨਾਂ ਦਾ ਧੰਨਵਾਦ ਕਰਦੇ ਹਾਂ। ਮੂਲ ਰੂਪ ਵਿੱਚ, ਸਭ ਕੁਝ ਆਮ ਦੁਆਰਾ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ make, ਇਸ ਲਈ ਉਪਭੋਗਤਾ Windows ਉਹ ਕੁਝ ਸਾਈਗਵਿਨ ਸਥਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ ਜਾਂ ਵਿਜ਼ੂਅਲ ਸਟੂਡੀਓ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਆਪਣੇ ਆਪ ਲੱਭਣਾ ਚਾਹੁੰਦੇ ਹਨ।

ਲਾਗੂ ਕਰਨਾ ਇੱਕ ਕੰਸੋਲ ਉਪਯੋਗਤਾ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਰੂਪ ਵਿੱਚ ਉਪਲਬਧ ਹੈ। ਉਹ ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲੇ Github 'ਤੇ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਰੀਡਮੀ ਵਿੱਚ ਬਾਅਦ ਵਾਲੇ ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਹੋਰ ਜਾਣ ਸਕਦੇ ਹਨ, ਜਿਸਦਾ ਲਿੰਕ ਮੈਂ ਪੋਸਟ ਦੇ ਅੰਤ ਵਿੱਚ ਨੱਥੀ ਕਰਾਂਗਾ। ਅਤੇ ਇੱਥੇ ਅਸੀਂ ਕੰਮ ਦੇ ਵਰਣਨ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵੱਲ ਵਧਦੇ ਹਾਂ.

ਕਿਸ ਨੂੰ ਵਰਤਣ ਲਈ?

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

ਮੰਨ ਲਓ ਕਿ ਕੰਪਾਇਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਸਾਨੂੰ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲ f5ar ਮਿਲਦੀ ਹੈ। ਤੁਸੀਂ ਫਲੈਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਦੀ ਵਰਤੋਂ ਦੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਆਕਾਰ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦੇ ਹੋ -a: ./f5ar -a [папка поиска] [Perl-совместимое регулярное выражение]. ਟੀਮ ਵੱਲੋਂ ਪੈਕੇਜਿੰਗ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ./f5ar -p [папка поиска] [Perl-совместимое регулярное выражение] [упаковываемый файл] [имя архива], ਅਤੇ ਵਰਤ ਕੇ ਅਨਪੈਕਿੰਗ ./f5ar -u [файл архива] [имя восстановленного файла].

ਕੰਮ ਦਾ ਪ੍ਰਦਰਸ਼ਨ

ਵਿਧੀ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਦਿਖਾਉਣ ਲਈ, ਮੈਂ ਸੇਵਾ ਤੋਂ ਕੁੱਤਿਆਂ ਦੀਆਂ 225 ਬਿਲਕੁਲ ਮੁਫਤ ਫੋਟੋਆਂ ਦਾ ਸੰਗ੍ਰਹਿ ਅਪਲੋਡ ਕੀਤਾ Unsplash. ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵਿੱਚ ਆਮ ਉਪਭੋਗਤਾ ਫੋਟੋਆਂ ਨਾਲੋਂ ਥੋੜ੍ਹਾ ਉੱਚ ਗੁਣਵੱਤਾ ਹੈ, ਪਰ ਫਿਰ ਵੀ. ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਨੂੰ libjpeg ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮੁੜ-ਏਨਕੋਡ ਕੀਤਾ ਗਿਆ ਸੀ ਤਾਂ ਜੋ ਸਮੁੱਚੇ ਆਕਾਰ 'ਤੇ ਲਾਇਬ੍ਰੇਰੀ ਦੀਆਂ ਏਨਕੋਡਿੰਗ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਬੇਅਸਰ ਕੀਤਾ ਜਾ ਸਕੇ। ਸੰਕੁਚਿਤ ਡੇਟਾ ਦੀ ਸਭ ਤੋਂ ਭੈੜੀ ਉਦਾਹਰਣ ਨੂੰ ਦਰਸਾਉਣ ਲਈ, ਇੱਕ ਬੇਤਰਤੀਬ 36-ਮੀਟਰ (ਕੁੱਲ ਆਕਾਰ ਦੇ 5% ਤੋਂ ਥੋੜ੍ਹਾ ਵੱਧ) dd ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕਸਾਰ ਵੰਡੀ ਗਈ ਫਾਈਲ ਤਿਆਰ ਕੀਤੀ ਗਈ ਸੀ।

ਟੈਸਟਿੰਗ ਪ੍ਰਕਿਰਿਆ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੈ:

$ ls
binary_data dogs f5ar
$ du -sh dogs/
633M dogs/
$ du -h binary_data
36M binary_data

$ ./f5ar -p dogs/ .*jpg binary_data dogs.f5ar
Reading compressing file... ok
Initializing the archive... ok
Analysing library capacity... done in 16.8s
Detected somewhat guaranteed capacity of 48439359 bytes
Detected possible capacity of upto 102618787 bytes
Compressing... done in 32.6s
Saving the archive... ok

$ ./f5ar -u dogs/dogs.f5ar unpacked
Initializing the archive... ok
Reading the archive file... ok
Filling the archive with files... done in 1.2s
Decompressing... done in 17.5s
Writing extracted data... ok

$ sha1sum binary_data unpacked
ba7ade4bc77881ab463121e77bbd4d41ee181ae9 binary_data
ba7ade4bc77881ab463121e77bbd4d41ee181ae9 unpacked
$ du -sh dogs/
563M dogs/

ਜਾਂ ਪ੍ਰਸ਼ੰਸਕਾਂ ਲਈ ਇੱਕ ਸਕ੍ਰੀਨਸ਼ੌਟ

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਹਾਰਡ ਡਰਾਈਵ 'ਤੇ ਮੂਲ 633 + 36 == 669 ਮੈਗਾਬਾਈਟ ਡੇਟਾ ਤੋਂ, ਅਸੀਂ ਇੱਕ ਵਧੀਆ 563 ਦੇ ਨਾਲ ਸਮਾਪਤ ਹੋਏ, ਸਾਨੂੰ ~ 1,188 ਦਾ ਸੰਕੁਚਨ ਅਨੁਪਾਤ ਦਿੰਦੇ ਹੋਏ। ਇਸ ਮੂਲ ਅੰਤਰ ਨੂੰ ਬਹੁਤ ਹੀ ਛੋਟੇ ਨੁਕਸਾਨਾਂ ਦੁਆਰਾ ਸਮਝਾਇਆ ਗਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਕਲਾਸੀਕਲ ਤਰੀਕਿਆਂ (ਜਿਵੇਂ ਕਿ tinyjpg) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ JPEG ਫਾਈਲਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਵੇਲੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਸਟੈਗਨੋਗ੍ਰਾਫਿਕ ਕੰਪਰੈਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਜਾਣਕਾਰੀ ਸਿਰਫ਼ "ਗੁੰਮ" ਨਹੀਂ ਹੁੰਦੀ, ਪਰ ਦੂਜੇ ਡੇਟਾ ਨੂੰ ਏਨਕੋਡ ਕਰਨ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, F5 ਦੀ ਵਰਤੋਂ ਦੇ ਕਾਰਨ "ਅਨੁਕੂਲਿਤ" ਗੁਣਾਂ ਦੀ ਗਿਣਤੀ ਰਵਾਇਤੀ ਅਨੁਕੂਲਨ ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਹੈ।

ਜੋ ਵੀ ਸੋਧਾਂ ਹਨ, ਉਹ ਅੱਖਾਂ ਲਈ ਬਿਲਕੁਲ ਅਦਿੱਖ ਹਨ. ਹੇਠਾਂ ਵਿਗਾੜਨ ਵਾਲੇ ਦੇ ਅਧੀਨ, ਪਾਠਕ ਅੱਖ ਦੁਆਰਾ ਅਤੇ ਬਦਲੇ ਹੋਏ ਹਿੱਸੇ ਦੇ ਮੁੱਲਾਂ ਨੂੰ ਮੂਲ ਤੋਂ ਘਟਾ ਕੇ ਅੰਤਰ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦਾ ਹੈ (ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਮਿਊਟ ਰੰਗ, ਅੰਤਰ ਛੋਟਾ ਹੋਵੇਗਾ):

ਚਿੱਤਰਾਂ ਦੇ ਲਿੰਕ ਜੋ ਹੈਬਰਾਸਟੋਰੇਜ 'ਤੇ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ

ਮੂਲ - https://i.ibb.co/wNDLNcZ/1.jpg
ਸੋਧਿਆ - https://i.ibb.co/qWvpfFM/1.jpg
ਅੰਤਰ - https://i.ibb.co/2ZzhHfD/diff.jpg

ਸੰਪੂਰਨ ਹੋਣ ਦੇ ਬਜਾਏ

ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਮੈਂ ਪਾਠਕ ਨੂੰ ਯਕੀਨ ਦਿਵਾਉਣ ਦੇ ਯੋਗ ਸੀ ਕਿ ਅਜਿਹੇ ਤਰੀਕੇ ਸੰਭਵ ਹਨ ਅਤੇ ਜੀਵਨ ਦਾ ਅਧਿਕਾਰ ਹੈ. ਹਾਲਾਂਕਿ, ਇੱਕ ਹਾਰਡ ਡਰਾਈਵ ਜਾਂ ਇੱਕ ਵਾਧੂ ਚੈਨਲ (ਨੈੱਟਵਰਕ ਪ੍ਰਸਾਰਣ ਲਈ) ਖਰੀਦਣਾ ਇਸ ਤਰੀਕੇ ਨਾਲ ਪੈਸੇ ਬਚਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲੋਂ ਬਹੁਤ ਸੌਖਾ ਵਿਕਲਪ ਜਾਪਦਾ ਹੈ। ਇੱਕ ਪਾਸੇ, ਇਹ ਸੱਚ ਹੈ; ਵਿਆਪਕ ਵਿਕਾਸ ਅਕਸਰ ਸਰਲ ਅਤੇ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਹੁੰਦਾ ਹੈ। ਪਰ ਦੂਜੇ ਪਾਸੇ, ਸਾਨੂੰ ਤੀਬਰ ਬਾਰੇ ਨਹੀਂ ਭੁੱਲਣਾ ਚਾਹੀਦਾ. ਆਖ਼ਰਕਾਰ, ਇਸ ਗੱਲ ਦੀ ਕੋਈ ਗਾਰੰਟੀ ਨਹੀਂ ਹੈ ਕਿ ਕੱਲ੍ਹ ਤੁਸੀਂ ਸਟੋਰ 'ਤੇ ਆਉਣ ਦੇ ਯੋਗ ਹੋਵੋਗੇ ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਹੋਰ ਹਜ਼ਾਰ ਟੈਰਾਬਾਈਟ ਹਾਰਡ ਡਰਾਈਵ ਖਰੀਦ ਸਕੋਗੇ, ਪਰ ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਘਰ ਵਿੱਚ ਪਏ ਹੋ।

-> GitHub

ਸਰੋਤ: www.habr.com