Google Diffusion Controller unifica o controle de imagens, mas seu maior teste vai além do Stable Diffusion

O Google apresentou o Diffusion Controller com um resultado marcante: uma configuração white-box alcançou uma taxa de vitória de 90% contra sua linha de base pré-treinada. O Google Diffusion Controller busca melhorar o alinhamento aos prompts sem sacrificar a qualidade visual já aprendida por um modelo de imagens. Sua principal mudança é surpreendentemente contida. Em vez de reconstruir o gerador, ele aprende uma correção menor que orienta o processo de remoção de ruído.

O trabalho questiona uma divisão conhecida na geração de imagens. Em geral, desenvolvedores escolhem entre a orientação aplicada durante a inferência e o fine-tuning que altera de forma mais permanente o comportamento do modelo. O Google argumenta que ambas as abordagens podem se encaixar em uma única estrutura de teoria de controle. Essa afirmação importa porque a estrutura também oferece suporte a uma configuração gray-box, na qual o modelo original permanece congelado.

A pressão recai mais diretamente sobre métodos de adaptação como o LoRA, que exigem algum acesso aos parâmetros internos de um modelo. Segundo relatos, o Diffusion Controller superou o LoRA em experimentos selecionados, apesar de operar com acesso mais restrito. Contudo, esses testes usaram o Stable Diffusion v1.4, e não os sistemas comerciais de imagem mais recentes. Portanto, a pesquisa estabelece um mecanismo interessante, não uma substituição consolidada para os pipelines de produção atuais.

Google Diffusion Controller transforma correções separadas em um único problema de controle

A principal mudança não é mais um truque de orientação, mas uma descrição matemática comum para várias formas de direcionar modelos de difusão.

O Google Research publicou sua explicação sobre o Diffusion Controller em 29 de setembro de 2026. O artigo subjacente apareceu no início de 2026 e foi aceito na 43ª Conferência Internacional sobre Machine Learning. Seus autores incluem pesquisadores do Google Research, do Google DeepMind e colaboradores acadêmicos.

Um modelo de difusão gera uma imagem ao converter repetidamente ruído aleatório em uma amostra estruturada. Cada etapa de remoção de ruído depende daquilo que o modelo considera uma imagem plausível. Condicionamento por texto e outros sinais influenciam essa trajetória, mas uma influência mais forte nem sempre produz um resultado melhor.

Considere um prompt que pede um lagarto usando óculos de sol. Um modelo pode criar um lagarto convincente, mas omitir os óculos. Uma orientação mais forte pode adicioná-los enquanto prejudica o rosto, as escamas ou as proporções do animal. O prompt se torna mais literal, enquanto a imagem se torna menos crível.

Essa tensão incentivou uma coleção de soluções especializadas. A orientação sem classificador altera a força do condicionamento durante a geração. Métodos de fine-tuning modificam o comportamento aprendido antes da inferência. Abordagens orientadas por recompensa treinam um modelo em direção a uma pontuação de preferência, enquanto adaptadores alteram um subconjunto limitado de seus cálculos.

A estrutura do Google trata esses métodos como operações de controle relacionadas. Ela modela a difusão reversa como um processo estocástico de controle apenas de estado. Em termos mais simples, cada estado de remoção de ruído passa a fazer parte de uma jornada cuja direção pode ser ajustada.

O modelo pré-treinado fornece a jornada padrão. Um controlador então altera a probabilidade dos possíveis próximos passos de acordo com uma recompensa-alvo. Uma penalidade de divergência limita o quanto o processo controlado se afasta do modelo original.

Essa combinação importa. A recompensa por si só pode incentivar uma otimização agressiva que explora um modelo de pontuação ou prejudica qualidades não relacionadas. A penalidade impõe um custo para abandonar a distribuição pré-treinada. Alinhamento e preservação passam a integrar o mesmo objetivo, em vez de serem correções separadas.

O artigo publicado sobre Diffusion Controller formaliza essa visão por meio de processos de decisão de Markov linearmente solucionáveis. Um LS-MDP é um modelo de controle cuja estrutura torna tratáveis etapas específicas de otimização. Os autores generalizam essa estrutura com diferentes medidas de divergência.

Esse enquadramento faz mais do que organizar a teoria. Ele produz objetivos concretos de treinamento para aprendizado supervisionado, regressão ponderada por recompensa e otimização por gradiente de política. Também leva à arquitetura de rede lateral que confere à pesquisa sua importância prática.

O resultado é uma única estrutura que abrange tanto a adaptação no treinamento quanto a força de controle em tempo de execução. Essa unificação é o evento que merece atenção. A arquitetura do controlador é seu primeiro caso de teste, não toda a extensão da ideia.

Por que o backbone congelado coloca métodos de adaptadores sob pressão

Um controlador útil permitiria que equipes personalizassem o comportamento de imagens sem obter permissão para reescrever o modelo inteiro.

A maioria dos métodos de adaptação pressupõe algum grau de acesso white-box. O acesso white-box significa que desenvolvedores podem inspecionar ou alterar pesos internos e cálculos intermediários. Essa premissa funciona para modelos distribuídos abertamente, mas deixa de valer quando provedores expõem apenas interfaces limitadas.

O LoRA reduz a carga do fine-tuning ao aprender atualizações de baixa dimensão para pesos selecionados do modelo. Os pesos originais podem permanecer congelados, mas o processo de treinamento ainda precisa acessar camadas relevantes. O método se popularizou porque seus adaptadores são menores do que cópias completas do modelo.

A pesquisa original sobre LoRA se concentrou em modelos de linguagem, mas a abordagem se disseminou amplamente pela geração de imagens. Artistas e desenvolvedores agora usam adaptadores para ensinar estilos, personagens, produtos e conceitos visuais. Esse ecossistema torna o LoRA um ponto de comparação importante.

O design gray-box do Google exige menos acesso interno. Um sistema gray-box expõe saídas intermediárias úteis, mas mantém indisponíveis os pesos do backbone. O Diffusion Controller observa uma média reversa intermediária e então prevê uma correção por meio de uma rede lateral separada.

A média reversa descreve para onde o processo pré-treinado espera que siga a próxima etapa de remoção de ruído. A rede lateral combina esse sinal com a imagem ruidosa atual e as informações de condicionamento. Sua saída altera a pontuação usada para orientar a etapa seguinte.

O backbone permanece congelado durante todo esse processo. Os desenvolvedores treinam o controlador em vez de editar o gerador original. No momento da inferência, o backbone e a rede lateral operam juntos.

Essa separação poderia mudar quem consegue personalizar um modelo. Uma empresa poderia receber acesso controlado a um backbone proprietário sem receber seus pesos. O provedor do modelo poderia proteger o ativo central enquanto expõe informação intermediária suficiente para adaptações aprovadas.

Isso não equivale a anexar um controlador a uma API pública comum de geração de imagens. O Google usa "gray-box" por um motivo. A abordagem ainda exige um sinal intermediário de remoção de ruído e uma forma de injetar a correção. Um serviço que oferece apenas prompts e imagens finalizadas não forneceria esse ponto de integração.

A distinção modera a linguagem do Google sobre compatibilidade com código fechado. O Diffusion Controller pode oferecer suporte a um modelo com acesso restrito cujo operador exponha a interface exigida. Ele não consegue acessar por conta própria qualquer endpoint comercial opaco.

Ainda assim, esse modelo de acesso pressiona os adaptadores convencionais. A vantagem de eficiência do LoRA se torna menos decisiva se uma rede externa menor consegue alcançar alinhamento comparável. Os fornecedores de modelos também ganham um possível meio-termo entre uma API bloqueada e a distribuição completa dos pesos.

O artigo avalia quatro configurações. O principal controlador gray-box usa a média reversa intermediária e um fluxo dedicado de adaptador lateral. Uma versão ingênua remove ambos os elementos arquiteturais. Duas variantes white-box treinam o controlador junto ao backbone, seja de forma conjunta ou separada.

Essas variantes permitem que os autores testem mais do que desempenho bruto. Eles examinam se a decomposição proposta importa, se a informação intermediária ajuda e se o acesso completo ao backbone agrega valor. Essa estrutura oferece aos experimentos um oponente mais claro do que um benchmark genérico de qualidade.

O oponente é a premissa de que uma personalização eficaz exige editar o próprio gerador. O Google Diffusion Controller não elimina esse caminho. Ele argumenta que uma correção separada pode capturar grande parte do comportamento necessário.

Como o Google Diffusion Controller orienta cada etapa de remoção de ruído

O controlador funciona porque a pontuação ótima se separa em uma linha de base pré-treinada e uma correção aprendida.

Uma pontuação de difusão estima a direção que move uma amostra ruidosa em direção a uma imagem limpa mais provável. O fine-tuning tradicional altera a rede que produz essa pontuação. O Diffusion Controller, em vez disso, representa a pontuação desejada como dois componentes.

O primeiro componente vem do modelo pré-treinado fixo. O segundo representa o sinal de controle necessário para um novo objetivo. Essa decomposição decorre das condições de otimalidade da estrutura, e não de um design arbitrário de adaptador.

O Google descreve a rede lateral como um amortecedor de direção. A analogia é útil se tratada com cuidado. Um amortecedor não substitui o motor de uma motocicleta, mas modera o movimento e melhora o controle. Da mesma forma, a rede lateral modifica a trajetória de geração sem reaprender o modelo-base.

O alvo pode representar alinhamento ao prompt, uma preferência artística ou outro resultado terminal mensurável. "Terminal" significa que a recompensa é calculada a partir da imagem concluída, e não de cada estado intermediário. O controlador precisa aprender quais correções anteriores tendem a produzir melhores resultados finais.

A estrutura oferece duas rotas baseadas em recompensa. A primeira usa um método de gradiente de política, incluindo uma versão baseada em otimização de política proximal. O PPO limita o tamanho das atualizações individuais da política, o que pode reduzir saltos desestabilizadores durante o treinamento.

A segunda usa perda ponderada por recompensa. Amostras que recebem recompensas maiores recebem mais peso durante o aprendizado. Na configuração de divergência de Kullback-Leibler do artigo, os autores derivam uma garantia de preservação do minimizador para o objetivo resultante.

Essa garantia é mais restrita do que uma promessa de imagens perfeitas. Ela diz respeito à relação entre objetivos matemáticos sob hipóteses declaradas. Não garante que um modelo de recompensa represente com precisão as preferências de todos os usuários.

O termo de divergência continua essencial. Uma f-divergência mede uma forma de diferença entre distribuições de probabilidade. Ao penalizar grandes desvios em relação ao processo reverso pré-treinado, o controlador precisa equilibrar a melhoria da recompensa com o desvio comportamental.

Esse equilíbrio aborda um problema conhecido na geração orientada. Um controle mais forte pode aumentar a adesão ao prompt enquanto reduz a variedade ou a plausibilidade visual. Um otimizador de preferências também pode descobrir atalhos que agradam seu avaliador sem satisfazer as pessoas.

A estrutura coloca esse conflito dentro do objetivo. Os desenvolvedores escolhem a recompensa e a força de regularização, em vez de combinar técnicas não relacionadas sem uma interpretação compartilhada. Isso não elimina o ajuste, mas esclarece o que o ajuste controla.

Um parâmetro separado de tempo de execução ajusta a força da orientação. Os usuários podem aumentar a influência do controlador para uma correspondência mais rigorosa com o alvo ou reduzi-la para permanecer mais próximos da linha de base. Não é necessário retreinamento para cada configuração.

Isso se assemelha à flexibilidade que tornou a classifier-free guidance amplamente útil. A classifier-free guidance combina previsões condicionais e incondicionais durante a amostragem. Sua escala de guidance oferece controle direto sobre a intensidade do condicionamento por texto.

O Diffusion Controller tem uma ambição mais ampla. Ele aprende uma correção para um objetivo especificado e, em seguida, expõe a intensidade dessa correção em tempo de execução. O alinhamento ao texto é um objetivo possível, mas a formulação matemática não se limita ao texto.

Essa distinção explica por que o Google apresenta o trabalho como uma estrutura unificadora. A proposta conecta controle de inferência, fine-tuning supervisionado, aprendizado ponderado por recompensa e gradientes de política. Cada um se torna uma expressão diferente de movimento controlado em torno de um processo pré-treinado.

A arquitetura também pode isolar mudanças futuras. As equipes poderiam preservar uma base validada enquanto substituem controladores para diferentes domínios ou políticas. Essa modularidade ajudaria nos testes porque o componente alterado permanece identificável.

No entanto, a modularidade também transfere a responsabilidade para a recompensa e o controlador. Um alvo mal projetado ainda pode produzir comportamentos indesejáveis. Uma base congelada impede algumas formas de desvio, mas não torna correto o objetivo de controle adicionado.

Os ganhos relatados são relevantes, mas o benchmark é limitado

Os resultados do Google sustentam o mecanismo, mas não estabelecem desempenho em geradores modernos e proprietários de imagens.

A equipe avaliou o Diffusion Controller com o Stable Diffusion v1.4. Esse modelo fornece uma base de pesquisa reconhecível e reproduzível, mas pertence a uma geração anterior de sistemas de texto para imagem. Produtos atuais usam arquiteturas, conjuntos de dados, pipelines de condicionamento e camadas de segurança diferentes.

Os testes cobriram três regimes de treinamento: fine-tuning supervisionado, perda ponderada por recompensa e PPO. Os pesquisadores mediram o alinhamento de preferências com o HPS-v2, um sistema de pontuação aprendido para qualidade de imagem e preferência por prompts. Eles também realizaram avaliações humanas.

Segundo o Google, o controlador gray-box superou o LoRA nas taxas de vitória do HPS-v2 durante o treinamento supervisionado e ponderado por recompensa. Essa comparação é relevante porque o LoRA recebeu acesso white-box, enquanto o controlador usou a configuração gray-box restrita.

O artigo também compara o controlador proposto com sua variante gray-box ingênua. Essa ablação testa se a média reversa intermediária e o fluxo do adaptador lateral contribuem com informações úteis. Sem essa comparação, qualquer ganho poderia simplesmente refletir capacidade treinável adicional.

O Google afirma que sua configuração white-box alcançou uma taxa de vitória de 90% contra a base pré-treinada. Uma taxa de vitória registra a frequência com que a saída de um sistema é preferida em comparações pareadas. Isso não significa que cada imagem melhorou em 90%.

A escolha da base também importa. Superar um modelo Stable Diffusion v1.4 não adaptado em geração alinhada a preferências é diferente de superar um modelo de produção atual. O resultado demonstra que a otimização alterou as preferências avaliadas sob as condições de teste.

O próprio HPS-v2 é um avaliador baseado em modelo, treinado para refletir preferências humanas. O benchmark de preferências associado buscou melhorar a medição de alinhamento entre prompts e estilos. Como toda métrica aprendida, ele captura apenas parte do julgamento visual subjetivo.

A otimização em relação a essa pontuação pode criar dependência do avaliador. Um método pode se tornar particularmente bom em produzir características recompensadas pelo HPS-v2. Uma avaliação humana separada ajuda, mas sua força depende do tamanho do painel, da cobertura de prompts, do desenho das comparações e da diversidade dos avaliadores.

O blog do Google afirma que o controlador registrou os melhores resultados de qualidade subjetiva e correspondência com prompts em prompts complexos e com múltiplos atributos. O resumo público não transforma esses experimentos em evidência universal. Os resultados em retratos, tipografia, raciocínio espacial ou conceitos culturais pouco familiares podem ser diferentes.

A formulação mais enfática da empresa também merece cautela. O blog diz que o controlador pode personalizar modelos rigidamente bloqueados sem tocar no código subjacente. Na prática, o operador do modelo precisa expor o sinal intermediário necessário e aceitar a correção injetada.

Isso representa mais acesso do que muitas APIs hospedadas de imagem oferecem. Um desenvolvedor não pode presumir que um provedor comercial existente dará suporte à arquitetura. A implantação, portanto, depende de interfaces técnicas e incentivos dos fornecedores, não apenas da matemática.

A sobrecarga computacional continua sendo outra questão em aberto para equipes de produção. Uma rede lateral é descrita como leve, mas ainda é executada junto à base. Latência, consumo de memória, eficiência de batching e utilização de aceleradores determinam se essa sobrecarga é aceitável.

O resumo da pesquisa enfatiza eficiência de parâmetros, e não o custo abrangente de serving. Menos parâmetros treináveis podem reduzir os requisitos de armazenamento para treinamento e otimização. Isso não produz automaticamente uma geração de imagens mais rápida.

Os experimentos com Stable Diffusion v1.4 também deixam em aberto a transferência entre arquiteturas. Um controlador comprovado em uma base de difusão latente pode exigir alterações para sistemas de imagem baseados fortemente em transformers. Vídeo acrescenta consistência temporal, trajetórias mais longas e demandas computacionais muito maiores.

Essas limitações não anulam a contribuição. Elas definem o limite do que foi demonstrado. Atualmente, o Google Diffusion Controller oferece evidências de um método de adaptação fundamentado em uma plataforma de pesquisa controlada.

A disputa maior é o acesso ao modelo, não apenas a qualidade da imagem

O Diffusion Controller importa mais se os provedores de modelos adotarem uma camada intermediária entre APIs fechadas e pesos disponíveis para download.

O controle de geração de imagens já inclui diversas rotas concorrentes. A engenharia de prompts altera a entrada. A classifier-free guidance altera a intensidade do condicionamento. O fine-tuning altera o comportamento, enquanto adaptadores limitam o número de parâmetros modificados.

O ControlNet introduziu outro padrão influente. Ele adiciona ramificações treináveis a um modelo de difusão congelado e aceita condições estruturais como bordas, poses ou mapas de profundidade. A arquitetura ControlNet mostrou como uma rede auxiliar poderia adicionar controle sem descartar capacidades pré-treinadas.

O Diffusion Controller compartilha o impulso de preservar uma base e adicionar computação especializada. No entanto, sua contribuição principal é diferente. O ControlNet se concentra no condicionamento espacial, enquanto o Diffusion Controller deriva uma correção geral a partir de uma formulação de controle ótimo.

O fine-tuning de difusão baseado em recompensa apresenta uma segunda comparação. Esses métodos otimizam amostras geradas em relação a recompensas de preferência ou de tarefa. Eles podem melhorar o alinhamento, mas seus algoritmos frequentemente vêm da prática de aprendizado por reforço, e não de uma teoria de controle específica para difusão.

A estrutura do Google tenta conectar essas rotas. Gradientes de política e regressão ponderada por recompensa emergem do mesmo processo reverso controlado. A rede lateral segue da mesma decomposição.

A questão comercial é se essa elegância produz um contrato de acesso útil. Provedores de modelos fechados normalmente expõem endpoints simples porque endpoints simples protegem propriedade intelectual e reduzem riscos operacionais. Ativações intermediárias criam novas obrigações de segurança, compatibilidade e suporte.

Um provedor precisaria definir qual saída de denoising permanece estável entre versões do modelo. Também precisaria validar controladores treinados por clientes. Controladores maliciosos ou pouco testados poderiam enfraquecer sistemas de segurança ou gerar conteúdo proibido.

A estrutura também poderia apoiar controles de segurança mais fortes. O Google identifica a mitigação de segurança como uma direção futura. Um controlador treinado para conformidade com políticas poderia operar separadamente da base criativa e receber atualizações independentes.

No entanto, a mesma separação cria conflito entre controladores. Um controlador de personalização, um controlador de estilo de marca e um controlador de segurança poderiam solicitar mudanças diferentes na trajetória. Sua combinação exigiria arbitragem, testes e regras claras de precedência.

A intensidade de guidance em tempo de execução introduz outro problema de governança. Um controle ajustável pelo usuário pode ser valioso para a criatividade, mas restrições de segurança nem sempre podem ser opcionais. Sistemas de produção precisam distinguir preferências que os usuários podem ajustar de proteções que eles não podem desativar.

Os fornecedores de modelos, portanto, enfrentam uma troca. Expor controle gray-box poderia atrair personalização empresarial que APIs fechadas atualmente têm dificuldade de oferecer. A mesma interface poderia ampliar superfícies de ataque e complicar garantias de serviço.

Ecossistemas de pesos abertos enfrentam um cálculo diferente. Seus usuários já possuem acesso white-box, de modo que a compatibilidade gray-box oferece menos valor estratégico. Eles ainda podem adotar a estrutura porque sua decomposição, controle em tempo de execução ou eficiência de parâmetros apresenta melhor desempenho.

O LoRA não desaparecerá apenas porque um estudo relata resultados de preferência mais fortes. Ele dispõe de ferramentas maduras, amplo apoio da comunidade, arquivos compactos e fluxos de implantação conhecidos. Um substituto precisa competir com esse ecossistema completo.

O Diffusion Controller pode, em vez disso, se tornar outra camada da pilha. As equipes poderiam usar LoRA para conceitos que exigem adaptação no nível dos pesos e um controlador para direcionamento orientado por recompensa. A teoria unificada não força todos os casos de uso a uma única implementação.

É por isso que a pesquisa não deve ser apresentada como uma simples derrota do LoRA. A disputa mais profunda diz respeito a quem controla as interfaces de adaptação. Se os provedores expuserem estados intermediários úteis, controladores separados se tornam comercialmente plausíveis. Se mantiverem APIs apenas de prompts, o acesso white-box e o ajuste gerenciado pelo provedor continuarão dominantes.

Três sinais mostrarão se a estrutura se sustenta

O próximo teste é verificar se equipes independentes conseguem reproduzir os ganhos, transferi-los para modelos mais novos e implantá-los a um custo aceitável.

O primeiro sinal é a reprodução independente. Pesquisadores precisam repetir as comparações com Stable Diffusion v1.4 usando prompts, recompensas, checkpoints e procedimentos de avaliação idênticos. A reprodução fortaleceria a confiança de que os ganhos vêm da arquitetura do controlador, e não de detalhes de implementação.

Uma avaliação humana mais ampla faz parte desse teste. Os painéis devem abranger tipografia, mãos, relações espaciais, estilos pouco familiares e composição com múltiplos sujeitos. Também devem incluir prompts em que um forte alinhamento entra em conflito com a estética.

Se estudos independentes reproduzirem a vantagem relatada, a alegação central da estrutura se torna mais forte. Se os resultados variarem substancialmente entre avaliadores, sua aparente liderança poderá depender do HPS-v2 ou da distribuição de prompts selecionada.

O segundo sinal é a transferência para arquiteturas mais novas. O Stable Diffusion v1.4 é um laboratório útil, mas não pode representar todo o mercado de imagens de 2026. Pesquisadores devem testar bases abertas mais robustas e sistemas que utilizem arquiteturas de denoising diferentes.

A configuração gray-box merece atenção especial. Uma demonstração convincente manteria uma base moderna congelada, exporia apenas informações intermediárias limitadas e ainda superaria um adaptador bem ajustado. Esse resultado sustentaria a vantagem de acesso prometida.

Uma falha de transferência não invalidaria a teoria de controle, mas reduziria a utilidade imediata da arquitetura. A rede lateral pode depender de sinais fáceis de expor em um modelo e difíceis de usar em outro.

O terceiro sinal é uma interface de qualidade para produção. Provedores de modelos ou projetos de código aberto precisam especificar como os controladores se conectam, treinam, são versionados e executados. Benchmarks devem relatar latência, memória, throughput e tamanho do controlador ao lado das pontuações de preferência.

A compatibilidade entre atualizações de modelos será crucial. Um controlador treinado com base em um checkpoint pode falhar quando o backbone muda. Os fornecedores precisam decidir se os estados intermediários constituem um contrato suportado ou se permanecem como detalhes de implementação.

Os testes de segurança pertencem à mesma interface. Um fornecedor precisa saber se um controlador externo pode contornar filtros de conteúdo, vazar o comportamento do modelo ou amplificar conceitos nocivos. Clientes empresariais também exigirão trilhas de auditoria e reversão previsível.

Uma implantação bem-sucedida reforçaria a visão mais ampla do Google: o controle pode existir fora do gerador central sem perder eficácia. Uma integração cara ou frágil enfraqueceria o argumento prático, mesmo que a matemática continue sólida.

Portanto, os desenvolvedores devem interpretar o Google Diffusion Controller como uma proposta de design com suporte experimental convincente. Ele oferece uma forma mais clara de raciocinar sobre alinhamento, preservação e acesso à adaptação. Ainda não resolve qual controlador pertence a um sistema de imagens em produção.

O próximo passo mais útil é avaliar o framework diante de uma necessidade real de personalização. Escolha uma meta mensurável, preserve uma linha de base intocada e compare a aderência ao prompt, a qualidade das imagens, a diversidade e o custo de servir. Em seguida, teste se um único controle em tempo de execução consegue navegar por esses objetivos concorrentes.

Essas evidências determinarão se o Diffusion Controller se tornará uma camada geral de adaptação ou continuará sendo um resultado de pesquisa elegante. A teoria unifica várias técnicas antes separadas. A adoção agora depende de interfaces, replicação e resultados que vão além de um único backbone em envelhecimento.