Prawda jest jednak bolesna – nie uda się uniknąć choć minimalnej obróbki zdjęcia przed umieszczeniem na forum, bo limit będzie zawsze mniejszy niż wielkość zdjęć prosto z aparatu/printscreena. A co za tym idzie, i czas potrzebny na umieszczenie tutaj zdjęcia nie skróci się zbytnio. Zatem jedynym argumentem pro/kontra danemu limitowi wielkości jest tylko kwestia estetyki i czytelności zdjęcia. Jak na razie, nie widzę przeciwwskazań aby podnieść ten limit do 250kb, ale też wiem, że tak na prawdę nic to nie zmieni, bo załączniki podlegające uwadze moderatorskiej są często >500kb. Rozdzielczości nie ma co ograniczać, limit wagowy wystarczy.
Myślę, że oprócz kwestii estetyki ma również pewne znaczenie kwestia czasu wymaganego do obróbki. Przy przygotowywaniu obrazka do publikacji widzę następujące kroki:
1. Minimalna obróbka polegająca na przejechaniu suwakiem stopnia kompresji do momentu uzyskania regulaminowego limitu. Jak czytałem, są programy graficzne, które pozwalają to nawet mocno ułatwić — podaje im się wielkość a one same dobierają stopień kompresji. Moim zdaniem konieczne minimum.
2. Poprawne kadrowanie — zadanie o wiele bardziej czasochłonne. Jeśli przeszkadzajki zajmują mniej niż 20% obrazka, to w przypadku screenów poglądowych akceptuję to, że ktoś tego nie zrobił (mimo, że sam bym kadrował). Co innego screeny artystyczne i zdjęcia, np. na jakiś konkurs — tam kadrowanie to absolutna konieczność, ale i tak w regulaminie trudno by jasno uregulować co to jest poprawne kadrowanie, więc nie powinno się tam znaleźć.
3. Optymalne dobranie rozdzielczości obrazka i stopnia kompresji, jeśli po kadrowaniu sama zmiana stopnia kompresji wywołuje artefakty. Tutaj mamy przestrzeń dwuwymiarową i zautomatyzowanie tego jest trudne. Ja sam zmieniłbym rozdzielczość raz, do znanej mi wcześniej zazwyczaj wystarczającej i dostosował następnie kompresję. Jeśli do tego kroku dojdzie to występować będzie utrata szczegółów wynikająca nie tylko z limitu wielkości, ale i przybliżonego algorytmu postępowania jaki jest dostępny dla człowieka, zamiast algorytmu optymalnego znajdującego idealny zestaw rozdzielczość + stopień kompresji.
Z kilku prostych testów, które zrobiłem wynika, że limit 150kB wystarcza na bezproblemowe skompresowanie od 1 do 1.5 megapiksela (upraszczając ~ 1280x1024). Podniesienie limitu dwukrotnie pozwoli umieszczać bez większego wysiłku obrazki o wielkości 2 do 3 megapikseli (czyli nie większe niż 2048x1536). Jeśli spojrzeć na wątek o rozdzielczościach, to widać że jest już całkiem liczna grupa osób mających monitory o rozdzielczości 1.5 megapiksela i większe. Dlatego mimo tego, że zgadzam się, że jakaś obróbka jest potrzebna, to uważam obecny limit za zbyt restrykcyjny i w dalszym ciągu postuluję podniesienie go do 250kB. Jak sam zauważyłeś, totalni olewacze regulaminu i tak wklejają obrazki dużo większe.
I ostatnia sprawa — czy ktoś wie, czy można wpiąć jakiś skrypcik przetwarzający załączniki? Jeśli tak, to można w prosty sposób ująć pracy moderatorom — jeśli załączany jest jpeg powyżej limitu regulaminowego, to przetrawić go przez ImageMagic (komenda convert -define jpeg:extent=xxxkB powinna zmniejszyć do xxxkB) i po sprawie. Alternatywnie można do crona wrzucić przeczesywanie katalogu z załącznikami i konwersję. W obu wypadkach wypadałoby najpierw przemyśleć, czy tak brutalne rozwiązanie jest akceptowalne i zbadać czy działa poprawnie.
Edit — sprawdziłem sprawę SMF (1.1.7) i załączników. Na moje oko dwie najprostsze opcje to:
1. W Post.php, w funkcji Post2(), przed linią 1452
$_FILES['attachment']['size'][] = filesize($modSettings['attachmentUploadDir'] . '/' . $attachID); dodać wywołanie zewnętrznego skryptu, który sprawdzi typ pliku i w razie potrzeby przepuści go przez ImageMagic. Ktoś znający się na PHP mógłby pewnie logikę skrypcikową schować w jakiejś funkcji php-owej wywoływanej z tego miejsca. Zaletą jest konwersja na wejściu danych, ale trzeba zmienić kod SMF.
2. Dodać do crona skanowanie katalogu z załącznikami i konwertować nowe zbyt duże obrazki, a następnie wywoływać wbudowane w SMF naprawianie przechowywanych w bazie danych informacji o załącznikach co porawi wielkości załączników wyświetlane w postach. Zaletą jest brak ingerencji we wnętrzności SMF, wadą konieczność periodycznego skanowania katalogu i bazy danych.
