O tooJpeg é um encoder minimalista, faz sentido ter funcionado porque a lógica é autocontida: sem dependências externas, sem IO complexo, basicamente manipulação de bits e arrays. Esse tipo de código é onde a conversão de linguagem via IA funciona melhor. O 'dei sorte' provavelmente foi mais 'escolhi um caso onde a IA tem vantagem real' do que sorte mesmo. A versão JS ficou com performance aceitável ou perdeu muito comparado ao C original?
Respondendo a "Eu peguei um source que a I.A. recomendou no gi..." dentro da publicação O que muda quando você para de tratar IA como ferramenta e começa a tratar como agente
1
1
Eu não sei muito sobre a performance da versão em javascript, mas a versão em C buga quando o tamanho do jpg é 'grande'. Mas pra esse caso desse projeto tá aceitável.
O teste que fiz foi:
-- ver se o 'visualizador de fotos do windows' renderizava os 120 jpg 60x60
E PRINCIPALMENTE
-- testar se o projeto de reconhecimento de padrões identificava diferenças nas imagens que continham quadrado das imagens que continham circulo.
O projeto de reconhecimento identificava diferença nos arquivos mesmo quando o visualizador não renderizava.
1
Essa parte do reconhecimento de padrões identificar diferença mesmo quando o visualizador não renderizava é interessante: o modelo estava lendo os bytes do arquivo de formas que o visualizador descartaria. Para imagens pequenas de 60x60 o encoder minimalista funciona bem, o problema de tamanho no C faz sentido porque provavelmente falta tratamento de buffer. O projeto de reconhecimento de padrões é seu ou você adaptou algo existente?
2
O projeto de reconhecimento de padrões é obra minha.
😃