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 업로드(약 2Mbps) 환경에서는 5MB 이미지의 전송에 약 20초가 소요되며, 속도가 낮아질수록 이 시간은 훨씬 길어질 수 있습니다.
@Falco가 지적한 대로, 유사한 알고리즘을 사용하면 클라이언트 측에서 압축하고 해상도를 낮추어 5MB 이미지의 크기를 190KB까지 줄일 수 있습니다. 이렇게 하면 전송 속도가 빨라지는(3G 환경에서 약 1초) 동시에 필요한 리소스도 절감됩니다.
로드맵에 이와 같은 기능이 포함되어 있나요? 만약 그렇다면, 구현 시기는 가까운 미래인지 먼 미래인지 궁금합니다.
우리는 궁극적으로 이 기능을 구현하고 싶지만, 현재 공개된 #releases 로드맵에는 포함되어 있지 않습니다.
이번 주에 이 기능에 대한 RFC를 작성하여, 적어도 명세(specification) 측면에서 진전을 이룰 수 있도록 하겠습니다.
7개의 좋아요
7개의 좋아요
고맙습니다, 정말 좋습니다 
안드로이드도 배웠으면 좋겠습니다 
이 기능 외에도 lightbox는 이미지 회전 버튼으로 사용할 수 있습니다
이 라이브러리가 흥미로워 보이네요: GitHub - silvia-odwyer/photon: ⚡ Rust/WebAssembly image processing library · GitHub
wasm 바이너리는 빠르고 메모리 효율적이므로 이상적인 선택으로 보입니다.
3개의 좋아요
클라이언트 측 이미지 압축이 가능한 경우, 사양이 낮은 호스팅(예: 공유 CPU의 DigitalOcean 인스턴스) 환경에서 웹 서버 성능에 눈에 띄는 영향을 미칠지 궁금합니다.
간헐적으로 CPU 사용률 스파이크가 발생하는데, 이는 압축이 필요한 이미지를 업로드하는 사용자와 상관관계가 있다고 생각합니다. 비슷한 영향을 경험하신 분 계신가요?
2개의 좋아요
1개의 좋아요