GT Turbo Posted March 9, 2006 Report Share Posted March 9, 2006 (VF par RaZ) Ils sont forts ces allemands, sérieux, ils déchirent, et quand ils codent, ils m'énervent, rapides, pointus, et touti quanti, j'ai les boules. D'autant plus quand ils pondent un codec de rien du tout en un rien de temps, compression par ondelettes que ça fait. Non, franchement, vous voulez faire quoi après ? Une remake de Pong !? Faut arreter... Chez Ray. [English]New dev tools are rare on our old machine, but when we've got one, we can appreciate that it got a high quality, that's the case of the new codec of Ray (Tscc) called BiQ. Now, Atari computers can use it but notice that the Jag support will be fastly added, Jag dev will appreciate Do you want it ? Go on Ray webpage Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted March 9, 2006 Report Share Posted March 9, 2006 (VF par RaZ)Je sais bien que GT a parfois des problèmes pour s'exprimer en français, mais si ç'en est au point que RaZ doive traduire... Bon, trêve de plaisanteries : tout d'abord, un à ray pour ce travail exemplaire (d'ailleurs, RaZ, faudrait ajouter un smiley qui applaudit, j'ai l'impression qu'on va en avoir besoin souvent ). Deuxième chose : si j'ai bien compris, l'algo de ray est optimisé pour une taille minimale et l'exécution sur 68000 (pas de multiplications, tout ça). La question que je me pose c'est : est-ce une bonne idée sur la Jag, sachant qu'on a un DSP qui permet justement de faire ce genre d'opérations ? Pure coïncidence, j'ai déniché avant-hier de la doc sur le JPEG et ses dérivés, et je pensais en faire (un jour ) une adaptation pour faire de la vidéo avec la JagCF. En bref, je me demande si la balance pencherait en la faveur de ce genre de méthodes sachant que les contraintes ne sont pas les mêmes que sur ST (je ne remets absolument pas en question le travail de ray, bien sûr). Qu'en pensez-vous ? (ray, en particulier) [English] First thing, a to ray for this amazing work (by the way, RaZ, you should add a clapping smiley, I've got the feeling we'll need it often ). Second thing : if I understood correctly, ray's algorithm is optimized for minimum size and execution on the 68000 (no multiplications, that kind of things). What I'm thinking is : is it a good idea on the Jaguar, since we have a DSP which can do such operations ? By sheer coincidence, I've found documentation about JPEG and its derivatives two days ago, and I thought about adapting it (one day ) to display video with the JagCF board. In a nutshell, I'm wondering whether it would be more interesting to use those methods since the constraints are different from the ST's ones (of course, I'm acknowledging ray's effort). What do you think of that ? (especially ray). Quote Link to comment Share on other sites More sharing options...
ray Posted March 10, 2006 Report Share Posted March 10, 2006 Second thing : if I understood correctly, ray's algorithm is optimized for minimum size and execution on the 68000 (no multiplications, that kind of things). What I'm thinking is : is it a good idea on the Jaguar, since we have a DSP which can do such operations ? By sheer coincidence, I've found documentation about JPEG and its derivatives two days ago, and I thought about adapting it (one day ) to display video with the JagCF board. In a nutshell, I'm wondering whether it would be more interesting to use those methods since the constraints are different from the ST's ones (of course, I'm acknowledging ray's effort). What do you think of that ? (especially ray). hi there zerosquare, using the DSP's/GPU's quick multiplication or multiply and accumulate instruction it might be feasible to improve BiQ's wavelet filters to use for instance daubechies or mexican hat wavelets instead of haar in the future which are known to produce lesser blocking artifacts. i still need to port the decoder to the GPU so we could think of that in the future but in general, BiQ is supposted to be all about small size which of course is an issue on the DSP/GPU, so i don't think the port of a simple JPEG decoder could be that. be=beat, sorry Quote Link to comment Share on other sites More sharing options...
Azrael Posted March 10, 2006 Report Share Posted March 10, 2006 j'ai déniché avant-hier de la doc sur le JPEG et ses dérivés, et je pensais en faire (un jour ) une adaptation pour faire de la vidéo avec la JagCF. En bref, je me demande si la balance pencherait en la faveur de ce genre de méthodes sachant que les contraintes ne sont pas les mêmes que sur ST Le DSP de la Jag est, comme il est dit dans la doc, spécialement (ou par chance ) fait pour décompresser le jpeg qui utilise une tranformée en cosinus. Suffit s'utiliser la fonction MMULT. Je ne connais pas l'algorithme de reconstruction des images par ondelettes (pas eu le temsp de voir le code source) Au fait, beau travail Ray ! [English] By sheer coincidence, I've found documentation about JPEG and its derivatives two days ago, and I thought about adapting it (one day ) to display video with the JagCF board. In a nutshell, I'm wondering whether it would be more interesting to use those methods since the constraints are different from the ST's ones The DSP of the Jag is especially (by good fortune) designed to uncompress jpeg format which uses a cosinus transform. This job fits to The MMULT instruction. I don't know the wavelet reconstructing algorithm (not enough time to read the source code) By the way, great job Ray ! Quote Link to comment Share on other sites More sharing options...
ray Posted March 10, 2006 Report Share Posted March 10, 2006 The DSP of the Jag is especially (by good fortune) designed to uncompress jpeg format which uses a cosinus transform. This job fits to The MMULT instruction. I don't know the wavelet reconstructing algorithm (not enough time to read the source code) ok, the DCT as well as the DWT (as used in BiQ) are ideally suited for implementation via MMULT and vice versa - i don't want to sound like a smartass, but it just so happens that matrix-multiply/multiply and accumulate operations are a natural thing in digital filtering and signal processing (which is a much wider range than just image encoding), so it's self-evident that DSPs (like the in in the jaggy) do have hardware-support for those - otherwise they wouldn't be called DSPs . ah and btw. azrael: the DWT is a very interesting topic to read into, and if you're already familiar with the DCT maybe you have a little advantage in understanding the filtering methods. By the way, great job Ray ! hehe, thanks. regards, ray arf, damn typos: like the in in the jaggy = like the one of the jaggy Quote Link to comment Share on other sites More sharing options...
Azrael Posted March 10, 2006 Report Share Posted March 10, 2006 so it's self-evident that DSPs do have hardware-support for those - otherwise they wouldn't be called DSPs . You're absolutely right. I'm not used to deal with signal processing at this moment (more 3D and fast calculation), so I forgot the first use of those little wafers. the DWT is a very interesting topic to read into, and if you're already familiar with the DCT maybe you have a little advantage in understanding the filtering methods. I am theoriticaly familiar with that technique, but never touched it. It's all kind of spectral decomposition (till now) Biq seems to be like JPEG2000. But now the next fashion method is strips (bandelettes in french) see http://www.letitwave.fr/index.php?rubrique=7+TECHNOLOGY Quote Link to comment Share on other sites More sharing options...
Recommended Posts