Manual:Image administration/pt

Este artigo descreve como MediaWiki manipula e armazena imagens, e dá algumas informações sobre como o configurar.

O mesmo se aplica a qualquer outro tipo de arquivo que possa ser carregado. Uma vez que todos os arquivos são armazenados com um artigo correspondente no namespace imagem, e que é identificado como uma imagem. Prior to MediaWiki 1.14, the "Image:" namespace was used instead. "Image:" is still retained as an alias for backward compatibility.

Envio e uso de imagens
Veja: Help:Images

Permitindo o envio de imagens
Para fazer o envio de imagens, três condições têm de ser preenchidas:


 * 1) O MediaWiki deve ter o envio ativado. Altere em $wgEnableUploads para true.
 * 2) O tipo de arquivo deve ser permitido. Mais informações: $wgFileExtensions.
 * 3) O usuário tem que estar conectado no sitio. By default this is given to all logged-in users.

Imagens são enviadas com o Specialpage Upload.

'Veja: Manual:Configuring file uploads, Manual:Mime type detection

Parâmetros relevantes para a manipulação de imagens
Esses parâmetros são relevantes:



Thumb em imagens
MediaWiki's prorrogando a sintaxe permite que imagens sejam automaticamente 'miniaturizadas' (verManual:Configuring file uploadsgeral para ajudar no envio de arquivos).

Uma imagem com thumb exige o ImageMagick ou GD library. ImageMagick é recomendado, uma vez que produz uma melhor qualidade nos thumbnails; ele pode ser baixado a partir de imagemagick.org. GD is included in some versions of PHP, and it is recommended to use GD on Windows systems. GD podem ser descarregados a partir de libgd.org.

Para versões mais antigas do Mediawiki (antes da 1.10.0) definir: $wgUseImageResize para true para permitir thumbnailing. Em versões mais recentes isto não é necessário.

Se você utilizar o ImageMagick, definir $wgUseImageMagick como true em LocalSettings.php. Certifique-se de que o $wgImageMagickConvertCommand aponta para a variável (absoluta) localização do comando para converter a sua instalação e que o comando é executável pelo servidor. For example, Windows users will want to change the default to "C:\ImageMagick\convert.exe" (or similar).

To re-create old thumbnail files before you used ImageMagick you can use.

If rendering fails silently, check and increase.

GraphicsMagick can now also be used as an alternative to ImageMagick. You will need to set $wgImageMagickConvertCommand to the (absolute) location of the 'gm' command. E.g.:

$wgImageMagickConvertCommand = "/usr/bin/gm";

GIF
For thumbnailing GIF-Animations under windows, you need to install ImageMagick as described above.

SVG
MediaWiki suporta imagem em renderização SVG: se ativada, imagens em SVG podem ser usadas como outras imagem: eles serão automaticamente prestados como um PNG e miniaturizadas como necessária na mosca. If you're on a shared host and no SVG renderer is pre-installed, you should probably ask your provider to install it for you.

Para ativar o suporte a SVG:


 * 1) Para permitir o envio de arquivos SVG no LocalSettings.php file: $wgFileExtensions[] = 'svg'; Note que irá recusar MediaWiki SVG arquivos contendo JavaScript, por uma questão fundamental de segurança.
 * To avoid a false positive, add  to the  file.
 * 1) ːSe você receber uma mensagem de erro dizendo o arquivo está corrompido, certifique-se que o tipo de detecção está funcionando corretamente.
 * 2) Add   to  and set the renderer you want to use.
 * Available options are ImageMagick, ImagickExt , sodipodi , inkscape , batik , rsvg , and imgserv.
 * For example: $wgSVGConverter = 'ImageMagick';
 * 1) * If the converter program is not in the system path, you have to specify the directory that contains the program using ..
 * 2) * librsvg é muito preciso e rápido. Tem uma grande cadeia de dependências, de modo que você pode não querer se incomodar com isso, a menos que você tenha um repositório para inclui-la e resolver as dependências para você. Os projectos Wikimedia utilizam rsvg.
 * 3) * Batik é o mais preciso SVG renderizador disponível. Its SVG parsing is more strict, causing it to reject "almost valid" SVG files that other renderers accept (e.g. commons:File:UbuntuCoF.svg). Baseia-se no Java. Também é muito mais lento do que rsvg. Veja SVG benchmarks. See SVG benchmarks. Requires a lot of work to get running, if not included in your distribution.
 * 4) * Inkscape também faz um trabalho de SVGs preciso, a metade da velocidade de rsvg, mas foi projetado para uso interativo gráfico - ele exige um writable diretório home para o usuário que o executa. Uma vez que irá estar a ser executado como usuário www ou algo semelhante, que tentará criar .inkscape/ e .Gnome2/ diretórios na casa do correspondente diretório, e irá falhar silenciosamente se não for capaz de renderizar. Inkscape é preferível à rsvg (a) em Windows (que vem como um pacote autônomo) ou (b) se tiver importante SVGs traçada no Inkscape que não tornam corretamente em rsvg. Inkscape has as complicated a dependency chain as librsvg &mdash; use only if it's in your distribution or available as a complete standalone package.
 * 5) * Sodipodi é como programa de Inkscape. As mesmas considerações valem.
 * 6) * mageMagick converte SVGs. Também lento. Este é o padrão, mas evitá-lo, se possível. However, it does work. On Windows, $wgConvertPath must be set to avoid a conflict with Windows' own convert.exe. One simple alternative in this scenario is to add to LocalSettings.php the line , which also allows for spaces in the path.
 * 7) * The PHP Imagick extension supports SVG rendering, however the same considerations as for the regular ImageMagick apply.
 * 8) * The GD library is not capable of converting SVG images to the PNG format, at least according to Joen Asmussen's June 2008 NoScope blog.
 * 9) * A maioria dos navegadores da web atual salvo Internet Explorer pode exibir SVGs diretamente, mas imprecisamente rápido (cerca bem como ImageMagick). Usando librsvg para tornar SVGs a um PNG vai dar resultados mais precisos. Direct SVG display is not supported in MediaWiki by default, unless you install NativeSvgHandler extension.

Set $wgSVGConverter = false if SVG rendering is not needed and you wish to make your users download the svg file in order to view it.

JPEG (using GD)
Simply add the following line to LocalSetting.php, this will cause auto fall back to GD library.

For errors with JPEG thumbnails, see JPEG (using GD).

TIFF
Generating thumbnails of TIFF files requires MediaWiki 1.15.0 or newer.


 * 1) Allow upload of TIFF files in the LocalSettings.php file: $wgFileExtensions[] = 'tif';
 * 2) Add $wgTiffThumbnailType to LocalSettings.php and set to either jpg or png to specify which type of thumbnail you wish to have generated.
 * 3) Making thumbnails of TIFF files may require system resources beyond those needed for thumbnailing JPEG, GIF, or PNG files. Consider appropriate settings for $wgMaxImageArea</tt> and $wgMaxShellMemory</tt>

Apagando imagens
Imagens, como páginas wiki, só podem ser excluído por sysops (a menos que os direitos de usuários tenham sido alterados). Supressão de imagens é feita mediante a supressão da descrição associada na página (ou clicando no link "excluir em todas as versões").

Apagando um revisão individual
Se uma imagem tiver sido alterada, existe uma revisão da história da imagem, que é mostrada na página da imagem. Cada revisão tem um link "excluir". Se este for clicado, a revisão e os arquivos são excluídos permanentemente.

The versions of files are separate from the page history of the file description page.

Information about old revisions of files are stored in the table while information on old revisions of the pages are stored in the  table.

Restauro de imagens
Em versões anteriores ao MediaWiki versão 1,8, a opção de excluir imagens/arquivos não pode ser desfeita (apenas a descrição associados a página pode ser restaurada).

De MediaWiki versão 1,8 até 1,10, arquivos excluídos de imagens/arquivos (e, portanto, sua restauração) está desabilitado por padrão, mas pode ser ativada por definição em: $wgSaveDeletedFiles = true.

Desde MediaWiki versão 1,11, que é ativado por padrão, e $wgSaveDeletedFiles é desaprovado. Instead, the behavior is controlled by.

Informações sobre suprimido imagens são armazenadas no filearchive table.

Deletion of Archived Files
Since MediaWiki version 1.11, deleted images are still stored on the server by default. If you want to delete selected archived images, you can do so using the maintenance script. If you want to delete all of them completely, you can do that with the script. If you delete archived files, you can not undelete those files anymore.

Reasons for Deleting a File
When choosing to delete a file, as described above, users will be asked to provide a reason for deletion. The available reasons can be edited on the MediaWiki:Filedelete-reason-dropdown of your wiki.

Armazenamento de dados
Quando a imagem é carregada, várias coisas que são criadas:


 * 1) Um artigo no namespace imagem com o nome exato do arquivo, por exemplo, Imagem: MyPicture.png. Este artigo é armazenado e comporta-se como qualquer outro artigo.
 * 2) O próprio arquivo está armazenado em uma pasta do sistema de hospedagem (unix).
 * 3) Se o arquivo for maior do que 800px ou superior a 600px, de um polegar com tanto 800px largura ou altura 600px será criada. Cada polegar recebe a sua própria pasta com o nome da imagem original.

If is enabled (by default), MediaWiki creates several subdirectories in the images directory.

Xy são os dois primeiros caracteres do md5 hash da imagem final.

Pastas
All image files are stored in a folder determined by (, by default).

Descrição da/imagem subpastas:


 * Archive/0-f/x0-xf: Este é o lugar para o armazenamento de imagem original, que foram substituídas por versões mais recentes.
 * Temp/0-f/x0-xf: utilizado para fazer upload de imagem. Freqüentemente arquivos antigos continuam aqui. Deverão ser suprimidos regularmente (por razões de espaço). (Due to, these files may not always be automatically deleted)
 * Thumb/0-f/x0-xf: corresponde a 0-f: Miniaturas (gerado automaticamente), para as imagens em 0-f. Se estes se perder, eles são automaticamente regenerado.

Depending on the configuration, there may be additional image subfolders:
 * math: Folder to store your rendered TeX input, see also Manual:Enable TeX or Math.
 * x/xy: If  is set to true (which is the default), images will be stored in subfolders of the images, thus making file paths look like  . See  for more details on why this might be desired and how this system works.

Tabelas do banco de dados

 * O artigo Image:MyPicture.png: é armazenada como qualquer artigo na página, o texto, revisão etc
 * table image: Mantém alguns meta dados como o tamanho da imagem. Não contém o link para o arquivo. Este é provavelmente calculado pelo nome do arquivo e da razão pela qual não é possível mover artigos no namespace imagem.
 * table oldimage: Este é o arquivo de imagens que foram substituídos por versões mais recentes. Nota: Imagens excluídas não são armazenadas aqui, são excluídos permanentemente (ou, em versões mais recentes do MediaWiki, mudou-se para o filearchive).
 * table filearchive: detém a informação sobre as imagens apagadas.
 * table imagelinks: Mantém as informações no artigo de uma imagem que está sendo utilizada. (Isso poderia ter sido armazenado em pagelinks, mas alguém decidiu criar uma outra tabela.)

Espaço usado
Fotos necessitam consideravelmente mais espaço do que artigos. Os seguintes cálculos assumir um bloco de tamanho 4KB com Linux / Unix servidores.

A configuração padrão é $wgHashedUploadDirectory = true.

Necessidades de espaço para todos os diretórios:


 * Imagem diretórios: 0-f/x0-f: max. 16 * 16 = 256 diretórios = 256 * 4 KB = 1024 KB
 * Arquivo diretórios: 0-f/x0-f: max. 16 * 16 = 256 diretórios = 256 * 4 KB = 1024 KB
 * Polegar diretórios: 0-f/x0-f: max. 16 * 16 = 256 diretórios = 256 * 4 KB = 1024 KB
 * Temp diretórios: 0-f/x0-f: max. 16 * 16 = 256 diretórios = 256 * 4 KB = 1024 KB

Portanto, o montante de base do espaço necessário, sem qualquer imagens carregadas é de 4 MB.

Para cada foto que precisamos:
 * O tamanho do arquivo de imagem original + 2 KB média overhead

Para imagens com uma altura de mais de 600 pixels de largura ou mais de 800 pixels:
 * Tamanho da miniatura criado (s) + 2 KB média overhead (cada)
 * Diretório para miniatura (4KB) (cada um tem a sua própria imagem miniatura diretório)

Exemplos:
 * Imagem 20778 Byte png (pequena dimensão, não polegar): 24 KB para a imagem: Total 24 KB
 * Imagem jpeg 123,000 Byte (grande porte, auto polegar): 124 KB para a imagem, 4KB para o polegar diretório, 64 KB para o polegar: Total: 192 KB

Acesso aos arquivos
Os arquivos enviados são geralmente servidos diretamente pelo servidor, e não através do mediawiki. Embora possa haver um nível mínimo de segurança através da obscuridade caminho com criptografia (ex. /c/c4/...) veja $wgHashedUploadDirectory está definido, o caminho pode ser facilmente calculado a partir do arquivo Nome e não fornece proteção na verdade.

Limitar o acesso a usuários autorizados, ver Image Authorisation

Licença
Uma característica dos MediaWiki permite a Special:Upload Page para agilizar licenciamento de imagens. A página da Wikipedia's para envio de imagens tem um licenciamento com uma caixa abaixo do sumário da imagem. Este recurso está desativado no padrão MediaWiki. Para ativar esse recurso um sysop precisa editar Licenças no namespace MediaWiki. Exemplo: MediaWiki:Licenses S/he can do this by going to the MediaWiki:Licenses page of their wiki and clicking 'create' or 'edit'.

Licenças esperadas de um determinado formato em uma lista de wikis.

Linha 1 vai produzir "Licença de texto" e substituir a licença 1 modelo na imagem e transclude licença página 2.

Linha 2 irá mostrar uma acinzentado cabeçalho com o texto "Cabeçalho 1:"

Linha 3 irá produzir "Atribuição Compartilhamento 2,5" e transclude modelo cc-by-sa-2,5 na imagem page.

Para informações pormenorizadas do mundo real veja o exemplo, w:pt:MediaWiki:Licenses

Foreign Repositories
It is possible to access files stored in foreign repositories, without needing to upload them to the wiki, by setting the $wgForeignFileRepos array. This feature offers several possibilities:
 * ForeignAPIRepo accesses files from a remote MediaWiki installation, such as Wikimedia Commons, through its API
 * ForeignDBRepo accesses files through a database, and is useful for creating wiki families
 * FSRepo accesses files from a local folder

In all cases, one would be able to embed files into a page using ordinary image syntax and specifying the name of the file in the foreign repository. Note that some of the above implementations are still experimental, and might not be suitable for production sites.

Versão do MediaWiki
Isto aplica-se a:
 * MediaWiki 1.9.x e acima
 * Outras versões não foram confirmadas