Quote:
Originally Posted by Thorham
Now that's a very good idea, meynaf. Can't wait to try it! Of course I'm going to try it in freebasic first  (more convenient because of easy to use gfx functions which all just work in 24bit). |
You could do it right in asm, because else it's already done. Look in jdcolor.c to see how.
I tried this already, but it was quite deceiving. I ran into a lot of bugs (you can't imagine the -ahem- beautiful images I've seen) and it didn't give a good speed gain. Too many tables to peek (4), 3 data sources for 1 destination -> too many address registers used -> too much swapping. Gosh !
Maybe you'll be more lucky if you give it a try...
Quote:
Originally Posted by Thorham
True, but it also applies to gray scale: The more visible detail the less compression.
|
Of course.
Quote:
Originally Posted by Thorham
That's true. There is a problem with this, though. I've tried (in freebasic, what else ) scaling the color information by 50%x50%, then, even with interpolation, the final rendered image is not as good as the original because aliasing is introduced. Could be fixed by somehow not scaling the whole image, just parts of it. And, of course, my interpolation algorithm isn't the best, although it does yield better results then none at all. |
You're doing here something jpeg already does. They're using a triangle filter for upsampling, maybe you can try that too (look in jdsample.c for more info).
I'm more interested in lossless compression, though. What if you could predict what the image will be by computing it with whatever you've already decoded, and only store the difference between the reality and your prediction ?
(this has already been applied to audio, but afaik not to gfx data)
(and, oh, yes, I don't have a clue on the predictors to use
)
Quote:
Originally Posted by Thorham
Oh, I hadn't realized this. Probably because I use Adpro as a quality reference, and this program is terribly slow, as you know, while your program is very fast |
FastJpeg also uses a similar algorithm, but probably not Visage because its rendering is quite ugly (though it is fast).
Adpro probably makes a lot of analysis to adapt its palette before rendering, which is terribly slow (that's why I didn't want to do it too).
Furthermore, if it's 100% compiled code then it's likely to be up to 4x slower...
Answer here for the viewer options (off-topic in the mpega thread
) : just list a few here and we'll see. Maybe they're already planned.
About the scaling, there is something that annoys me quite a lot : what to do on a palettized display ? Skipping pixels will be ugly and we don't have enough colors to get all the rgb combinations an average would make, but ham display may be even uglier than pixel skipping on some images.
