ตอนนี้ลองเขียน Luko Sharpening โดยได้ศึกษาระบบการทำงานมาจาก
kitty
require 'RMagick'
include Magick
def luko(p)
layer1 = p.unsharp_mask(40,1,0.18,0)
layer2 = layer1.unsharp_mask(0.3,1,1.5,0)
layer1.composite!(layer2,Magick::CenterGravity,DarkenCompositeOp)
layer2.opacity=TransparentOpacity*0.5
layer1.composite!(layer2,Magick::CenterGravity,LightenCompositeOp)
return layer1
end
ตัวอย่างรูปที่ทำกับไม่ทำดูได้จากของ kitty นะครับ แต่บางถาพเช่นภาพคน บางรูปก็ไม่เหมาะทำ luko เพราะหน้าจะคจนเห็นกละ ชัดเจนมาก หุหุ
[...]
Published on Thu, 01 Jan 2009 15:49
พี่แสนเคยบอกไว้มานานแล้วว่า เวลาย่อรูปเนี่ยเราไม่ควรย่อลงไปให้ได้ขนาดในทันที เช่น จาก 100% ไปเป็น 50% เราคววรจะแบ่งการย่อทีละนิดๆจาก 100% ไปเป็น 75% แล้วค่อยย่อจาก 75% ให้ได้ 50% หลังการย่อแต่ละครั้งให้ทำ unsharp-mask ด้วยจะทำให้ภาพคมขึ้นและดูสวยงาม
My brother SAN told me long time, when I have to resize, I should not resize to aspect ratio immediately such as 100% to 50%. I have to resize little by little from 100% to 75% then resize from 75% to 50 . Then after each resize process, it should be applied unsharp-mask filter. I will make more sharpen.
ผมก็เลยเขียนเพิ่มให้มันเป็นการแบ่งครั้งที่จะทำการ resize ได้ดังนี้
SHARPEN.times do
nphoto = photo.resize(NEWSIZE**(1.0/SHARPEN))
photo = nphoto.unsharp_mask
end
ดูได้จากภาพตัวอย่าง ได้ที่ multiply
[...]
Published on Wed, 10 Sep 2008 16:01
คือว่าผมใช้ debian + ruby + rmagick เขียน script เพื่อที่จะทำการ stamp รูป แต่มาได้ความคิดว่า อย่าง convert เนี่ย ถ้าเราเรียก
$ convert -resize 1600 *.jpg
มันจะใช้ cpu 1 core เต็มๆ แต่อีก core จะชิวๆ หรือไม่ทำงานยุ่งเกี่ยวกับ convert เลย ก็เลยลองให้มันทำ
$ convert -resize 1600 *[02468].jpg &
$ convert -resize 1600 *[13579].jpg &
ผลลัพท์ที่ได้คือมันใช้ 2 core ทำงาน เป็นเพราะ shell เรียก convert นี่เป็น native ซึ่งมันจะไปทำงานแบบ fork จึงได้ผลลัพทธ์ดังกล่าว
จากที่อ่านมา Fork คือ Heavy Weight Process ที่แยก resource กันชัดเจน ส่วน Thread คือ Light Weight Process ที่แบ่งปัน resource ซึ่งกันและกัน
แต่ปัญหาอยู่ที่ว่าคือผมเขียน ruby คิดว่าถ้ามันเป็น thread ก็จะน่าได้ผลลัพธ์เช่นเดียวกับการ fork 2 ครั้ง แต่ผลลัพธ์ที่ได้กลับกลายเป็นว่า การทำงานนั้นไม่เต็ม 2 core คือใช้เพียงแค่ 1 core เท่านั้น
จากการศึกษาเพิ่มเติมได้ผลออกมาว่า thread นั้นมี 2 แบบคือ user space และ kernel space
- Kernel space จะเป็น thread แบบ native คือ kernel จะเป็นผู้จัดสรรและสับเปลี่ยน ก็จะได้ประสิทธิภาพตามคุณภาพของ kermel + cpu
- User space หรือเรียกอีกอย่างว่า Green thread คือ thread ที่ทำงานแบบ time slice โดยผู้รับผิดชอบคือ VM (Virtual Machine) ในกรณีของผมคือ ruby นั่งเอง VM จะทำหน้าที่จัดสรรและสับเปลี่ยน เสหมือนเป็นการจำลอง thread อีกที ผลที่ได้คือ kernel เห็นเป็นเพีบง singel thread จึงทำงานได้เต็มที่แค่ 1 core
สรุปได้ว่า thread บน ruby นั้นป็น green thread จึงได้ผลลัพธ์ดังกล่าว ทางแก้ตอนนี้คือเขียนให้ ruby นั้น fork อีก process
ไม่ใช่ว่า ruby thread จะไม่มีประโยชน์ ไว้จะลองเขียน ประโยชน์ของ ruby thread ดู
[...]
Published on Wed, 03 Sep 2008 16:57