Category talk:Images with inappropriate JPEG compression

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Can we expand this all to JPEG / GIF? They both suffer from the same problems. gren グレン 08:24, 3 January 2006 (UTC)[reply]

What do you mean? JPEG use is certainly appropriate for photographs. GIF use is also appropriate for animations, and is acceptable for limited-color graphics. There is some discussion of other possible tags for cleanup at Template talk:BadJPEG. --ChrisRuvolo (t) 17:24, 3 January 2006 (UTC)[reply]

BadJPEG and fairuse[edit]

Some of the images listed are logos used under fair use. While SVG would be ideal it would not be legal since infinite size can in no way be interpreted as "low resolution". Should fair use images be removed? Or should we take into account that they could be so small and need a slightly larger version. However, SVG is out of the question. I'd think a Template:low resolution logo for images with too low of a resolution might do a better job. Asking for low resolution images... but not badly compressed ones. gren グレン 09:00, 3 January 2006 (UTC)[reply]

Note that the WP:FU guidelines mention low resolution works but the article on fair use does not. Resolution alone doesn't preclude fair use. SVG is appropriate for encapsulated postscript conversion (e.g. Image:EEA agency logo.svg). Also, people have redrawn logos as SVG, see for example Image:007.png (now deleted), redrawn as Image:007.svg. I don't see why redrawing a logo accurately would not fall under fair use of the copyright or trademark. For more info, see the debate for deletion at: Wikipedia:Templates for deletion/Log/Not deleted/December 2005#Template:BadJPEG. --ChrisRuvolo (t) 17:24, 3 January 2006 (UTC)[reply]
Converting PNG images to SVG does not magically add extra resolution. SVG's have an implicit sense of resultion and realism. Unless you're recreating extensive amounts of detial, SVG's shouldn't be a problem. --Interiot 05:45, 24 February 2006 (UTC)[reply]

Sorted report[edit]

For what it's worth, I created a report here that lists images sorted by the number of pages the image is used on. --Interiot 05:45, 24 February 2006 (UTC)[reply]

Tagging has been a bit overzealous[edit]

A lot of images are being listed here just because they're not photos, but they're still high-color images like 3D logos and wouldn't necessarily benefit much from PNG. I'm going to start removing the template from stuff like that, it makes it too hard to find the MS Paint diagrams and such that really need PNG-ing. DopefishJustin 00:17, 4 April 2006 (UTC)[reply]

I disagree. JPEGs can't be transparent and have artifacts, which are particularly obvious on rendered output, 2D or 3D such as logos. --ChrisRuvolo (t) 02:18, 4 April 2006 (UTC)[reply]
Wikipedia doesn't need transparency for anything, and artifacts are really a matter of how the image was compressed. A PNG of a large 3D render is way, way bigger than a JPEG version saved with generous quality settings, and only looks slightly better. Also, to be realistic, it's not like any of the companies who made these low-res JPEG logos are are going to come over one day and give us high-resolution translucent PNG versions, and frankly we don't need them because the logo is only used as a fair-use thumbnail to adorn the company article. Believe me, I'm the biggest PNG nazi around, but it's just not useful to tag stuff like this. DopefishJustin 18:22, 4 April 2006 (UTC)[reply]
Not all pages have white backgrounds, only the main namespace. It also depends on the theme being used. Although I agree that the amount of work to replace all of these would be significant, ideally they will eventually be replaced. --ChrisRuvolo (t) 18:25, 25 May 2006 (UTC)[reply]
It's also worth mentioning that badJPEG is often also a call for SVG -- not only PNG. I think they are all things that should be tagged... but, I would agree that maybe a priority system would help. Most don't have obvious artifact and are less important to fix than others. gren グレン 10:17, 11 May 2007 (UTC)[reply]