Até agora apenas a Seagate produzia SSDs para a Xbox. Mas agora a Western Digital vai entrar!
No futuro os possuidores de Xbox vão passar a ter novas opções de SSDs para quando pretenderem expandir o armazenamento da consola.
Se no caso da Sony a sua consola usa SSDs NVME standard, havendo apenas a limitação de estes cumprirem com determinadas performances, a MS optou por um sistema proprietário de SSDs em formato de “cartão”.
A utilização do SSD na Xbox acaba assim por ser mais simples pelo facto e este poder ser usado sem abrir a consola, mas, infelizmente, isso è conseguido à custa de um preço que se revela significativamente mais elevado.
Até ao momento apenas a Seagate disponibiliza estes cartões de expansão para a Xbox, e a preços estupidamente altos (o cartão de 2TB chega a custar 447 euros). Como comparação, um SSDs de 2TB PCIe 4.0 pode ser obtido por menos de 150 euros.
É nesse sentido que a concorrência é bem vinda. E ela vai existir, com com a chegada dos cartões de expansão da Xbox da Western Digital.
Infelizmente a WD não vai fazer milagres, mas mesmo assim pretende lançar a expansão de 1TB a um preço cerca de 40 euros abaixo do custo atual dos cartões da Seagate. Isso quer dizer que os SSDs continuarão a ser bastante caros, mas ao menos haverá concorrencia.
O series X como no ps5 dá pra levar bem sem o ssd. Mas o S é um produto praticamente morto. A ideia é tão ruim que nem lembrava. A única lógica é querer ganhar dinheiro, porque a justificativa de praticidade não cola.
OFF:
Como prometido, seguem mais análises de capturas com a ferramenta.
Primeiro um pouco de contexto.
1) Captura
Resolvi testar conteúdos em 4k 60fps e já tinha pesquisado que não é tarefa fácil capturar nessa taxa.
Meu PC quase fritou para efetuar essas capturas e eu ainda tive que usar a memória RAM como cache de HD, pois a taxa de transferência de dados é altíssima e meu ssd sata de 350 Mbps não aguentava.
O tamanho dos arquivos são grandes, cerca de 10GB de vídeos lossless por minuto capturado.
Mesmo assim, minhas capturas não ficaram perfeitas, aconteceram drops de frames.
Nos vídeos, de tempos em tempos, o FPS cai para 45 FPS, isso é devido a captura em si. O PS5 continuava a 60 fps.
Vou fazer mais ajustes e tentar ter taxas constantes de FPS na captura.
Foi utilizado o jogo Resident Evil 4 Remake – patch 1.02 – Playstation 5.
Foram duas capturas, a primeira foi utilizando modo performance com ray tracing ligado e modo ‘hair’ desligado, 4k 60 FPS.
A segunda foi modo resolução com ray tracing ligado e modo ‘hair’ desligado, 4k 60 FPS.
2) Análise dos resultados
a) No modo performance ( primeira parte do vídeo), analisando a contagem de pixels, vemos que o valor mais comum ( Moda ou Mode) é de 1932p.
Contudo, observe que não é um dado constante. As vezes a medição chega até 1080p.
Não sei dizer se realmente a contagem é 1080p ou se é algum ‘outlier’ ( se for o caso de outlier, pretendo implementar um recurso estatístico para eliminação desses).
Esse jogo é muito difícil fazer contagens manuais. Precisaria de um jogo sem tanto antialiasing ou efeitos de pós-processamento.
É curioso observar a diminuição da resolução quando aparecem vários inimigos, seria mesmo a resolução dinâmica em ação ou mera coincidência de erro do algoritmo?
Outra coisa muito interessante que eu custei a perceber é que a legenda do jogo afeta diretamente a contagem do algoritmo. Repare que exatamente no frame que ela aparece temos uma subida na contagem, as vezes para 1997p ou para 2059p. Até quando ela desaparece brevemente, temos um pico na contagem.
Pelo gráfico dá até para saber quando irá aparecer ou sumir uma legenda …
Não imagina que isso teria algum efeito, nas próximas capturas, irei retirar as legendas.
b) Já no modo resolução a situação fica bem mais caótica. A contagem fica muito irregular, o mais provável seria a contagem 2160p mas como eu estou forçando o algoritmo a obter uma resposta mais assertiva ( os mesmos parâmetros que foram usados no modo performance ), ele fica menos preciso, é curioso. Pois, uma coisa é o algoritmo adivinhar a resolução de uma imagem de 720p para 1080p, bem mais previsível, outra é adivinhar uma possível elevação de 2000p para 2160p, é um range bem mais apertado, desse modo mais difícil de ser mais assertivo. Como no anterior, temos vários outliers. Nesse modo a resolução mais comum parece ser por volta de 2100 ( se desprezar a interferência das legendas), que é praticamente 2160p ou 4k.
E as legendas nesse modo? Elas também afetam o algoritmo, mas de maneira diferente, elas abaixam, de modo geral, a contagem para 1997p ou 2059p.
Repare que bem no final do vídeo aparecem elementos de texto (“Mapa atualizado”), o que faz a resolução cair pra casa dos 1900p.
PS: Os vídeos compactados para subir no youtube sofreram diminuição para 1080p pois estava demorando muito o processamento, cada vídeo de 4k demorou 3h para ser processado pela ferramenta nessa resolução de saída de 1080p.
PS2: Por favor, não considerem que a contagem é bala de prata ou verdade absoluta, principalmente os resultados estranhos como as de resolução 1080p.
Link do vídeo:
https://youtu.be/ut40H5-C9VY
Hildo, uma sugestão, que pode não ser tão boa por você ter de fazer tudo em duas etapas, mas economiza em hardware pra parte da avaliação… Você poderia usar a captura em 4k apenas para efeitode contagem de pixels, e fazer uma captura a 720p apenas para frame time e fps… Mas se você achar que tem como melhorar a programa e não vai precisar ter de melhorar o computador pra fazer tudo de uma vez só, é melhor apenas ir melhorando ele mesmo ao invés de dar jeitinhos… Mas 4k@60 sem compressão é pesado mesmo.
E uma dúvida, as capturas feitas pelos próprios consoles são muito comprimidas?
Outra questão, sobre essa questão da resolução aumentar ou diminuir com as legendas, a contagem é feita apenas de determinada linha da tela tipo uma amostra de uma única linha de pixels horizontal e outra uma única linha de pixels vertical? Porque se sim, isso realmente explicaria a situação, sobretudo se as linhas de amostra passassem pelas legendas. De qualquer forma é só uma indagação de curiosidade. Pra ser mais preciso, o ideal era contar todas as linhas e colunas e fazer uma media de contagens de cada um desses eixos mesmo. Mas se for pra economizar em processamento, talvez pegar linhas menos próximas das legendas (mais ao extremos da tela) seria uma alternativa.
PS: desculpa aí se eu estiver falando alguma besteira já que estou fazendo algumas presunções de como o algorítimo possa estar a funcionar.
Eu posso tentar ajudar na captura e/ou processamento… O meu PC faz ambos na boa.
Agora não sei é como enviar-te os dados. Teriamos de ter uma plataforma de partilha.
Agradeço , seria uma boa ajuda. Mas realmente existe o problema de como compartilhar esse volume gigante.
Façam a captura normal com lossless e depois comprimam o arquivo do vídeo com um .7z, .rar ou .lha… O que tb permitiria fatiá-lo e serem mandados em partes Ou qualquer formato de supercompressão que seja mais eficiente para vídeos vp9 ou o formato que usarem. Criem um googledrive que suporta até 15GB grátis e mandem um pro outro. Seria minha sugestão.
Também andei lendo que mesmo formatos lossless tem perdas e penso que o ideal seria um app que rodasse em tempo real analisando a tela, mas sei que aí já soaria meio impossível! ? Sua técnica já parece muito surpreendente.
Acima de tudo tem de se analisar pequenos troços de vídeo. Se virmos um vídeo do NXG ou outro, eles apenas mostram alguns segundos onde mostram os fps…
De modo que num vídeo terá de ser mostrado sequências do jogo, mas apenas alguns minutos com os contadores ativos.
Assim isso implica que apenas esses minutos requerem processamento.
O vídeo deverá ter no início um disclaimer indicando sempre que a questão das resoluções é meramente indicativa e uma referência pela questão dos outliers.
É que o Tio Hildo havia referenciado que 1min de 4K iam pra cerca de 10GB, em lossless… Por isso sugeri as coisas acima. Mas concordo, é preciso pegar vários momentos do jogo pra uma amostragem mais justa e confiável.
Uma coisa também me veio a cabeça, em caso de VRS que pode ser mais agressivo no SX, o VRS reduz é resolução local ou apenas a geometria local? E se é a resolução, como funciona a contagem nesses casos ficaria como é recolhida ou escolhida a amostra, por exemplo?!?!
O VRS é outro impecilho… Com VRS a probabilidade de medires uma resolução inferior é grande. Isto porque visualmente o efeito é de quebra de resolução.
Então, outra variável que deve ser analisa. Eu nem tinha ideia que uma legenda poderia implicar na contagem.
Há muitos fatores.
Olha este exemplo tirado do Halo Infinite.
O VRS mostra-te zonas visualmente iguais a 720p mas numa resolução 4k.
É complexo
Caso a imagem não apareça, ela está aqui:
Ou só podem fazer um seed torrent e pronto.
é também podem!
É uma boa ideia. Não tinha pensado nisso.
A captura dos vídeo games são muito comprimidas, não tenho dúvida.
Sobre as legendas, eu acredito que elas fazem parte da imagem então acabam afetando como um todo.
Cara, que trabalho bacana feito por você. Parabéns!
Sobre os 1080p, pode ser outlier, como pode ser algo inerente à técnica de reconstrução específica que a Capcom utiliza (interlaced checkerboarding). Então a queda poderia ser um momento de transição, já que muitas dessas técnicas são temporais.
Então seria um caso de analisar manualmente esses outliers para entender melhor o que está acontecendo, para ver se descarta, ou se considera alguma nova situação na sua contagem.
Um bom case para você trabalhar seria Returnal no PS5, porque usa duas técnicas de reconstrução, uma sobrepondo a outra. Seria interessante de saber como a sua contagem de pixels vai se comportar neste caso, para que você cada vez mais ajuste seu software visando lidar com essas diferentes técnicas de upscalling/reconstrução.
ps: só para deixar claro, quando eu sugeri você colocar o fonte no GitHub, achei que você estava apenas fazendo de hobby, algo bem experimental mesmo, sem compromisso. Mas agora vendo que seu software está ganhando corpo, com potencial para se transformar em uma ferramenta profissional de análise, então esqueça o que eu disse haha sucesso!
Eu pensei em capturar o returnal, seria interessante ver o que acontece. TB concordo que seria interessante fazer medição manual e comparar.
Uma coisa que queria deixar claro, talvez eu tenha explicado mal. A ferramenta foi uma composição de vários bibliotecas para chegar ao resultado final. Estou usando python, matplotlib, opencv etc. Tentei reinventar o mínimo a roda. A parte de contagem de FPS eu que fiz minha implantação, deu trabalho demais.
Para a contagem de pixel eu estava pesquisando sobre o assunto e vendo como faria isso. Ao realizar as pesquisas eu achei uma lib que faz um teste pra ver se houve upscale em imagem. Então eu compilei esse código e vi seria perfeito pra o que eu estava querendo. Não quero tomar crédito do trabalho de ninguém, mas como é apenas um teste não revelei a origem da lib. Acho que o mais correto seria eu revelar a origem da lib. O objetivo é mais experimental mesmo. Se eu fosse fazer disso algo comercial, apesar que eu acho que ainda está muito longe, eu certamente teria que citar esse detalhe, ou então eu fazer a minha própria implementação.
Tu tens aqui um problema neste jogo.
É que de acordo com o NXGamer ele não trabalha em modo progressivo, mas interlaçado. Ou seja nenhuma das resoluções é P, mas sim I.
Então é um jogo com metade de resolução horizontal que se percebe a cada instante?!?! Ou é outro tipo de interpolação?
Agora isso explicaria em parte como a Capcom consegue um jogo com 4K@60 com RT!
Sim, eu reparei que ele tinha dito isso ontem e fiquei na dúvida. Mas esse interlaçado seria interno não? Pois o PS5 manda o sinal progressivo. Eu teria que estudar um pouco mais como seria um vídeo interlaçado sendo enviado em progressivo. Não sei como isso funciona.
Eventualmente sim. Reconstruído talvez.
Eu pesquisei aqui e entendi o tal do interlaçado. É que o re4 usa interlaced check boarding . Então a engine rendeniza o frame N-1 e o N com metade da resolução e junta os dois para mandar para a saída. Então a saída continua sendo progressiva, só a sua construção que a junção de dois frames interlaçado. Acho que é isso.
A saída é sempre progressiva.
No checkered board normal tu rendes pixel sim, pixel não e calculas o resto usando informação vetorial de movimento baseado nos últimos frames para preencher o resto.
No interlaçado, os fotogramas alternam entre os de linhas pares e os de linhas ímpares.
Eventualmente aqui misturas as duas coisas trabalhando com ainda mais informação vetorial e reconstruindo fotogramas checkeredboard interlaçados.
Bom dia…
dá uma vista de olhos neste código!
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
import javax.imageio.ImageIO;
import java.awt.image.BufferedImage;
public class ImageResolutionChecker {
public static void main(String[] args) { results = new ArrayList ();
File folder = new File(“frames”);
File[] listOfFiles = folder.listFiles();
List
for (File file : listOfFiles) {
if (file.isFile() && file.getName().endsWith(“.jpg”)) {
try {
BufferedImage image = ImageIO.read(file);
int nativeWidth = image.getWidth();
int nativeHeight = image.getHeight();
int finalWidth = Integer.parseInt(file.getName().split(“_”)[1]);
int finalHeight = Integer.parseInt(file.getName().split(“_”)[2].split(“.jpg”)[0]);
String technique = file.getName().split(“_”)[0];
String antialiasing = “”;
if (technique.equals(“fsr”)) {
antialiasing = “,Usou a técnica de anti-aliasing”;
}
String resolutionInfo = “”;
if (nativeWidth == finalWidth && nativeHeight == finalHeight) {
resolutionInfo = “,Resolução da imagem e nativa são iguais: ” + nativeWidth + “x” + nativeHeight;
} else {
resolutionInfo = “,Com resolução de ” + finalWidth + “x” + finalHeight + ” reconstruída a partir de ” + nativeWidth + “x” + nativeHeight;
}
results.add(file.getName() + resolutionInfo + antialiasing);
} catch (IOException e) {
e.printStackTrace();
}
}
}
try {
FileWriter writer = new FileWriter(“resolucoes.txt”);
for (String str : results) {
writer.write(str + “\n”);
}
writer.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
Ainda não o testei, ainda está em rascunho e por falta de tempo e por estar no escritório, não saiu sequer do papel (literalmente), pelo que pode ter algum tipo de erro, mas criei-o com a ideia de fazer o mesmo que o teu faz… A diferença está na saída que aqui é guardada num ficheiro TXT chamado resolucoes.txt, com o nome da imagem e os resultados da análise, por linha.
Aqui verifico a resolução original, se ela tem anti aliasing, e se é reconstruída usando resolução fixa ou dinâmica, usando FSR ou Checkerboard. Depois procedo a calcular a resolução nativa, e guardo os resultados num ficheiro.
Tenho outro código onde converto os ficheiros MP4 em JPGs guardados na pasta “frames”, guardados com nomes sequenciais, que depois são corridos aqui e é criado o ficheiro de texto que deverá apresentar a seguinte estrutura:
imagem1.jpg, com resolução de 3840×2160 reconstruída a partir de 1920×1080, usando a técnica de FSR
imagem2.jpg, com resolução nativa de 1920×1080
imagem3.jpg, com resolução de 2560×1400 reconstruída a partir de 2048×1120, usando a técnica de Checkerboard
Neste caso, testa-o se quiseres e compara os resultados com os teus. Requer a livraria ImageIO.
Nota. Acusa a leitura por favor, pois irei apagar este comentário assim que possível!
Eu li o código e compilei ele. Só não entendi muito bem o propósito. O código analisa a resolução da imagem baseado no nome do arquivo? É isso?
O código requer a livraria para funcionar. Ele lê a imagem e determina a resolução nativa da mesma após determinar o que lhe foi aplicado (anti aliasing, fsr ou checkerboard), gravando o resultado num ficheiro de texto. O nome da imagem não tem nada a ver!
Se funciona ou não depende das capacidades da livraria, mas pelo que li ela deveria ser capaz de fazer isso com este código. Mas como disse, não o experimentei pois não tenho o Java instalado no trabalho
E bolas ,ontem podia-o ter compilado e até testado quando cheguei a casa e esqueci-me completamente.
Se a livraria cria uma nova imagem do tipo “fsr_800_600.jpg”, esse código funciona. Mas o mais importante é a livraria que faz essa estimativa. Esse código é só classificar esses dados.
Hummm..
já percebi o que dizes…
Que tal assim?
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
import javax.imageio.ImageIO;
import java.awt.image.BufferedImage;
public class ImageResolutionChecker {
public static void main(String[] args) { results = new ArrayList ();
File folder = new File(“frames”);
File[] listOfFiles = folder.listFiles();
List
for (File file : listOfFiles) {
if (file.isFile() && file.getName().endsWith(“.jpg”)) {
try {
BufferedImage image = ImageIO.read(file);
int nativeWidth = image.getWidth();
int nativeHeight = image.getHeight();
String technique = file.getName().split(“_”)[0];
String antialiasing = “”;
if (technique.equals(“fsr”)) {
antialiasing = “,Usou a técnica de anti-aliasing”;
}
String resolutionInfo = “”;
if (nativeWidth == finalWidth && nativeHeight == finalHeight) {
resolutionInfo = “,Resolução da imagem e nativa são iguais: ” + nativeWidth + “x” + nativeHeight;
} else {
resolutionInfo = “,Com resolução de ” + nativeWidth + “x” + nativeHeight + ” reconstruída a partir de ” + finalWidth + “x” + finalHeight;
}
results.add(file.getName() + resolutionInfo + antialiasing);
} catch (IOException e) {
e.printStackTrace();
}
}
}
try {
FileWriter writer = new FileWriter(“resolucoes.txt”);
for (String str : results) {
writer.write(str + “\n”);
}
writer.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
Agora obtenho a resolução usando diretamente a largura e altura retornadas pelo método getWidth() e getHeight() e pelo BufferedImage
Tenho de passar a testar antes de te enviar… percebia logo os erros. A ideia inicial era gravar a informação obtida no nome da imagem e não no txt.
Estou a ver que se calhar este código não vai dar. Porque pelos vistos a livraria vai buscar à imagem os metadados necessários à determinação da sua resolução nativa…
E isso não está forçosamente presente. Aliás, nestas capturas nem sequer está presente. Pensei que a livraria funcionasse de outra forma e fizesse algum tipo de análise à imagem em si!
Nesse sentido, parece que é para esquecer!
Quem me falou desta livraria foi um amigo. Eu contei-lhe sobre o que estavas a fazer e ele disse-me que era fácil fazer isso usando está livraria.
O que ele não me disse é que ela é para imagens do Photoshop onde a resolução original é guardada nos metadados.
Ah entendi agora. Não vai ter o uso que queremos. Pois a captura não tem metadados.
Pois não… Os ficheiros MP4 tem e podiam ser passados para as imagens, mas isso também só se aplica se criados no premiere… Capturados na PS5 ou em outro local, não tem!
Fiz um teste rápido e realmente não funciona, segue evidência abaixo.
O problema é porque ele vai contar os pixels do output que é 4k, e não da quantidade de pixels que o render entrega.
Veja que tanto o modo performance quanto o modo resolução de RE 4 está retornando 4k, que é a resolução de output.
Infelizmente eu no trabalho não posso testar pois os computadores não permitem instalar nada sem autorização da informática, sendo que não tenho aqui o Java. E ontem passou-me o testar em casa!
Mas a partir do momento que a livraria se baseia nos metadados para obter a resolução nativa, que nestas imagens não existem, morre à partida!
Seja como for a resolução de output não seria forçosamente a mesma que a resolução nativa. A resolução nativa é calculada ao fazer a chamada aos métodos getWidth() e getHeight() da classae BufferedImage class, que lê a resolução intrínseca da imagem.
Depois ela é comparada com a resolução nativa que é guardada nas variaveis finalWidth e finalHeight. Caso não batam certas o programa deveria dizer que a imagem froi reconstruida e a partir de qual resolução.
O problema é que estes dados sobre a resolução nativa não são obtidos por análise, mas sim dos metadados, que neste tipo de imagens não estão presentes.
Por mera curiosidade, alguem conhece um compilador online?
Estou a usar este, mas dá problemas diversos.
Não é necessário. Se não tem permissão de instalar, tem a opção abaixo.
Baixe a openjdk da liberica no formato zip. Descompacte o zip e na pasta Bin tem o javac.exe e o java.exe.
Procura no Google: openjdk liberica
Tenho atualmente o código neste estado!
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.List;
import javax.imageio.ImageIO;
import java.awt.image.BufferedImage;
public class ImageResolutionChecker {
public static void main(String[] args) { results = new ArrayList ();
File folder = new File(“c:\\frames”);
File[] listOfFiles = folder.listFiles();
List
int finalWidth = 3840;
int finalHeight = 2160;
for (File file : listOfFiles) {
if (file.isFile() && file.getName().endsWith(“.jpg”)) {
try {
BufferedImage image = ImageIO.read(file);
int nativeWidth = image.getWidth();
int nativeHeight = image.getHeight();
String technique = file.getName().split(“_”)[0];
String antialiasing = “”;
if (technique.equals(“fsr”)) {
antialiasing = “,Usou a tecnica de anti-aliasing”;
}
String resolutionInfo = “”;
if (nativeWidth == finalWidth && nativeHeight == finalHeight) {
resolutionInfo = “,Resolucao da imagem e nativa sao iguais: ” + nativeWidth + “x” + nativeHeight;
} else {
resolutionInfo = “,Com resolucao de ” + nativeWidth + “x” + nativeHeight + ” reconstruida a partir de ” + finalWidth + “x” + finalHeight;
}
results.add(file.getName() + resolutionInfo + antialiasing);
} catch (IOException e) {
e.printStackTrace();
}
}
}
try {
FileWriter writer = new FileWriter(“resolucoes.txt”, false, StandardCharsets.UTF_8);
for (String str : results) {
writer.write(str + “\n”);
}
writer.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
Mas está-me ainda a dar um erro com a gravação do TXT…
Não é relevante pois isto não vai funcionar e não, mas sem compilar não posso ver…
ImageResolutionChecker.java:51: error: no suitable constructor found for FileWriter(String,boolean,Charset)
FileWriter writer = new FileWriter(“resolucoes.txt”, false, StandardCharsets.UTF_8);
^
constructor FileWriter.FileWriter(String,Charset,boolean) is not applicable
(argument mismatch; boolean cannot be converted to Charset)
constructor FileWriter.FileWriter(File,Charset,boolean) is not applicable
(argument mismatch; String cannot be converted to File)
Já me fartei de alterar essa linha, e nada…
Se for Java 11 , o construtor filwwriter recebe ( string filename, charset charset, booleand append)
Oi Mário, creio que este código não muda em relação ao que printei acima.
Veja que as variáveis nativeWidth e nativeHeidth vão sempre retornar a resolução de output como fiz no código que printei, e ao comparar com as constantes finalWidth e finalHeidth, o resultado vai ser sempre positivo caso o output seja 4k.
Também está printando que usou técnica de anti aliasing apenas se a pessoa escreveu isso no nome do arquivo, ou seja, alguém teve que colocar manualmente essa informação.
Eu acredito que o software do Tio Hildo está fazendo um tratamento de imagem, ou seja, pegando ponto a ponto da matriz e verificando as variações de cor.
Eu não corrigi essa parte. Nem olhei para ela. Apenas a parte da obtenção da informação nativa.
Mas é como disse, este código não serve pois ele não faz tratamento de imagem, mas obtem a info dos matadados.
E o que eu julgava que a biblioteca fazia era tratamento de imagem.
Mas só por curiosidade, meti o código no CHATGPT e pedi-lhe para me dizer se usando aquele código naquela livraria ele retornava sempre uma resolução nativa igual à da imagem, e a resposta foi que não!
Agora que sei que ele obtem os dados vindos dos metadados, o código que faria o inicialmente pretendido seria algo assim:
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.List;
import javax.imageio.ImageIO;
import javax.imageio.ImageReader;
import javax.imageio.stream.ImageInputStream;
public class ImageResolutionChecker {
public static void main(String[] args) { results = new ArrayList ();
File folder = new File(“c:\\frames”);
File[] listOfFiles = folder.listFiles();
List
int finalWidth = 3840;
int finalHeight = 2160;
for (File file : listOfFiles) {
if (file.isFile() && file.getName().endsWith(“.jpg”)) {
try {
ImageInputStream iis = ImageIO.createImageInputStream(file);
ImageReader reader = ImageIO.getImageReaders(iis).next();
reader.setInput(iis);
String imageType = reader.getFormatName();
int nativeWidth = reader.getWidth(0);
int nativeHeight = reader.getHeight(0);
String technique = file.getName().split(“_”)[0];
String antialiasing = “”;
if (technique.equals(“fsr”)) {
antialiasing = “,Usou a tecnica de anti-aliasing”;
}
String resolutionInfo = “”;
if (nativeWidth == finalWidth && nativeHeight == finalHeight) {
resolutionInfo = “,Resolucao da imagem e nativa sao iguais: ” + nativeWidth + “x” + nativeHeight;
} else {
resolutionInfo = “,Com resolucao de ” + nativeWidth + “x” + nativeHeight + ” reconstruida a partir de ” + finalWidth + “x” + finalHeight;
}
String colorProfile = reader.getStreamMetadata().getAsTree(“javax_imageio_1.0”).getChild(“Chroma”).getChild(“ColorSpaceType”).getAttribute(“name”);
String compressionType = reader.getStreamMetadata().getAsTree(“javax_imageio_jpeg_image_1.0”).getChild(“JPEGvariety”).getChild(“App0JFIF”).getAttribute(“extension”);
String pixelSize = reader.getStreamMetadata().getAsTree(“javax_imageio_1.0”).getChild(“Dimension”).getAttribute(“pixelSize”);
results.add(file.getName() + resolutionInfo + antialiasing + “,Tipo de imagem: ” + imageType + “,Perfil de cor: ” + colorProfile + “,Compressão: ” + compressionType + “,Tamanho do pixel: ” + pixelSize);
reader.dispose();
iis.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
try {
FileWriter writer = new FileWriter(“resolucoes.txt”, false);
for (String str : results) {
writer.write(str + “\n”);
}
writer.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
Mas isto não vale nada… pois os metadados não existem em capturas.
Nota que este código tem mais algumas coisas que antes. Isto porque talvez o venha a usar para outra coisa!
Agora que tenho o código a funcionar, arranjei um editor EXIF e meti metadata numa imagem, definindo as suas resoluções. E este método não está a conseguir ler corretamente os dados, pelo que os valores caem para os de defeito que são os 3840×2160.
Arranjei uma livraria externa ao java que lê esses dados, e estou a tentar corrigir (este código vai-me dar jeito para outra coisa pelo que o quero ver a funcionar), mas está-me a dar um erro ao compilar que não sei bem o que é pois é um erro que nunca vi antes!
Ok. tenho o código a correr sem erros… Isto apesar de não fazer nada do que esperava que fizesse…
Ele está-me efetivamente a dar que as imagens são 4K reconstruidas a partir de 4K. Mas isso deve-se ao facto de não haver metadados sobre a resolução nativa, e de a resolução 3840 por 2160 estar definida por defeito na inicialização das variáveis…
Pelo menos é o que me parece!
E o facto de a análise não ser precisa é normal dada a dificuldade da contagem. Mas a ferramenta já dá para se ter uma boa ideia do que ali está…
Agora como é que encontras boas amostras em todos os fotogramas?
Sua pergunta seria como fazer o algoritmo de contagem acertar sempre?
Creio que ele quis dizer no sentido de que se estamos lidando com resolução dinâmica, a tendência é que sempre existam outliers.
Os principais canais que fazem análises pegam algumas amostras e as analisam manualmente. Enquanto isso, seu software pega todos os quadros gerados por cerca de 2 minutos e os analisa automaticamente, gerando cerca de 6.000 quadros analisados (120 segundos com média de 50 quadros por segundo). Então seu software está muito mais propenso a encontrar outliers do que os canais de análise.
Os principais canais não mostram os outliers talvez por duas razões: 1) não encontram ou 2) descartam em virtude de ser uma única amostra diante de toda a amostragem.
Se bem que… eu já vi o Alex Battaglia mostrar outliers e usá-los como regra. Por exemplo, na demo de RE4, ele disse que o PS5 tinha contagem de 1440p no modo de performance, usando como base um único quadro, estando abaixo do Series X. Eu particularmente considero isso como desonestidade intelectual. Seria como eu argumentar que o Brasil jogou melhor do que a Alemanha no 7 x 1, usando como exemplo o único gol marcado pelo Oscar no final do jogo.
Pelo menos na minha área é permitido eliminar até 1~3% dos outliers, porque atrapalham e muito a amostragem. Por exemplo, eu já fiz análises de 500 mil classes Java, e umas 10 classes dessa amostragem possuíam mais de 20 mil linhas de código. Nesses casos é permitido excluir, porque elas não refletem a amostragem. Agora se fossem 10 mil classes com 20 mil linhas de código cada, aí sim é um número bastante representativo, logo não pode ser descartado.
Ah tá. Se a resolução é dinâmica, fica mesmo a questão se é outlier ou não. Mas se a resolução é fixa, aí os outliers ficam mais evidentes.
Acredito que um jogo com resolução fixa seja mais ideal para ajuste fino da ferramenta.
Sobre as contagens manuais, existe esse revés da pequena amostragem. Os canais não falam qual foi a amostragem feita, eu imagino que devem ser pouquíssimas, ainda mais comparado ao espaço ao todo, ainda mais que tem que analisar para vários consoles e várias configurações.
Isso, mas no caso da resolução fixa, teoricamente não deveriam nem existir outliers. Gran Turismo 7 é um exemplo, são 4k nativos fixos .. logo se eu encontrasse algo diferente disso em um quadro, imediatamente procuraria ver se não é uma falha no software que fez a contagem.
Sobre as contagens manuais, é por isso que eles pegam imagens de diferentes biomas do jogo, para pelo menos variar a amostragem. Em The Witcher 3, analisam ambientes fechados, abertos, as cavalgadas, momentos em que se está correndo.
Então, o problema é que o algoritmo é estatístico e uma heurística. Vai acontecer sem de vir outliers. Nesse caso, a solução seria descartar os outliers.
Esses resultados da análise do RE4 também são uma novidade pra mim. Pois só agora com a ferramenta pronta que tive todos os dados juntos para análise. Antes eu só pegava pequenas amostras. E no teste das capturas de switch, não mostrava muitos outliers, provavelmente por serem upscales mais agressivos, de 720 pra 1080p.
Assim, eu vejo que existe um bom potencial para a medição e evolução , mesmo que não seja perfeita, da para ter um panorama geral do comportamento.
Mas também não descarto o caso de as medições serem mais ruins do que boas e partir pra outra abordagem.
Eu acredito que esses sites mais conhecidos avaliam manualmente também para entender melhor que tipo de “truque” o estúdio está aplicando para o console alcançar a resolução target.
Em GT7 não tem truque nenhum, são 3840 × 2160 pixels saindo do render. Já Deathloop usa um FSR, Sackboy usa um TAA, RE 4 um interlaced checkerboarding, Spiderman usa temporal injection feito pela Insomniac, etc..
Gt7 seria um bom teste então …
Usa vídeos de jogos que tenhas e que já saibas qual a resolução mínima e máxima… E testa!
No fundo a questão pertinente é essa. Mas a realidade é que mesmo que faça contagem manual tenho de escolher imagens com superfícies retas inclinadas e nem sempre há boas amostras.
No teu vídeo vê-se que a ferramenta mede a resolução em todos os fotogramas, pelo que como é que isso acontece?
Analisas a imagem à procura de bons locais para amostragem? Tiras amostras em locais fixos? Como fazes?
E como garantir sempre que a amostra não é um outlier?
Nesse sentido elogio o que fizeste pois o sistema parece estar a funcionar mais ou menos, mas perceber o que questiono é relevante para se perceber o grau de fiabilidade que estamos a ter das leituras.
Pois é, essa é minha dúvida, se ele pega amostragem (tipo aleatória ou fixa) ou se realmente conta todos os pixels e faz uma média. Eu entedi que no processo ele captura cada frame 1 por um e faz a contagem e depois transforma a sequencia de frames num novo vídeo. Porém ainda não percebi se pra contar, por exemplo as linhas horizontais se ele conta os pontos de cada coluna e depois divide pelo número de colunas, ou se simplesmente escolhe uma coluna e conta apenas o número de ponto daquela coluna, por exemplo.
A contagem tem de ser feita em superfícies inclinadas. Basicamente medes o aliasing.
Imagina uma linha a 45 graus… Medes 30 pixels na vertical e medes quantas escadas tens. Neste caso terias 30 se a resolução for nativa, pelo que 1:1 face à resolução de saída.
Basicamente a ideia é esta. Se não tiveres 30 degraus em 30 pixels de altura, mas sim menos, verificas a proporção face à altura.
Imagina 20 degraus em 30 pixels de altura tens como resolução nativa 2/3 da resolução de saída.
A dificuldade de contar isto é que as reconstruções o Anti Aliasing, e mesmo o VRR, dificultam esta leitura e isso implica que encontrar uma boa amostra é primordial.
Daí que a contagem normalmente seja manual e em imagens selecionadas onde as superfícies retas inclinadas sejam visíveis.
Logo a questão que coloco é como é que o Tio Hildo consegue medir em todos os fotogramas e que tipo de amostras ele está a usar.
Nota que amostras fixas no ecrã não servem pois podes apanhar o HUD que normalmente está na resolução nativa…
Entendi, é uma triangulação e sempre vai ser por área de amostragem.
Concordo plenamente com você no sentido de ter certeza se a medição é correta ou não. Eu tenho essa preocupação. Por isso que mais testes são necessários e sempre deixei claro que é experimental. Como expliquei no comentário do Carlos acima, a contagem é feita por uma biblioteca de terceiros. Ela usa uma abordagem diferente de contagem de pixels manual tradicional com retas. Por isso, ela consegue fazer a contagem de qualquer imagem.
Na verdade, seria mais uma heurística, ela faz uma contagem que é aproximada e estatística, nesse caso então, podem acontecer erros.
Sobre a precisão , eu vejo que a contagem é mais precisa se o redimensionamento for maior, por exemplo, de 720 pra 1080. Para valores mais próximos da resolução final, fica mais difícil.
Vocês querem que eu explique como é feito?
Humm… Uma metodologia diferente.
Tens dados sobre como ela funciona?
E sim, se quiseres explicar pode ser que surjam ideias para discutirmos.
Só não partilhes é o teu código. Tenho muito respeito pelos direitos de autor.
Tenho como funciona em alto nível. É uma coisa bem avançada em análise de imagem.
Eu vou dar uma lida aqui e tento explicar com mais exatidão.
Já não era sem tempo de baratearem um pouco, expandir armazenamento muitas vezes é uma necessidade mesmo. Esse custo de armazenamento adicional seria o principal motivo pelo qual eu jamais optaria por um SS em detrimento de um SX se eu quisesse um Xbox. A única exceção possível seria a falta de dinheiro de imediato, mas acredito que logo me arrependeria de escolher um SS e não um SX.
e pensar que o xbox usa um SSD de 2.4GB/s, quando o xbox saiu já tinha SSD que entregava essa velocidade.
Mas pq vai fazer isso?
É só pagar uma noticia nos Astrotufing e deixar os seu fanboys babões ficarem ANOS na internet defendendo essa M
[img
[/img]