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.

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:

batik, ersvg. Directa SVG exibição não é suportado em MediaWiki por omissão.
 * 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.
 * 1) ːPara evitar alguns enganos, definir $wgAllowTitlesInSVG = true;.
 * 1) ːSe você receber uma mensagem de erro dizendo o arquivo está corrompido, certifique-se que o tipo de detecção está funcionando corretamente.
 * 1) Altere $wgSVGConverter para o renderizador que pretende utilizar.
 * 1) ːOpções disponíveis são: ImageMagick,sodipodi,inkscape,
 * For example:
 * 1) * 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.
 * 2) * 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.
 * 3) * 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.
 * 4) * Sodipodi é como programa de Inkscape. As mesmas considerações valem.
 * 5) * 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.
 * 6) * The PHP Imagick extension supports SVG rendering, however the same considerations as for the regular ImageMagick apply.
 * 7) * 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.
 * 8) * 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.
 * 1) * 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.

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

Troubleshooting
If you see a blank square instead of SVG (Chrome) or no image at all (Firefox) and all PNG links lead to 404 error and you don't see any other error message anywhere please check variable. Setting it to false may make SVG transformation deferred always. Make sure that proc_open and symlink PHP methods are enabled (they may be disabled in php.ini for security or performance reasons).

JPEG (using GD)
Simply add the following line to LocalSettings.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:
 * 2) Add   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   and

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.

Informações sobre revisões de velhas imagens são armazenadas no oldimage table.

Restauro de imagens
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. Em vez disso, o comportamento é controlado por $wgFileStore.

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.
 * 1) O próprio arquivo está armazenado em uma pasta do sistema de hospedagem (unix).
 * 1) 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.

Estas subpastas será exibido apenas se você tiver $wgHashedUploadDirectory = true (padrão).

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

Pastas
Todos os arquivos gráficos são armazenados em uma pasta separada. Padrão é pathofwiki/images/x/xy/MyPicture.png. Veja $wgUploadPath para mais detalhes.

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). (Bug descrição: Quando você fazer o upload de uma foto, é armazenado na primeira temp e depois transferido. Se a imagem já existe, o usuário recebe um aviso . Se ele depois clicar em cancelar, o processo de carregamento é interrompido, mas a imagem permanece na pasta temp.)
 * 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