بريمج: صانع الصور .. نسق جديد للصور

السلام عليكم ..

كيفك اخوي الشمري .. و الله الك وحشة ..

جاي التحميل .. و لنا عودة

لم أحمّل بعد.

لكن خطوتك هذه أسعدتني..

لقد قمت بالفعل بإنتاج نوع ملفات خاص بك...

لكن (أنا طمّاع) لكن يجب أن تكون خطوتك القادمة هي البحث عن خوارزمية لتصغير عدد البايتات في الملف، ما قمت به هو ما يفعله bmp لكن مع بعض الفروق. عليك أن تطور فكرتك الرائعة ليصبح الملف "شيء جديد" ويدفع الآخرين لدعمه..

أعرف أن فكرتي هذه رغم سهولة طرحي لها صعبة جدّاً .. لكن لو نجحت في ضغط الملف بخوارزمية - غير المستخدمة الان في jpg فسيتحوّل موضوعك من موضوع على منتدى الى محط أنظار كل المهتمين..

تحياتي..

وخطوة رائعة في الاتجاه الصحيح.

مشكور يالاخير زمانه على المرور ,,, ننتظر رايك ,,

اقتباس

فسيتحوّل موضوعك من موضوع على منتدى الى محط أنظار كل المهتمين..

هذه صعبة شوي :rolleyes:

لكن فعلا هذا فكرت فيه .. كيف من الممكن ان اقلل من حجم الملف ..

لو على الاقل 10% من حجمه .. لا اريد ضغط كبير ..

هل يوجد من يعرف !!!! او لديه فكرة .

فكرة جيدة .. خصوصا للتعلم و الممارسة.

يمكنك اختصار حجم الملف عن طريق تخزين الأرقام بشكل binary و ليس نصي.

اذا خزنت الأرقام على شكل حروف فإن كل رقم سياخذ 3 بايتات, او ربما 4 بايتات اذا حسبنا المسافة ايضا.

بينما اذا خزنت الارقام بشكل ثنائي فكل رقم سياخذ بايت واحد.

يعني اختصار اكثر من 10% :)

اضافة الى ما قاله الأخ hasan_aljudy استخدم خواريزمية ضغط مثل LZW

شرح الخواريزمية + Sourceهنـــا

السلام عليكم و رحمة الله ..

بصراحة الفكرة جملية .. ولا اروع ..

بس الحجم هو المشكلة الوحيدة ..

يعني اخونا الشمري انت سهلت الخزن على حساب الحجم ..

اقتباس

لكن فعلا هذا فكرت فيه .. كيف من الممكن ان اقلل من حجم الملف ..

بقية انواع الصور تعتمد على خوارزميات معينة لكبس الصورة .. اعتقد ال PCX اسهل انواع الكبس واظن مبدأ عملها على تشابه الالوان وتقاربها يعني مثلا لو كانت لدينا قيم الوان هكذا 1 .2 .3 .4 .5 .. فيتم خزنها بأختيار قيمة وسطية مثلا 2 اختصارا مما يقلل جودتها (هذا الكلام ليس دقيق بالمئة لكن فقط للتوضيح) ولهذا تكون ال BMP افضل وادق الانواع لأنها لا تحوي على كبس ..

اما الخوارزمية المذكورة .. فأذا ما خانتي الذاكرة .. هي مستخدمة في JPG (كتبتها صح ؟؟ :rolleyes: ) و التي تتميز بأقوى انواع الكبس ..(اضنها تمر بثلاث مراحل )

المهم ...

موضوعك اخي الشمري وفكرتك دفعتني للتالي ..

لما لا نطور (او بالأصح نبتكر ;) ) طريقة في كبس الصور ..

بصراحة الموضوع عجبني .. وفعلا بدأت ابحث عن المراجع في Image Processing لأقرء عن الخوارزميات المستخدمة في الكبس على وعسى نسوي شي ..

يعني الملخص .. اريد اقول ان الحجم اهم من السهولة .. وفعلا يشكل تحدي كبير اذا ما اردنا ان نبدأ ..

وش رأيكم ؟؟

اخيرا ..

مجهود رائع اخي الشمري .. وزادك الله من علمه ونفع الله بك الامة ..

و بأنتظار ردك ..

و السلام عليكم

عندي رد جاهز بالنسبة لاقتراح الاخ حسن ..

بالفعل كتابة الملف بطريقة binary خفضت حجم الملف الناتج .. بنسبة 8% تقريبا :) ....

سأقرأ بقية الردود ... على مهل ...

بالنسبة لخوارزمية LZW مافهمتها زين .. ايضا مالفائدة من تكرار نفس الخوارزمية .

اقتباس

بقية انواع الصور تعتمد على خوارزميات معينة لكبس الصورة .. اعتقد ال PCX اسهل انواع الكبس واظن مبدأ عملها على تشابه الالوان وتقاربها يعني مثلا لو كانت لدينا قيم الوان هكذا 1 .2 .3 .4 .5 .. فيتم خزنها بأختيار قيمة وسطية مثلا 2 اختصارا مما يقلل جودتها (هذا الكلام ليس دقيق بالمئة لكن فقط للتوضيح) ولهذا تكون ال BMP افضل وادق الانواع لأنها لا تحوي على كبس ..

بالفعل .. فكرة ممتازة .

اي بشكل عام نختصر الالوان المتشابهة ..

فبدلا من كتابة

255 255 100

255 255 100

255 255 100

255 255 100

255 255 100

ممكن نكتب في الملف

r 5

255 255 100

يعني ان اللون السابق مكرر خمس مرات ...

لكن كيف نكتشف ان اللون مكرر .

ايضا لو نستطيع نطور طريقة لمعرفة ان اللون x يقارب جدا للون y ..

وبالتالي نقلل الحجم على حساب الدقة.. ولن يكون ذلك مؤثرا

ولكن كل ذلك يحتاج لتفكير فقط

عندي فكرة ثانية ..

لنفرض عندنا صورتين نفس الشكل تماما ..

الاولى ابعادها 200* 200 بكسل

الثانية 150* 150 بكسل

اكيد اننا سنلاحظ ان حجم الاولى اكبر من حجم الثانية .. بالرغم من أن الشكل العام متشابه

اذا

الحل اللي في بالي .

نفتح اي صورة .

نقلل من ابعادها قليلا .

نحفظ الصورة + نكتب في اعلى الملف رقم يبين نسبة التصغير التي حدثت .

عندما نقرأ الصورة .. نقرأها + نضيف اليها نسبة التصغير لترجع الى حجمها الطبيعي .

اذا نحن قللنا من حجم ملف الصورة .

بعد قليل سأضع التطبيق ,,,, ان شاءالله

اعتقد ان lzw تنفع فقط في النصوص الطويلة .. لانه عادة هناك مقاطع كثيرة تتكرر في الكتابة, خصوصا الانكليزية.

بالنسبة لضغط الصور .. اعتقد ان افضل شي متوفر هو نمط png و لكن لا اعرف ما هي الخوارزمية المستخدمة. اعتقد يمكن ايجادها بسهولة عند البحث في جووجل.

( .. بعد قليل من البحث ... )

يا ساتر ..

PNG Specification:

http://www.w3.org/TR/PNG

اعتقد تحتاج طولة بال :)

اقدم لكم أغبى خوارزمية ظهرت على وجه الارض .,,

الفكرة التي كنت اريد الوصول لها .

تحميل الصورة ....

تصغير مساحتها الى النصف .

حفظها على هيئة AT2

بالفعل طبقت هذه الطريقة وبدلا من ان يكون الحجم الناتج 1700 كيلو بايت صار 436 كيلو بايت.

وهذا شيء طبيعي لان مساحة الصورة قلت .

لكن كنت اريد ان اقرأ الصورة .. ثم اكبرها مرة اخرى بضرب الطول والعرض * 2 ..

بالتالي ترجع الصورة بنفس حجمها السابق ولكن مع قليل من التشويه .

بالتالي اكون قد استطعت ان اقلل من حجم الصورة الى اكثر من 25% ..

لكن الطريقة غبية جدا ..

هاه أحد عنده حل اخر .. :D

-----------

يا اخوان ...مالفائدة من تقليد الخوارزمية الاخرى .. ممكن نستفيد من بعض الافكار الموجودة فيها وليس ان نطبقها بحذافيرها ,,, وش استفدنا !!!

image_creator_3.rar

اقتباس

النسبة لخوارزمية LZW مافهمتها زين .. ايضا مالفائدة من تكرار نفس الخوارزمية .

خواريزمية سهلة و بسيطة بالمقارنة مع غيرها

وهي مستخدمة في GIF

لا عيب في استخدامها مع بنية جديدة New File Format

اقتباس

اعتقد ان افضل شي متوفر هو نمط png و لكن لا اعرف ما هي الخوارزمية المستخدمة

PNG تستخدم نفي خواريزمية ZIP المسمات deflate

ولعلمك خواريزمية LZW كانت الأكثر شعبية في ضغط الصور لكن بسبب حقوق Unisys في الخواريزمية ومطالبة المبرمجين لدفح حقوق استعمال الخواريزمية في GIF اتجه المطورون لانشاء Format جديد هو PNG مستخدمين خواريزمية Deflate التي كانت حرة و متاحة بدون مقابل

تجد اليوم جميع مطوري Open Source يدعمون PNG لذلك ايبب

شيئ أخير: حقوق Unisys في GIF و خواريزمية LZW توقفت منذ 2004

ويمكن استخدامها الأن

السلام عليكم ..

البحث عن طريقة جديدة لكبس الصورة ليس بالأمر السهل .. و خاصة اذا لم نرد تكرار و الاعتماد على خوارزمية سابقة ..

وعليه اولا يجب قراءة الخوارزميات والطرق المستخدمة في الكبس والتعمق في هذا الموضوع ..

يعني برنامج اخونا الشمري فتح لنا ابواب جديدة ..

انا بدأت بخطوات عملية في هذا الموضوع وبدأت اقرء في انواع الصور وطريقة كبسها ..

مثلا PCX تعتمد طريقة Run – Length Compression

و التي هي كما ذكر اخونا الشمري ..

اقتباس

اي بشكل عام نختصر الالوان المتشابهة ..

فبدلا من كتابة

255 255 100

255 255 100

255 255 100

255 255 100

255 255 100

ممكن نكتب في الملف

r 5

يعني لو كانت لدينا القيمة 5 تتكرر بمقدار 20 مرة ، تخزن هكذا

20 5

أي سيكون

count value

لكن عند فتح الصورة كيف نميز بين ال count و value ؟؟

ملفات pcx تستخدم 6 بت فقط من كل بايت أي سيكون لدينا البت السابع والثامن فارغين .. يتم استخدام هذين البتين للتميز ..

ام GIF فأنها تستخدم طريقة LZW لضغط البيانات (للعلم هناك براءة اختراع لهذا البرنامج ….. احنا شبلانا -_- )

كما وهناك طرق في الضغط تسمى بالطرق الفاقدة (أي تفقد بعض تفاصيل الصورة او بعض البيانات ويسمى هذا الضغط بالضغط الفاقد Lossy Compression) يعني مثلا عندك ال JPEG التي تمر عملية ضغط البيانات فيها بثلاث مراحل (لسه الان اقرء فيها .. معقدة وفيها شوية رياضيات )

المهم هذه الطرق وغيرها تم ابتكارها منذ زمن و لا ادري هل من الممكن ان نستطيع ان نبتكر طريقة نحن .. ام هذا من ضرب الخيال ..

و الله يا أخوان انا انام واستيقظ على حلم وكلمة انه ان الاوان لأمة محمد ان تقدم وفي جميع المجالات .. فكفانا ما دهانا ..

(يمكن شوية طلعت على الموضوع ..)

ساضيف هنا كل جديد اتوصل اليه في هذا المجال ..

اخي الشمري ..

انا للأن لم اطلع على كود برنامجك .. ان شاء الله اليوم .. واذا في سؤال راح ارجعلك وارجو ان يتسع صدرك لي ..

بس شي عالماشي بالنسبة للبرنامج ..

هل البرنامج يفتح جميع انواع الصور ويحولها الى صيغتك ام فقط BMP ؟؟

و السلام عليكم

انا استخدمت المكتبة DevIL في المثال الاخير ,, يعني تفتح جميع انواع الصور ,,

تعليق بالنسبة لطريقة الشمري في الضغط!!

إياك أن تفعلها :)

إذا صغرت حجم الصورة للنصف، ستضيع الكثير من البيكسلات وبيناتها بشكل عشوائي، عند اعادة التكبير لن ترجع القسم الضائعة، وهذا هو أكبر تحدي في فلسفة الضغط، استرجاع قيَم دون تخزينها.. كل الخوارزميات تدور في هذا المنوال فمثلا خوارزمية Run – Length Compression المذكورة اعلاه تسترجع القيم دون تخزينها وذلك بأنها تخزن عدد التكرار فمثلا لو أن القسمة الاولى مكررة مائة مرة فإنه سيتم حفظ أول قيمة مع عدد 100 كعداد.. أي أننا حفظنا قيمتين بدل أن نحفظ 100 قيمة إي أننا سنسترجع 98 قيمة دون ان نخزنها!

هذه هي كل التعقيدات تأتي أنت :) وتحدمها بأنك ستحتفظ بجذر القيم (يعني مش النصف بل الجذر) وتسترجع القيم عشوائياً لو أن هذا ممكن لما احتجنا لتلك الخوارزميات المعقدة! :)

حقيقة موضوع رائع مما دفعني للمشاركة معكم في هذا المنتدى :^)

حالياً اقوم بتحميل الملفات لأطلع على العمل ولكن خطرت ببالي فكرة ربما قد تكون مفيدة في عملية الضغط

وهو ان يتم تقسيم الملف الى جزئين Head و Body

ال Head سيحتوي على القيم الاساسية للألوان ( R G B )

وال Body سيحتوي على عنوان اللون الموجود في ال Head حسب المكان (id)

سأوضح الفكره بمثال

من المثال الذي ذكره الأخ الشمري سابقاً

اقتباس

396

401

255 255 255

255 255 255

255 255 255

229 229 247

229 229 247

229 229 247

0 0 0

229 229 247

بأستخدام الطريقة التي ذكرتها يكون الملف كالتالي :

396   -------> Height Picture
401   -------> Width Picture
9	  --------> Size Of Head 
----------------------- Start Head ----------------------
255 255 255
229 229 247
0 0 0
----------------------- End Head ------------------------
----------------------- Start Body -----------------------
1
1
1
2
2
2
3
2
--------------------- End Body --------------------------

هذا مجرد شكل توضيحي للملف

طبعاً لو حسبنا حجم الملفين بأتعتبارهم Byte وليست محارف ( سيتم اهمال المسافات والاسطر )

فالملف الأول ( الغير مضغوط ) : 28 Byte

والملف الثاني ( المضغوط ) : 22 Byte

لي عودة إن شاء الله ولعلها تكون بمثال حي :D

تحياتي surini

بسم الله الرحمن الرحيم

اتمنى الموضوع ده يكون مفيد

http://en.wikipedia.org/wiki/Image_compression

بعدما قمت بالأطلاع على البرنامج والكود الذي قام بتطويرة الأخ المبدع الشمري

احببت ان اضيف الفكرة السابقة لكني للاسف لم اكن امتلك VC++

قمت بإعادة كتابة الفكرة من جديد بأستخدام الدلفي Delphi

ووضعت اللاحقة للملف المضغوط هي at3

والملف العادي at2

مااريد ان اقوله هو اني حصلت على نتائج مذهلة بعد عمل البرنامج

فسألخص لكم تجربتي البسيطة على ثلاث انواع من الصور

الصورة الأولى والتي كانت مرفقة ضمن ملفات الاخ الشمري

كان حجم الصورة : 10 KB

وذات الابعاد : 100 * 100

قمت بحفظها على النسق at2

واصبحت بحجم : 29.3 KB

اما at3 فالحجم اصبح : 9.94 KB

الصورة الثاني : كانت تحمل عبارة نصية قمت بكتابتها بلون واحد

وهذه التجربة هي ماتخضع لفكرة الضغط المستخدمه بحيث

كلما وجد التماثل اللوني قل حجم الصورة

كان حجم الصورة : 117 KB

وذات ابعاد : 200 * 200

بإستخدام النسق at2 اصبح الحجم : 118 KB

اما at3 فكان الحجم : 39 KB

الصورة الثالثة : كانت صورة طبيعية تحمل تعددية الوان

كان الغرض من التجربة هو معرفة هل at3 سيعمل مع هذه النوعية ام لا

طبعاً الاجابة كانت لا :D

لإن هناك محدودية في عمل at3 او في الفكرة بشكل خاص

بحيث انه لاتقبل لتكرار اكثر من 255 لون في الصورة

هناك بعض الحلول ولكن ستزيد من سعة الملف

المهم

كان حجم الصورة : 268 KB

قم بحفظها على النسق at2 فأصبح الحجم : 267 KB ;)

البرنامج + Source Code موجودة في المرفقات باسم ATP.rar

اما ملفات التجربة فهي بأسم test.rar

تحياتي surini

ATP.rar

test.rar

فعلا الصورة 100*100 بكسل ..صارت اصغر مع at3 .

رائع .. لكن اذا فهمت بالظبط طريقتك التي استخدمتها ... .. بالفعل .. بعض انساق الصور .. تعتمد على تخزين الالوان كقائمة وكل قائمة لها ID .. وهذا مطبق في بعض الصور والله اعلم .

----

لكن أنا ما عندي الدلفي .. فااريد أن اعرف الطريقة التي انت استخدمتها في تخزين الالوان ..

يعني لو تعطينا الخطوات .. ككلام فقط . . .

--

ولكن انا لم استطع فتح بعض الصور ( بالرغم من انها bmp ) واذا فتحت معي .. واردت حفظها يقول انه لا يدعم هذا النوع من الصور .. واحيانا يهنق البرنامج ..

هل جربت وفتحت اكثر من صورة من نوع bmp لانه تظهر مشاكل عندي .

اقتباس

ولكن انا لم استطع فتح بعض الصور ( بالرغم من انها bmp ) واذا فتحت معي .. واردت حفظها يقول انه لا يدعم هذا النوع من الصور ..

نسيت ان اذكر نقطة مهمة وهي اني وضعت حدود لعمل البرنامج لكي لايحدث اخطاء في العمل

فمثلاً البرنامج لن يفتح الصور التي تزيد مقاساتها عن 1275 * 1275

ولن يفتح الملفات التي تزيد احجامها عن 10 MB

ولن يقوم بحفظ الصور على لاحقة at3 اذا زادت التكرارات اللونية عن 256 و .......

بل ستظهر لك رسالة مفادها " Do not Supported "

السبب في ذلك عدة عوامل منها ان طريقتي في بناء البرنامج كانت Static

من حيث حجز الذاكرة وتحديد السعات وو .... وذلك وفقاً لحدود بنية الملف

ستتعرف على ذلك اكثر حينما افصل تركيبة الملفات

اقتباس

واحيانا يهنق البرنامج ..

اعتقد ان ذلك يحدث عندما تقوم بحفظ صورة ذات الوان تعددية على النسق at3

اظن ذلك ليس تهنيق وانما هي مجرد عملية analyze coulor

ربما لو اني استخدمت ال Thread لما حدث ذلك

اقتباس

لكن أنا ما عندي الدلفي .. فااريد أن اعرف الطريقة التي انت استخدمتها في تخزين الالوان ..

يعني لو تعطينا الخطوات .. ككلام فقط . . .

انا تحت امرك :D

اقتباس

396 -------> Height Picture

401 -------> Width Picture

9 --------> Size Of Head

----------------------- Start Head ----------------------

255 255 255

229 229 247

0 0 0

----------------------- End Head ------------------------

----------------------- Start Body -----------------------

1

1

1

2

2

2

3

2

--------------------- End Body --------------------------

هذا هو الشكل العام للملف

سأقوم بتفصيلة

قمت بحفظ ارتفاع الصورة Height في البايت من 0 الى 4 على شكل Binary

وكما تعلم ان سعة كل Byte هي 256 ( 255 اذا كانت البداية من الصفر )

واحصل على السعة من خلال جمع قيم كل من 5 Bytes

فهذا يعني 255 + 255 + 255 + 255 + 255 = 1275

* لذلك جعلت هناك محدودية لدعم الصور لكي لا يحصل Over Load

( هناك طرق افضل لاستغلال 5 Byte في تخزين قيم كبيره ولكني استخدمت هذه الطريقة لانها الاسهل )

اما بالنسبة لعرض الصورة ( Width ) فهي مخزنة على البايت من 5 الى 9

اما البايت رقم 10 فهو يحمل سعة الرأس ( Head ) الذي يحتوي على الألوان

قد تستغرب من استخدام بايت واحد لتخزين السعة السبب في ذلك هو ان عدد الألوان محدود !!

ستعرف على ذلك بعد قليل

يبدأ رأس الملف ( Head ) من البايت 11 الى السعة المسجلة في البايت 10 مضروبة في 3 مضافاً اليها 2 ( &10 * 3 + 2 )

وذلك بأعتبار كل من قيمة R G B مخزنة على 3 بايت

بعدما يتنتهي الرأس يأتي الجسم ( Body )

حيث يتم تخزين كل Pixel على واحد بايت بحيث ان القيمة الموجودة في البايت هي عبارة عن عنوان رقم البايت في راس الملف الذي يحتوي على اللون

مثلاً لو كان البايت يحتوي على الرقم 2 فهذا يعني ان 2 * 3 ( يعطينا بداية البايت ) بحيث اللون سيكون مخزن من البايت 6 الى 8

وهذا ماجعل عمل at3 محدود حيث ان قيمة كل بيكسل على بايت واحد وهذا يعني انه غير قادر على عنونة اكثر من 256 لون في راس الملف

وهذا السبب ماجعلني استخدم البايت 10 فقط لسعة الراس الملف وذلك لمحدودية العمل

ارجوا ان يكون الشرح واضحاً

بالنسبة لكيفية استخلاص الألوان فقد كتبت تعليمية تحدد تكرارية الألوان

هذه هي باللغة باسكال ( Delphi )

function found(R:integer;G:integer;B:integer):integer;
var
i,founded:integer;
begin
founded:=-1;
i:=0;
while (founded=-1) do begin
if i>(hs*3)+2 then
break;

if ((R=header) and (G=header[i+1]) and (B=header[i+2])) then
founded:=i;

i:=i+3;
end;
if founded<>-1 then
result:=founded div 3
else
result:=founded;
end;

ستكون هكذا باللغة C++ (( ارجوا ان تكون خالية من الأخطاء ))

int found (int R,int G,int B)
{
int i,founded=-1;

for (i=0; i<=hs*3+2;i=i+3) 
{
if (founded!=-1) 
break;

if ((R==header) & (G==header[i+1]) & (B==header[i+2]))
founded=i;

}
if (founded!=-1)
return founded/3;
else
return founded;
}

علماً أن :

int hs;
int header[1275];

هما متغيرات عامة ( Global Variable )

حيث ان hs هي سعة Head

وال header هي مصفوفة البايتات المكونة لل head

نعطي هذه function قيم R G B للبيكسل ( Pixel ) الذي نقف عليه اذا تم ارجاع القيمة -1 فهذا يعني انه اللون غير موجود في ال Head

فنقوم بإضافته

if (found(r,g,b)==-1) {
header[hs]=r;
header[hs+1]=g;
header[hs+2]=b;
hs+=3;
} else
continue;

بعدما ننتهي من تكوين ال Head سنحتاج هذه التعليمة في Body حيث سنعيد قراءة قيم Pixel للصورة من جديد

بحيث لو فرضنا

int body[9999999];
int bs

حيث body هي جسم الملف فسيتم كتابة كل Pixel على بايت واحد ( حيث ان الحقل ( Cell ) الواحد يمثل Byte )

و bs حجم الجسم ( body )

فستكون كتابة قيم البيكسل بهذا الشكل

bs=0;
for(y=0;y<=image.bmHeight-1;y++)

			 {
				 for(x=0;x<=image.bmWidth-1;x++)

				{

					   pixel=GetPixel(hdc,x,y);


					rgb.r= GetRValue(pixel);
					rgb.g= GetGValue(pixel);
					rgb.b= GetBValue(pixel);
					body[bs]=found( rgb.r , rgb.g , rgb.b);
			bs++; 

			 }

اعتقد ان هذا هو كل شيء

ارجوا المعذرة اذا كان اسلوبي ركيكاً

اذا كنت تريدنا ان نستمر في تطوير هذا العمل فأنا مستعد لذلك بإذن الله

لدي الكثير من الحلول ولكن ربما لاجد الوقت لتطبيقها

ارجوا ان يزيد هذا النقاش سخونة لعل وعسى ان ننتج ولو لمرة واحد عمل يكون بأيدي عربية

تحياتي surini

فهمت الفكرة ... لكن ما احاول الوصول اليه الان أمران :

1 - امكانية تحويل صورة BMP الى AT2-3 .. دون رسمها على الشاشة .. فاذا توصلنا لهذه النقطة قطعنا شوط كبير .

2- يوجد شيء اسمه PALETTE فكل الصور على حسب علمي تحوي PALETTE وهو عبارة عن الالوان التي تستتخدمها الصورة ..

كيف نحصل على هذه الالوان ؟

الجواب: يوجد مكتبة تسهل لنا ذلك وهي devIL ... ستجد رابط المكتبة في توقيعي .

يوجد دالة اسمها GetPalette تعيد لنا مقبص hpalette بالتالي يمكن استخدامه مع WIN API .

سأعرض محاولاتي قريبا ان شاء الله .

اخي الشمري اشكرك على هذا التفاعل

اقتباس

فهمت الفكرة ... لكن ما احاول الوصول اليه الان أمران :

1 - امكانية تحويل صورة BMP الى AT2-3 .. دون رسمها على الشاشة .. فاذا توصلنا لهذه النقطة قطعنا شوط كبير .

اعتقد ان رسم الصورة على الشاشة ستفتح المجال للتطوير بشكل اكبر :D

حيث لن نكون محصورين للعمل على BMP فقط

ستجد ان اغلب برامج الرسومات تقوم بقراءة النسق ثم رسمه وفي حالة كنت تريد اعادة حفظة على نسق آخر

سيتم تحليل البيانات من الصورة المفتوحة وليست من الملف

(( وجهة نظر -_- ))

عموماًَ الفكرة رائعة بحد ذاتها

حيث لو قمنا بتنفيذها سنكون قادرين على فهم طبيعة ملفات BMP

اقتباس

2- يوجد شيء اسمه PALETTE فكل الصور على حسب علمي تحوي PALETTE وهو عبارة عن الالوان التي تستتخدمها الصورة ..

قمت ببحث سريع عن ملفات BMP

وجدت هذه المعلومات في موسوعة WiKi

http://en.wikipedia.org/wiki/Windows_bitmap

من قراءة خاطفة وجدت بعض المقتطفات

اقتباس

# Bytes #26-27 store the number of color planes being used. Not often used.

هذا هو مكان وجود PALETTE COLOR

اقتباس

Color Palette

This block of bytes define the colors being used inside the image.

كما ذكرت انت سابقاً ;)

فهذا هو مجرد اثبات لكلامك

اقتباس

Each entry contains 4 bytes. The first 3 bytes store the values for for blue, green and red respectively while the last one is unused and will be filled with 0 by most applications.

اكتشفت ان هناك تشابة مابينها وبين مااستخدمناه في at3

الفرق انهم يستخدمون 4 بايت لكتابة اللون الواحد ونحن نستخدم 3 بايت فقط :D

اقتباس

a value of 255 indicates that maximum intensity is used.

نفس المشكلة التي نعاني منها في at3

اقتباس

he color palette is not used when the bitmap is 16-bit or higher.

هذ هو الحل المستخدم لحل المشكلة :s

بعد قرائتي لتلك المعلومات بدأت تراودني بعض الافكار

والتي ستمكنني من تطوير at3 لدعم اكثر من 16-bit

اتمنى من الله التوفيق في عمل ذلك

اقتباس

يوجد مكتبة تسهل لنا ذلك وهي devIL ... ستجد رابط المكتبة في توقيعي .

يوجد دالة اسمها GetPalette تعيد لنا مقبص hpalette بالتالي يمكن استخدامه مع WIN API .

مارأيك لو استغنينا عن المكتبات الجاهزة :rolleyes:

سنقوم بدراسة جميع انساق الصورة وسنكتب الخوارزمية القادرة على فتح كل نوع على حده

وسنبدأ اولاً بـ BMP

الطريق سيكون طويلاً وصعباً .... ولكن سنجني الثمار في الأخير

سأبدا من الآن في المحاولة من كتابة خوارزمية لفتح ملفات BMP

وسأكون في انتظار ابداعاتك ;)

تحياتي surini

اقتباس

سأبدا من الآن في المحاولة من كتابة خوارزمية لفتح ملفات BMP

الامر ما يستاهل خوارزمية .. مجرد معرفة بنية الملف ..في منتدى برمجة الالعاب طرح الاخ حسن موضوع مشابه .. عندك ايضا هذه الروابط..

http://local.wasp.uwa.edu.au/~pbourke/dataformats/bmp/

http://atlc.sourceforge.net/bmp.html

اقتباس

مارأيك لو استغنينا عن المكتبات الجاهزة

نعم كلامك صحيح ..لكن انا فقط اريد تجربة هذا الpalette ..

بعد 5 ساعات من الدراسة والتحليل لبنية ملفات BMP ( المعقدة ):D

استطعت بناء برنامج قادر تحليل البيانات من ملفات BMP ورسم الصورة دون استخدام اي مكتبة جاهزة ;)

الشي الغريب في BMP انها متشعبة جداً حيث اعتقد انه شارك في بناءها الكثير من الاشخاص

فكل شخص له اسلوب في قراءة وتوزيع البيانات

قمت بتصميم برنامجين منفصلين الأول يقوم فتح الصور من نوع 8 bit (( اي بحدود 265 لون ))

والثاني يقوم بفتح الصور من نوع 24 bit (( وهي الاكثر شيوعاً ))

ربما لايكون البرنامجين خالين من الأخطاء وذلك لانني من لحظات انتهيت من بنائهم

سأترك لك المجال للتجربة وانتظر ردك

ولي عودة إن شاء الله سأشرح فيها تركيب ملفات BMP

وبعض المعلومات التي لم اجد لها مرجعاً

تحياتي surini

BMP_Reader8.rar

BMP_Reader24.rar

بارك الله فيك .. والله يسامح العشرين شخص اللي حملوا المرفقات وتفرجوا على التطبيق ثم لاحس ولاخبر .

أنا لا املك جهاز في البيت حاليا .. لذلك لا استطيع عمل التجاب اللازمة .

ولكن أتمنى أن تحاول تطوير الكود ليقوم بالحصول على الPALETTE ( الالوان التي تستخدمها الصورة) ..

وأنا متى ما رجع إلي جهازي سأقوم باضافة التجارب ان شاء الله .