Java 7 - Tempo demais por pouca coisa?

Assuntos Gerais
#81

[quote=marcobiscaro2112]Quanto ao método de compressão, o PNG usa uma derivação do LZ77:

[quote]5. Deflate/Inflate Compression

PNG compression method 0 (the only compression method presently
defined for PNG) specifies deflate/inflate compression with a 32K
sliding window. Deflate compression is an LZ77 derivative used in
zip, gzip, pkzip and related programs. Extensive research has been
done supporting its patent-free status. Portable C implementations
are freely available.[/quote]
Existem vários campos em uma imagem PNG, dentre os quais o IDAT se destaca (é nesse campo que fica os bits da imagem comprimida propriamente dita). A especificação desse campo:

Absolutamente nenhuma relação com imagens BMP ou DIF. Mais sobre o campo IDAT:

[quote]4.1.3. IDAT Image Data

     The IDAT chunk contains the actual image data.  To create this
     data:

         * Begin with image scanlines represented as described in
           Image layout (Section 2.3); the layout and total size of
           this raw data are determined by the fields of IHDR.
         * Filter the image data according to the filtering method
           specified by the IHDR chunk.  (Note that with filter
           method 0, the only one currently defined, this implies
           prepending a filter type byte to each scanline.)
         * Compress the filtered data using the compression method
           specified by the IHDR chunk.

     The IDAT chunk contains the output datastream of the
     compression algorithm.

     To read the image data, reverse this process.

     There can be multiple IDAT chunks; if so, they must appear
     consecutively with no other intervening chunks.  The compressed
     datastream is then the concatenation of the contents of all the
     IDAT chunks.  The encoder can divide the compressed datastream
     into IDAT chunks however it wishes.  (Multiple IDAT chunks are
     allowed so that encoders can work in a fixed amount of memory;
     typically the chunk size will correspond to the encoder's
     buffer size.) It is important to emphasize that IDAT chunk
     boundaries have no semantic significance and can occur at any
     point in the compressed datastream.  A PNG file in which each
     IDAT chunk contains only one data byte is legal, though
     remarkably wasteful of space.  (For that matter, zero-length
     IDAT chunks are legal, though even more wasteful.)

     See Filter Algorithms (Chapter 6) and Deflate/Inflate
     Compression (Chapter 5) for details.[/quote]

Referência completa: http://tools.ietf.org/html/rfc2083[/quote]

Vou perguntar de maneira diferente, já que você se recusa a ler o datasheet do bmp.
Porque png não tem nada haver com o bmp, já que ele é um método de compressão?
em qual formato de imagem a compressão png ou jpg deve ser aplicada?

#82

[quote=juliocbq]Vou perguntar de maneira diferente, já que você se recusa a ler o datasheet do bmp.
Porque png não tem nada haver com o bmp, já que ele é um método de compressão?
em qual formato de imagem a compressão png ou jpg deve ser aplicada? [/quote]
São casos diferentes. JPG é um método de compressão que é aplicado em alguma imagem. O PNG é um formato de imagem [color=red]que usa[/color] (usar um não quer dizer ser um) método de compressão (uma derivação do LZ77) sobre um mapa de pixels (armazenado no seu campo IDAT) que representa a imagem.

#83

[quote=marcobiscaro2112][quote=juliocbq]Vou perguntar de maneira diferente, já que você se recusa a ler o datasheet do bmp.
Porque png não tem nada haver com o bmp, já que ele é um método de compressão?
em qual formato de imagem a compressão png ou jpg deve ser aplicada? [/quote]
São casos diferentes. JPG é um método de compressão que é aplicado em alguma imagem. O PNG é um formato de imagem [color=red]que usa[/color] (usar um não quer dizer ser um) método de compressão (uma derivação do LZ77) sobre um mapa de pixels (armazenado no seu campo IDAT) que representa a imagem.[/quote]

Vou ser mais claro. Um arquivo png possui cabeçalhos diferentes de um bmp, assim como o jpg, mas a estutura de dados que guarda os bytes de informação dos pixels deve ser gerada através de um algoritmo de compressão, em bytes em estrutura não compactada, ou seja, um dib.

Experimenta passar um jpeg para um codificador de png, ou vice-versa e veja se funciona.

O JPEG, PNG, MNG, todos são métodos e algoritmos de compressão. Alguns são livres e outros pagos.

O livro do Gonzales é muito bom. Digital Image Processing 3ª ed.
Bibliografias:

#84

Uma correção sobre algo que eu disse: que JPG é um método de compressão. Na verdade JPG é um formato de imagem que define seu próprio algoritmo de compressão.

Não faz sentido dizer que o PNG é um algoritmo de compressão (seria como fazer um Pessoa extends Carro - só porque usa um não quer dizer que é um). Se PNG fosse um algoritmo de compressão, porque eu não poderia comprimir qualquer outro tipo de arquivo?

Perfeitamente.

Perfeitamente.

É aqui que discordamos. Um DIB é um formato de imagem proprietário. O que os formatos de imagem guardam são um Raster graphic, nesse caso, especificamente, é um Bitmap. Um Bitmap (ou pixmap) é exatamente o que você disse:

Ou seja, há um bitmap (ou pixmap) compactado (com um algoritmo diferente, dependendo do formato) dentro do campo de dados de cada formato de imagem, concorda comigo?

#85

O Java 7 vai ter suporte ao PNG e ao BMP?
Caso negativo, acho que a briga de ego de vcs dois já desvirtuou o tópico.

#86

[quote=marcobiscaro2112]Uma correção sobre algo que eu disse: que JPG é um método de compressão. Na verdade JPG é um formato de imagem que define seu próprio algoritmo de compressão.

Não faz sentido dizer que o PNG é um algoritmo de compressão (seria como fazer um Pessoa extends Carro - só porque usa um não quer dizer que é um). [/quote]

Exactamente.
Na realidade formatos de arquivo sempre definem 3 coisas: algoritmo de escrita, algoritmo de leitura e formato de arquivo. Os três estão interligados. PNG usa um algoritmo de compactação/descompactação nos algoritmos de I/O, não no arquivo em si.

JPEG é um formato que usa transformada de Fourier para “compressão”, já que a TF não é um algoritmo de compressão, mas é usado como um. O JPEG 2000 usa Transformada de Wavelets, muitos mais poderosa que a TF para processamento de imagem.

A imagem nem é sempre um array de matrizes de canais. Bitmap não é sinónimo de imagem, é sinonimo de “formato de representação” e não tem relação 1-1 com BMP ( BMP usa um bitmap, mas bitmap não é necessáriamente BMP). O contra-exemplo seria o SVG que não usa um mapa de bits e os algoritmos de escrita e leitura não são formas de compressão. Mas tudo são imagens.

GIF , JPEG , PNG , etc … são formatos de arquivo de imagem com seus algoritmos de leitura e escrita. Se esse algoritmo usa compressão isso é apenas um detalhe do padrão do arquivo, não da imagem.

A conversa saiu fora do ponto que era exemplificar que nem sempre coisas que existem ha mais tempo são melhores , nem isso significa que ficaram sendo usadas para sempre.

#87

[quote=clone_zealot]O Java 7 vai ter suporte ao PNG e ao BMP?
Caso negativo, acho que a briga de ego de vcs dois já desvirtuou o tópico.[/quote]
Deve ter suporte aos dois formatos sim, mas eu concordo com você. E agora com o complemento do sergiotaborda, creio que o assunto esteja encerrado. Voltemos ao Java 7. :slight_smile:

#88

[quote=marcobiscaro2112]Uma correção sobre algo que eu disse: que JPG é um método de compressão. Na verdade JPG é um formato de imagem que define seu próprio algoritmo de compressão.

Não faz sentido dizer que o PNG é um algoritmo de compressão (seria como fazer um Pessoa extends Carro - só porque usa um não quer dizer que é um). Se PNG fosse um algoritmo de compressão, porque eu não poderia comprimir qualquer outro tipo de arquivo?

Perfeitamente.

Perfeitamente.

É aqui que discordamos. Um DIB é um formato de imagem proprietário. O que os formatos de imagem guardam são um Raster graphic, nesse caso, especificamente, é um Bitmap. Um Bitmap (ou pixmap) é exatamente o que você disse:

Ou seja, há um bitmap (ou pixmap) compactado (com um algoritmo diferente, dependendo do formato) dentro do campo de dados de cada formato de imagem, concorda comigo?[/quote]

O bmp(dib) não é proprietário. É livre de patentes.

[quote]he simplicity of the BMP file format, and its widespread familiarity in Windows and elsewhere, as well as the fact that this format is relatively well documented and free of patents, makes it a very common format that image processing programs from many operating systems can read and write.
While most BMP files have a relatively large file size due to lack of any compression, many BMP files can be considerably compressed with lossless data compression algorithms such as ZIP (in rare cases of non-photographic data, up to 0.1% of original size) because they contain redundant data.[/quote]

O bmp é um formato livre de compressão, como já concordamos e padrão em sistemas win e os/2. Existem formatos de imagens proprietárias, como é o caso dos dispositivos de captura de vídeo, que eu trabalho aqui, e exigem decodificadores semelhantes ao png e ao jpeg.

Acho que a causa do nosso debate é simplesmente uma palavra. Codificação.

O que eu venho dizer com ela, é que, a codificação produz a estrutura de dados por traz dos arquivos. Um bmp pode conter um jpeg, para isso basta codificá-lo. Basta olhar a referência acima.

Com o png é a mesma coisa. Depois de codificado(O bitmap sem nenhuma compressão), torna-se uma imagem com formato png. Mas o responsável é o codificador. Não importa a procedência, para uma imagem nesses formatos, e imprecindível que haja sua original em estruturas livres de compressão.

Não confunda transformada de furrier com wavelets. Transformadas de furrier são usadas em análise de imagens no domínio da frequência. Wavelets são uma forma de transformada, com uso específico para compressão e não é nada mais poderosa que furrier. São apenas usadas em foco específico. o wavelet pode fazer análise no domínio do tempo. Furrier é muito melhor para análise de frequência.

Aqui tem exemplos com fontes em java.
http://homepages.inf.ed.ac.uk/rbf/HIPR2/tranops.htm

#89

Realmente os conceitos estão muito confusos ai …
O que pode estar nos dois é a imagem. A imagem contida no bmp pode estar contida no jpeg, mas dizer que o bmp está contido no jpeg ou vice-versa não faz sentido.

Acho que está confundindo bitmap com imagem. Como eu já falei, a imagem não tem que ser um mapa de bits.
O Java tem isto bem entendido. Image é abstracto. E RenderedImage é concreto. RenderedImage é produzida por um Raster que é o nome que o java dá aos leitores do tipo pixel por pixel. Outros tipos, que não os baseados em Rasters como o SVG são possiveis.

Imagens do memso tipo têm modelos compativeis o que permite diversas operações sobre a imagem ( não o formato) e este modelo não usa mapas de bits, ou melhor, devido ao encapsulamento não ha garantia que use.

O encoder e o decoder são tb separados, sendo possível ler e não escrever ou vice-versa.
Se é JPEG ou PNG depende do encoder/decoder escolhidos. Na memória nenhum desses formatos existe. Nem mesmo o bitmap.

E o nome é Fourier não Furrier(sic).

O que diz não é totalmente correto. Transformada de Wavlet tb é uma analise em espaço de freqüência, mas ela tem propriedades de escala que a de Fourier não tem. Isso é importante. quando vc tem um jpeg ( que usa uma trasnformada de Fourier) e faz um resize a imagem perde qualidade. Pq ? porque a TF não é invariante à escala da imagem e certa informação vai-se perdendo.
Com wavlets isso não acontece porque a TW é invariante à escala. Isso significa, por exemplo, que se vc tiver a imagem do cristo redentor de um helicóptero ou de um satélite tanto faz. Algoritmos de reconhecimento de imagem ( ou melhor, de match de imagem) usam esta propriedade abundantemente, é assim que monumentos são encontradas automáticamente em fotos de turistas. Portanto, TW não é apenas para compressão. é uma ferramenta de analise como a TF.

Qualquer uma das duas pode fazer analise em tempo ou espaço. A TF 2D usada em processamento de imagem é para espaço (imagems são informações de espaço). O foco não é especifico.

O formato JPeg 2000 usa wavlets ao contrario do formato JPEG normal que usa TF. O novo formato foi criado exactamente para resolver o problema de escala do jpeg normal. O fato do arquivo ficar menor é um detalhe, esse não é o objetivo.

Enfim, são duas ferramentas igualmente importantes em processamento de imagem e ambas têm várias utilizações além da compactação.

#90

[quote=sergiotaborda][quote=juliocbq]
Acho que a causa do nosso debate é simplesmente uma palavra. Codificação.

O que eu venho dizer com ela, é que, a codificação produz a estrutura de dados por traz dos arquivos. Um bmp pode conter um jpeg, para isso basta codificá-lo. Basta olhar a referência acima.
[/quote]

Realmente os conceitos estão muito confusos ai …
O que pode estar nos dois é a imagem. A imagem contida no bmp pode estar contida no jpeg, mas dizer que o bmp está contido no jpeg ou vice-versa não faz sentido.

Acho que está confundindo bitmap com imagem. Como eu já falei, a imagem não tem que ser um mapa de bits.
O Java tem isto bem entendido. Image é abstracto. E RenderedImage é concreto. RenderedImage é produzida por um Raster que é o nome que o java dá aos leitores do tipo pixel por pixel. Outros tipos, que não os baseados em Rasters como o SVG são possiveis.

Imagens do memso tipo têm modelos compativeis o que permite diversas operações sobre a imagem ( não o formato) e este modelo não usa mapas de bits, ou melhor, devido ao encapsulamento não ha garantia que use.

O encoder e o decoder são tb separados, sendo possível ler e não escrever ou vice-versa.
Se é JPEG ou PNG depende do encoder/decoder escolhidos. Na memória nenhum desses formatos existe. Nem mesmo o bitmap.

E o nome é Fourier não Furrier(sic).

O que diz não é totalmente correto. Transformada de Wavlet tb é uma analise em espaço de freqüência, mas ela tem propriedades de escala que a de Fourier não tem. Isso é importante. quando vc tem um jpeg ( que usa uma trasnformada de Fourier) e faz um resize a imagem perde qualidade. Pq ? porque a TF não é invariante à escala da imagem e certa informação vai-se perdendo.
Com wavlets isso não acontece porque a TW é invariante à escala. Isso significa, por exemplo, que se vc tiver a imagem do cristo redentor de um helicóptero ou de um satélite tanto faz. Algoritmos de reconhecimento de imagem ( ou melhor, de match de imagem) usam esta propriedade abundantemente, é assim que monumentos são encontradas automáticamente em fotos de turistas. Portanto, TW não é apenas para compressão. é uma ferramenta de analise como a TF.

Qualquer uma das duas pode fazer analise em tempo ou espaço. A TF 2D usada em processamento de imagem é para espaço (imagems são informações de espaço). O foco não é especifico.

O formato JPeg 2000 usa wavlets ao contrario do formato JPEG normal que usa TF. O novo formato foi criado exactamente para resolver o problema de escala do jpeg normal. O fato do arquivo ficar menor é um detalhe, esse não é o objetivo.

Enfim, são duas ferramentas igualmente importantes em processamento de imagem e ambas têm várias utilizações além da compactação.

[/quote]

[quote]Realmente os conceitos estão muito confusos ai …
O que pode estar nos dois é a imagem. A imagem contida no bmp pode estar contida no jpeg, mas dizer que o bmp está contido no jpeg ou vice-versa não faz sentido.[/quote]

Quando me referi a estrutura de dados, me referi aos bytes da imagem. Dizer que um bitmap está num jpeg faz todo o sentido, porque posso decodificar os bits de um jpeg e formar um novo bmp. Apesar de perder qualidade, como você disse acima.
Você não pode usar uma classe java para descrever o funcionamento de fundamentos de imagem digital, porque cada framework funciona de uma maneira determinada. Dá uma olhada na OpenCV.

[quote]Acho que está confundindo bitmap com imagem. Como eu já falei, a imagem não tem que ser um mapa de bits.
O Java tem isto bem entendido. Image é abstracto. E RenderedImage é concreto. RenderedImage é produzida por um Raster que é o nome que o java dá aos leitores do tipo pixel por pixel. Outros tipos, que não os baseados em Rasters como o SVG são possiveis[/quote]

Justamente o bitmap é o mapa de bits. Ele é a imagem. Ele é parte da estrutura de dados do arquivo. Arquivos de imagens são, cabeçalho e mapa de bits(Não importa a codificação ou tabela de cores que está usando). Mais uma vez, não pode se basear no framework para descrever fundamentos de imagens digitais. Precisa usar cálculo e álgebra linear.

[quote]E o nome é Fourier não Furrier(sic).

O que diz não é totalmente correto. Transformada de Wavlet tb é uma analise em espaço de freqüência, mas ela tem propriedades de escala que a de Fourier não tem. Isso é importante. quando vc tem um jpeg ( que usa uma trasnformada de Fourier) e faz um resize a imagem perde qualidade. Pq ? porque a TF não é invariante à escala da imagem e certa informação vai-se perdendo.
Com wavlets isso não acontece porque a TW é invariante à escala. Isso significa, por exemplo, que se vc tiver a imagem do cristo redentor de um helicóptero ou de um satélite tanto faz. Algoritmos de reconhecimento de imagem ( ou melhor, de match de imagem) usam esta propriedade abundantemente, é assim que monumentos são encontradas automáticamente em fotos de turistas. Portanto, TW não é apenas para compressão. é uma ferramenta de analise como a TF. [/quote]

Furrier é como se pronuncia. Furrier é utilizada em análise de frequências. Uma vez que se tem a frequência, pode-se trabalhar no tempo. Mas você estará extendendo a função. Então usa-se wavelets, que é proprio para isso.

Usa-se laplace, e não furrier, para analizar o diminio espacial.

#91

O fato é que no final, independente de API, formato de compactação, forma de codificação, etc. Um bitmap terá que ser obrigatoriamente gerado. Pelo menos, é assim que a placa de vídeo entende.

Não sei se o Sergio está falando de alguma API de mais alto nível, onde um Image poderia, por exemplo, conter apenas um conjunto de instruções opengl no seu interior.

Mas, ao se falar de manipulação de imagens por cálculo, nunca ouvi falar de uma forma de se transformar imagens sem antes reverter para seus bits.

Exceto no caso de imagens vetoriais, onde pode-se processar os vetores da imagem antes de envia-los para ser transformado em bitmap no vídeo.

#92

:shock: :shock: :shock: :shock: :shock: :shock:

Vc está equivocado. “frequencia” não implica em “tempo”. As distancias tb têm uma frequencia associada ( o seu inverso) A TF é utilizável com qualquer tipo de dimensão.

Vc está equivocado.
http://robotics.eecs.berkeley.edu/~sastry/ee20/vision2/node1.html#SECTION00010000000000000000
http://homepages.inf.ed.ac.uk/rbf/HIPR2/fourier.htm

A transformada de laplace é outra coisa ( muito usada para resolver equações diferenciais)
Acho que vc está confundindo com http://en.wikipedia.org/wiki/Discrete_Laplace_operator que se aplica pela convolução de um operador matricial com a imagem. a convolução por sua vez é um tipo de operações especial que envolve o uso da TF.

Eu já trabalhei com processamento de imagem e nunca vi ninguém se referir à imagem em memória como bitmap nem dizer que o bmp ( o formato) pode ser colocado dentro de jpeg( o formato) nem que o bitmap pode. diz-se que a imagem é convertida para o formato X. Ou que a representação em memória da imagem é convertida para o formato X. A representação da imagem na memória não tem que ser um bitmap (exemplo SVG). Isso que fique claro.

Acho que vc está um pouco confuso quanto aos termos e está confundindo todo o mundo e gastando o nosso tempo tentando explicar que vc está confundido.
Vamos esquecer este spinoff.

#93

[quote=sergiotaborda][quote=juliocbq]
Furrier é como se pronuncia.
[/quote]
:shock: :shock: :shock: :shock: :shock: :shock:

Vc está equivocado. “frequencia” não implica em “tempo”. As distancias tb têm uma frequencia associada ( o seu inverso) A TF é utilizável com qualquer tipo de dimensão.

Vc está equivocado.
http://robotics.eecs.berkeley.edu/~sastry/ee20/vision2/node1.html#SECTION00010000000000000000
http://homepages.inf.ed.ac.uk/rbf/HIPR2/fourier.htm

A transformada de laplace é outra coisa ( muito usada para resolver equações diferenciais)
Acho que vc está confundindo com http://en.wikipedia.org/wiki/Discrete_Laplace_operator que se aplica pela convolução de um operador matricial com a imagem. a convolução por sua vez é um tipo de operações especial que envolve o uso da TF.

Eu já trabalhei com processamento de imagem e nunca vi ninguém se referir à imagem em memória como bitmap nem dizer que o bmp ( o formato) pode ser colocado dentro de jpeg( o formato) nem que o bitmap pode. diz-se que a imagem é convertida para o formato X. Ou que a representação em memória da imagem é convertida para o formato X. A representação da imagem na memória não tem que ser um bitmap (exemplo SVG). Isso que fique claro.

Acho que vc está um pouco confuso quanto aos termos e está confundindo todo o mundo e gastando o nosso tempo tentando explicar que vc está confundido.
Vamos esquecer este spinoff.

[/quote]

Ow sergio, você é uma pessoa inteligente. Como frquência não implica em tempo?

Tempo = 1 / frequencia

ou

Frequencia = Velocidade da onda / largura da onda.

É calculo de física colegial.

Vc está equivocado. [url]http://robotics.eecs.berkeley.edu/~sastry/ee20/vision2/node1.html#SECTION00010000000000000000[/url] [url]http://homepages.inf.ed.ac.uk/rbf/HIPR2/fourier.htm[/url]

Não estou não. f(x,y) representa cordenadas espaciais da imagem digital.

essas cordenadas dizem respeito ao espaço da frequência da onda, e não da imagem
Laplace é usado em filtros do dmínio espacial, inclusive, um dos melhores isotrópicos possui seu nome.
http://homepages.inf.ed.ac.uk/rbf/HIPR2/log.htm

[quote]Eu já trabalhei com processamento de imagem e nunca vi ninguém se referir à imagem em memória como bitmap nem dizer que o bmp ( o formato) pode ser colocado dentro de jpeg( o formato) nem que o bitmap pode. diz-se que a imagem é convertida para o formato X. Ou que a representação em memória da imagem é convertida para o formato X. A representação da imagem na memória não tem que ser um bitmap (exemplo SVG). Isso que fique claro.

Acho que vc está um pouco confuso quanto aos termos e está confundindo todo o mundo e gastando o nosso tempo tentando explicar que vc está confundido.
Vamos esquecer este spinoff.[/quote]

Em quais projetos de imagem digital trabalhou? Vamos esquecer sim. Eu te passei todas as fontes que podia.

#94

A palavra “frequencia” sozinha, não implica nem espaço, nem tempo. Implica algo que se repete.
No tempo o que se repete é o periodo e a frequencia é o seu inverso. Normalmente a frequencia temporal é denotada pela letra f.
No espaço o que se repete é o comprimento de onda e a frequencia é o seu inverso. k é usado para esta frequencia.

Não velocidade envolvida neste conceito de frequencia.
A relação v = f/lambda pode-se escrever em termos de f e k, mas só se aplica a ondas. Isso leva aos conceitos de velocidade de grupo e velocidade de fase.

[/quote]

Não. Dizem respeito à frequencia espacial. Em duas dimensões usa-se u e v em vez de k.
Não ha ondas nesta historia.
Para a posição (x,y) do pixel ha uma frequencia (u,v) cuja relação é dada pela TF.

Se vc está pensando que a TF se aplica apenas a ondas vc está enganado. Ela se aplica a qualquer função.
Inclusive a funções como o delta de Dirac (que é infinito num ponto e zero no resto).

Filtros, não transformadas. Filtro de Laplace e Transformada de Laplace são coisas diferentes.

Em um projeto de visão assistida por computador para um projeto da ESA (agencia espacial europeia) que enviaria uma sonda a mercúrio usando esses sistema. Meu trabalho era encontrar métricas que pudessem comparar vários algoritmos de feature detection e depois qual deles era melhor na situação de movimento (em que ha uma sucessão de imagens e os pontos encontrados em uma têm que ser os mesmos que na seguinte).

#95

Ok Srs,

estava preferindo a discussão sobre Java 7, Flex e JavaFX do que sobre BPM. JPG e PNG.

Que tal voltarmos?

#96

[quote=andre_salvati]Ok Srs,

estava preferindo a discussão sobre Java 7, Flex e JavaFX do que sobre BPM. JPG e PNG.

Que tal voltarmos?[/quote]

O que é que ha para ainda falarmos sobre isso?

#97

[quote=sergiotaborda][quote=juliocbq]
Como frquência não implica em tempo?
[/quote]

A palavra “frequencia” sozinha, não implica nem espaço, nem tempo. Implica algo que se repete.
No tempo o que se repete é o periodo e a frequencia é o seu inverso. Normalmente a frequencia temporal é denotada pela letra f.
No espaço o que se repete é o comprimento de onda e a frequencia é o seu inverso. k é usado para esta frequencia.

Não velocidade envolvida neste conceito de frequencia.
A relação v = f/lambda pode-se escrever em termos de f e k, mas só se aplica a ondas. Isso leva aos conceitos de velocidade de grupo e velocidade de fase.

[/quote]

Não. Dizem respeito à frequencia espacial. Em duas dimensões usa-se u e v em vez de k.
Não ha ondas nesta historia.
Para a posição (x,y) do pixel ha uma frequencia (u,v) cuja relação é dada pela TF.

Se vc está pensando que a TF se aplica apenas a ondas vc está enganado. Ela se aplica a qualquer função.
Inclusive a funções como o delta de Dirac (que é infinito num ponto e zero no resto).

Filtros, não transformadas. Filtro de Laplace e Transformada de Laplace são coisas diferentes.

Em um projeto de visão assistida por computador para um projeto da ESA (agencia espacial europeia) que enviaria uma sonda a mercúrio usando esses sistema. Meu trabalho era encontrar métricas que pudessem comparar vários algoritmos de feature detection e depois qual deles era melhor na situação de movimento (em que ha uma sucessão de imagens e os pontos encontrados em uma têm que ser os mesmos que na seguinte).[/quote]

Muito bem sergio. Nosso debate percorreu desde estruturas de dados a transformadas e filtros. Tenho que concordar com você que transformadas são diferentes de filtros. Também trabalho com visão artificial e uso constantemente.

Agora, só me ajude a entender uma coisa nessa equação. Porque a frequência nela não tem relação com o tempo?

#98

[quote=sergiotaborda][quote=andre_salvati]Ok Srs,

estava preferindo a discussão sobre Java 7, Flex e JavaFX do que sobre BPM. JPG e PNG.

Que tal voltarmos?[/quote]

O que é que ha para ainda falarmos sobre isso?[/quote]

Se ainda há o que falar sobre Java 7, o tópico é este. Se o assunto não é esse, pq não abre outro tópico? Questão de organização… :wink:

#99

[quote=andre_salvati][quote=sergiotaborda][quote=andre_salvati]Ok Srs,

estava preferindo a discussão sobre Java 7, Flex e JavaFX do que sobre BPM. JPG e PNG.

Que tal voltarmos?[/quote]

O que é que ha para ainda falarmos sobre isso?[/quote]

Se ainda há o que falar sobre Java 7, o tópico é este. Se o assunto não é esse, pq não abre outro tópico? Questão de organização… :wink: [/quote]
Bom, talvez possamos fazer um append ao título do tópico. Algo tipo: - formatos e processamento de imagens. Seria uma boa fonte de referência. :slight_smile:

#100

Pessoal alguem sabe se já existe um link para download do Java 7?

Valeu :smiley: