Was that given a go?
Another example of what is possible on ImageOptimization in browser:
This video goes over the tech. They compiled the state of art codecs (the same we use on the server for Discourse) to WASM 
Looks like a cool, optional thing for Discourse.
The WASM for mozjpeg can be compressed to 48k and the WASM for OptiPNG is 93k.
9 إعجابات
My image folder grows to 42.3 GB.
So I think I need to figure out image processing and storing in Discourse 
إعجاب واحد (1)
I’m not sure if this is the right topic to post on, but I am very interested in knowing if there’s a way to automatically downsize images before they get stored in my discourse. My community is going to be very image heavy.
I’m less than a week in and already 350 MB used and not even open to general public yet. Would like to be able to resize images down to some resolution so that I keep them < 1MB or something like that (based on image resolution though as per norm I think).
I’d recommend using Digital Ocean spaces or S3 for your images so you don’t need to worry about space so much.
It seems unlikely that a community that really likes images is going to want really bad ones. 
We already have max_image_megapixels site setting, can you try toning that down?
إعجابَين (2)
@sam Yes, but, the problem is there’s a big difference between reducing some resolution that most people won’t even notice (IMO big diminishing returns), versus blocking them from uploading at all. On my main site, I downsize to 1500x and no one cares. But if they can’t upload it’s a huge hassle.
@pfaffman This sounds perfect, I guess I need to read:
I wonder, this is probably something I need to do sooner than later, because I’m guessing trying to migrate the files from discourse hosting to s3 could be hard?
إعجاب واحد (1)
I do support a simpler mechanism longer term, something like
All images must be smaller than 500k but allow people to upload stuff up to 2000k and fix on server if needed by either downsizing or reducing resolution. Try resizing on client first if possible.
But yeah, getting to this level of fidelity will take quite a while.
إعجابَين (2)
There is a rake task that will do it, but I’d say that sooner is better than later.
إعجاب واحد (1)
معظم مستخدمينا يستخدمون بيانات الهاتف المحمول، وأحيانًا قد تكون سرعة الإنترنت لديهم 3G أو أقل. في كثير من الأحيان، ليست جودة الصور التي يرسلونها مهمة، بل السرعة هي الأهم بالنسبة لهم.
في حالة رفع الصور عبر شبكة 3G (حوالي 2 ميجابت/ثانية)، يستغرق إرسال صورة بحجم 5 ميجابايت حوالي 20 ثانية، وقد يكون هذا الوقت أطول بكثير مع انخفاض السرعة.
كما يشير @فالكو، باستخدام خوارزميات مماثلة، يمكن تقليل حجم صورة بحجم 5 ميجابايت إلى 190 كيلوبايت عن طريق ضغطها من جانب العميل وتقليل أبعادها. بهذه الطريقة، يتم إرسال الصور بشكل أسرع (في شبكة 3G، حوالي ثانية واحدة) مع استهلاك موارد أقل.
هل توجد هذه الميزة في خارطة الطريق؟ وإذا كانت الإجابة بنعم، فهل هي قريبة أم بعيدة؟
إنها شيء نرغب في القيام به في النهاية، لكنها ليست مدرجة في خارطة الطريق العامة لدينا في #releases.
سأكتب مقترحًا للطلب (RFC) حول هذه الميزة هذا الأسبوع حتى نتمكن من المضي قدمًا فيها، على الأقل من حيث المواصفات.
7 إعجابات
هذا ممكن بالفعل في iOS. كالتالي (سأشارك لقطة شاشة، انتظروا)
عبر
لقد اخترت “كبير”. لكن لا يزال الأمر يخلّ بالاتجاه!
7 إعجابات
شكرًا لك، هذا رائع 
أتمنى أن يتعلم أندرويد ذلك أيضًا 
بالإضافة إلى هذه الميزة، يمكن أن يكون lightbox زرًا لتدوير الصور
هذه المكتبة تبدو مثيرة للاهتمام: GitHub - silvia-odwyer/photon: ⚡ Rust/WebAssembly image processing library · GitHub
يبدو أن ملف الثنائي wasm هو الخيار المثالي لأنه سيكون سريعًا وفعالًا من حيث الذاكرة.
3 إعجابات
أنا فضولي لمعرفة ما إذا كان ضغط الصور من جانب العميل، عندما يكون ذلك ممكنًا، سيؤدي إلى تأثير ملحوظ على أداء خادم الويب مع استضافة منخفضة المواصفات (مثل مثيل Digital Ocean المشترك للمعالج).
ألاحظ ارتفاعًا متقطعًا في استخدام المعالج، وأعتقد أنه يرتبط برفع المستخدمين للصور التي تحتاج إلى ضغط. هل رأى أي شخص تأثيرًا مشابهًا؟
إعجابَين (2)
مناقشة التنفيذ على Optional image optimization before upload
إعجاب واحد (1)