ภาพ SVG ดูลดขนาดลงกว่า png, jpg หรือ gif ที่มีความละเอียดสูงหรือไม่


15

ฉันรู้ว่าถ้าคุณต้องการขยายภาพ SVG เป็นทางเลือกที่ชาญฉลาด

อย่างไรก็ตามสถานการณ์ของฉันคือฉันมีไอคอนที่ฉันต้องการให้ผู้ใช้สามารถอัปโหลดผ่าน CMS SVGs นั้นช่างยากที่จะสร้างขึ้นดังนั้น jpg, gif หรือ png จึงเป็นรูปแบบที่เหมาะสำหรับผู้ดูแลระบบ

หากอัปโหลดขนาดเท่ากันหรือใหญ่กว่าขนาดหน้าจอและคงไว้ในอัตราส่วนที่ถูกต้องสามารถ jpgs, gif หรือ pngs มีคุณภาพสูงเท่ากับ SVG เมื่อลดขนาดลงหรือไม่

ข้อสันนิษฐานของฉันคือเบราว์เซอร์จำเป็นต้องลดขนาด svg ให้ต่ำลงด้วยเช่นกันดังนั้นพวกเขาจึงมีแนวโน้มที่จะเบลอมากเท่ากับรูปแบบอื่น ๆ แม้ว่า gif จะดูเบลอมากกว่า


4
เป็นคำถามที่ดี แต่ฉันเชื่อว่าคำตอบคือ "ขึ้นอยู่กับเบราว์เซอร์"
usr2564301

คำตอบ:


7

(หมายเหตุ: โปรดอ่านคำตอบของ OPก่อนหน้านี้เนื่องจากคำตอบของฉันคือความคิดเห็นในการสืบสวนของ OP)

นี่เป็นปัญหาที่ทราบของ Android Chrome ในบางส่วนของการสร้างพวกเขาปิดการใช้งานการป้องกันนามแฝงทำให้รูปร่างเวกเตอร์จะแสดงผลด้วยขอบที่คมชัด เหตุผลนี้คือเพื่อลดการโอเวอร์โหลดที่สร้างโดยการคำนวณการป้องกันนามแฝง เนื่องจากมีการร้องเรียนพวกเขาจึงปล่อยการอัปเดตที่ควรเปิดใช้งานการป้องกันนามแฝงกลับ

มีหลายเธรดในสแต็คโอเวอร์โฟลว์ที่พูดถึงปัญหานี้ นี่คือหนึ่งในนั้น:
/programming/19875908/vectors-poorly-displayed-on-chrome-for-android-canvas

ฉันไม่พบการอ้างอิงถึงปัญหาเดียวกันใน iPod Touch Safari แต่อาจจะปลอดภัยในการคาดการณ์และถือว่าปัญหาเหมือนกัน

มีวิธีที่จะพยายามบังคับให้ต่อต้านนามแฝงแม้ว่าจะปิดการใช้งานเช่นเคล็ดลับนี้โดยทั่วไปจะเพิ่มการเติมเล็กน้อยรอบองค์ประกอบทำให้เบราว์เซอร์ด้วยเหตุผลบางอย่างที่จะใช้ต่อต้านนามแฝง คุณสามารถลองตั้งค่าคุณสมบัติการแสดงผลรูปร่างขององค์ประกอบเป็นสิ่งที่แตกต่างจากขอบที่คมชัดและดูว่าเบราว์เซอร์ให้เกียรติ


การเพิ่ม -webkit-backface-ทัศนวิสัย: ซ่อนอยู่หมายความว่า non-svgs เบลอบน iPod ในแบบเดียวกับ svgs และตอบคำถามของฉัน - นั่นคือไม่จำเป็นต้องเลือกอีกอันเมื่อปรับขนาดลง การแก้ไข Android อย่างแปลก ๆ ดูเหมือนจะไม่ได้มาตรฐานพฤติกรรมการแสดงผลใน Android Chrome / native broswer รุ่นของฉัน แต่นั่นเป็นปัญหาที่แตกต่างกัน ขอบคุณสำหรับความช่วยเหลือของคุณ.
Richard B

13

ฉันเพิ่งจะทำการทดสอบและความแตกต่างเพียงอย่างเดียวก็คือบนเบราว์เซอร์มือถือ

ฉันสร้างภาพ Twitter ของไอคอน 990x900px (ไอคอนนั้นดูเหมือนรายละเอียดการออกแบบที่ดีเกินไปสำหรับการปรับขนาดที่ดีมากสำหรับการทดสอบนี้) ฉันบันทึกสิ่งนี้เป็น SVG, JPG, GIF, GIF โปร่งใส (เพียงรูปนก, ไม่มีสีพื้นหลัง, แทนที่จะเพิ่มสิ่งนี้ด้วย CSS), PNG, PNG โปร่งใส

จากนั้นฉันย่อขนาดลงเป็น 15px, 25px, 50px, 100px และ 150px

นี่คือผลลัพธ์ใน Firefox: ป้อนคำอธิบายรูปภาพที่นี่

นี่คือผลลัพธ์ใน Chrome: ป้อนคำอธิบายรูปภาพที่นี่

หากเราซูมเข้าไปที่หน้าจอของผลลัพธ์ที่เล็กที่สุดเพื่อให้เราเห็นว่าพิกเซลกำลังถูกสร้างขึ้นมาอะไร Firefox (ด้านบน) จะทำให้ขอบของรุ่นที่ไม่โปร่งใสดูมืดลงเล็กน้อย แต่ผลลัพธ์อื่น ๆ นั้นคล้ายกันมาก

ป้อนคำอธิบายรูปภาพที่นี่

อย่างไรก็ตามในเบราว์เซอร์ IPod Touch Safari รุ่น SVG นั้นค่อนข้างเบลอและตัวอื่น ๆ ค่อนข้างเป็นพิกเซล:

ป้อนคำอธิบายรูปภาพที่นี่

ผลที่คล้ายกันจะเห็นได้บน Android Chrome ฉันยังไม่ได้จับภาพหน้าจอของสิ่งนี้

ฉันสงสัยว่าเหตุผลนี้อาจเป็นเพราะความหนาแน่นของพิกเซลซึ่งเป็นความแตกต่างหลักในการแสดงแม้ว่าจะเหมาะสมกว่าสำหรับฉันหากภาพทั้งหมดมีการจัดการที่แตกต่างกันบนมือถือไม่ใช่แค่ SVG

หากใครบางคนสามารถอธิบายได้ว่าทำไมในกรณีนี้ฉันจะถ่ายโอนเห็บคำตอบที่ยอมรับได้ มิฉะนั้นฉันคิดว่าคำตอบ TL; DR นั้นขึ้นอยู่กับว่าคุณต้องการไอคอนเบลอหรือพิกเซล (หรือเพื่อให้ไอคอนจำนวนมากที่ขนาดพิกเซลสมบูรณ์แบบสำหรับจุดพักการตอบสนองของคุณ)

แก้ไข: ตั้งแต่ฉันสังเกตเห็นว่า svgs มักจะชัดกว่าบนอุปกรณ์แอปเปิ้ล - นกทวิตเตอร์อาจมีรายละเอียดเกินกว่าที่จะแสดงในการทดสอบของฉันข้างต้นดังนั้นรู้สึกว่ามันเป็นรูปแบบที่ถูกต้องสำหรับไอคอน


SVG แสดงผลตามเวลาที่แสดงและสามารถได้รับประโยชน์จาก AA ส่วนอื่น ๆ นั้นเป็นความละเอียดคงที่และ AA เดียวเท่านั้นที่สามารถแสดงผลได้ 2x เบลอ; และลดซึ่งจะไม่ช่วยจริงๆยกเว้นในสถานการณ์ "คัดกรอง" สำหรับ SVG วิธี AA แบบตายตัว (เช่นทั่วทั้งกระดาน 4x 4x แบบง่ายของ FSAA) จะก้าวร้าวมากเกินไปเมื่อคุณมีความกว้างเพียง 8px และการสุ่มลงมาจะทำให้เกิดภาพเบลอบ้าง
Yorik

โปรดทราบว่าประเภทของการปรับขนาดและการสุ่มใหม่นั้นขึ้นอยู่กับการใช้งานซอฟต์แวร์ ส่วนใหญ่ไปสำหรับ "เร็ว" หรือ "สมดุล" แทนคุณภาพ
Yorik

3

มีความแตกต่างที่สำคัญมากระหว่างภาพเวกเตอร์และภาพบิตแมป อิมเมจเวกเตอร์ถ้าเราทำให้บิตง่ายขึ้นจะมีการสร้างการแสดงผลโดยไคลเอ็นต์ในขณะที่อิมเมจบิตแมปกำลังแสดงผลโดยคุณ

ซึ่งหมายความว่าแอปพลิเคชันที่คุณส่งภาพไปพูดนั้นมีความหมายมากขึ้น ผลลัพธ์ที่ได้คือคุณได้ติดตามข้อเสีย :

  • ต้องใช้ทรัพยากรมากขึ้นเพื่อทำให้ภาพเรียบร้อย
    • ในกรณีนี้การแสดงผลอาจเลือกที่จะลดคุณภาพเนื่องจากไม่มีทรัพยากรเพียงพอที่จะทำได้ดีกว่า
  • ระบบถ่ายภาพแต่ละระบบมีชุดของนิสัยและข้อบกพร่อง
    • ทำให้มันยากขึ้นที่จะสอดคล้องกัน
    • คุณได้รับปัญหาของโปรแกรมเมอร์

ในทางตรงกันข้ามมีประโยชน์บางอย่างของสิ่งนี้:

  • ภาพสามารถปรับขนาดได้อย่างอิสระและมีตัวเลือกการจัดการมากขึ้น
    • นี่เป็นเพียงผลของงานที่ทำในไคลเอนต์ดังนั้นพวกเขาจึงสามารถใช้เวลามากขึ้นในการคำนวณพิกเซลเพื่อให้ได้ภาพที่ใหญ่ขึ้นถ้าคุณส่งองค์ประกอบที่รู้วิธีการขยาย
  • ข้อมูลในหลายกรณีมีขนาดเล็กกว่าภาพพิกเซล (แม้ว่าจะไม่จำเป็นต้องเป็น)

มีไม่มากที่คุณสามารถทำได้ถ้าระบบมีตัวเรนเดอร์ buggy แอปพลิเคชันปลายทางของคุณเป็นตัวเลือกและพวกเขาสามารถใช้ตัวเลือกนั้นเพื่อตัดสินใจที่ไม่ดี

ไหนดีกว่ากัน

ขึ้นอยู่กับว่าคุณสามารถแสดงภาพของคุณได้ดีแค่ไหนและมีแบนด์วิธเท่าไหร่ แน่นอนว่าเป็นไปได้ที่จะทำการเรนเดอร์ที่ดีกว่าที่เบราว์เซอร์ทำ ไม่น่าแปลกใจเลยที่คน ๆ หนึ่งสามารถทำงานได้ดีกว่านักวาดภาพประกอบ แต่คุณสูญเสียผลประโยชน์ทั้งหมดของการแสดงผลที่เลื่อนออกไป

มีตัวเลือกที่สามคือ

หากคุณไม่พอใจกับผลลัพธ์คุณสามารถลองสร้างเครื่องมือการแสดงผลของคุณเอง ด้วยแพลตฟอร์มที่รองรับ webgl คุณสามารถ ดูตัวอย่างที่นี่ แต่นี่เป็นฮาร์ดคอร์ที่สวยและไม่ได้ช่วยให้คุณประหยัดรายละเอียดในการติดตั้ง


2

(คะแนนไม่เพียงพอที่จะแสดงความคิดเห็นในคำตอบของ Richard B โดยตรง)

เพื่อตอบคำถามของคุณ Richard B เรามักเห็นผลกระทบนี้ต่อองค์ประกอบที่จำเป็นต้องมีการลดรอยหยักบนฮาร์ดแวร์ที่ใช้พลังงานต่ำ สิ่งนี้ยังเกิดขึ้นกับองค์ประกอบ DOM แบบโค้งมุมเมื่อการลดรอยหยักหรือลบออกจากสภาพแวดล้อมเหล่านั้น

ที่ บริษัท ของเราเรามีบางกรณีที่เราใช้ฮาร์ดแวร์พลังงานต่ำและเริ่มพบปัญหา "รูปร่างที่มีขอบขรุขระมาก" นี้ เราได้ปิดการใช้งาน / ลดจำนวนการต่อต้านนามแฝงเพื่อปรับปรุงประสิทธิภาพ นี่อาจเป็นเหตุผลเดียวกับที่การทดสอบบนมือถือของคุณส่งคืนผลลัพธ์ที่พวกเขาทำ


ทำให้รู้สึกเป็นเหตุผล แม้ว่าความอัปยศ SVG ดูเหมือนจะไม่สอดคล้องกับภาพประเภทอื่น ๆ
Richard B

1
@RichardB เอ่อพวกมันต่างจากภาพปกติ คุณสามารถโต้ตอบกับพวกเขาราวกับว่าพวกเขาเป็นโหนด DOM เส้นทางและรูปร่างของพวกเขาได้รับเหตุการณ์และคุณสมบัติ CSS เช่นเดียวกับโหนด DOM จริงดังนั้นหากความเข้าใจของฉันถูกต้องพวกเขาปฏิบัติตามเส้นทางการแสดงผลเช่นเดียวกับโหนดอื่น ๆ และมันสมเหตุสมผลในบริบทนี้ รูปภาพเป็นช่องแบบแรสเตอร์ไรซ์และผ่านช่องทางการแสดงผลที่แตกต่างกันบางครั้งแม้แต่แกะสลักพื้นที่บน GPU
Brak
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.