Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Coming soon: Jpeg loader
#1
This is to announce the release in a couple of weeks of a FB jpeg loader for gfxlib.
You have at the moment the possibility of loading jpegs in a portable way using SDL or Allegro (Allegro's loader is by lillo !!)

I'm trying to make my old (1999) QB code into a lib with these functions:

Functions generating an image:
Load Image to Gfxlib buffer (uses gfxlib API)
Load Image to general buffer (without any gfxlib call)

Functions not generating an image:
GetImagesize (just reads image size h X w from file)
Getparameters (prints to a file the jpeg file structure)
PrintError (prints the error code returned by the previous functions)

It will work in true color, not in paletted modes.

You have at the moment the possibility of loading jpegs in portable form using SDL or Allegro (Allegro's loader is by lillo !!)

At the moment I'm able to output a 1Mb Jpeg to screen in 0,44 seconds in a P4 2,4, it compares with what IE does...I'm using lillo's profiler to try to make it faster, but the bit manipulation slows everything down. A 70% of the time is spent in the Huffman decoder.

Ideas, suggestions?
Antoni
Reply
#2
I don't care about the speed. They'd be bitmaps later anyways. What I care about is the fact that it would be in the GFX lib!!!

Woot!!!!
Big Grin
y smiley is 24 bit.
[Image: anya2.jpg]

Genso's Junkyard:
http://rel.betterwebber.com/
Reply
#3
sounds good! Im glad you are including a getimagesize function, because I created an image viewer for my aging laptop (it only has a crappy quickviewer that rarely works) and I dont know how to retrieve the size of image because I hate SDL. With a GFZ Lib implemented version I would be over the moon.

(even if I could only use it for JPG Loading)

Perhaps you could create a whole library with JPG, GIF and perhaps even PNG?

One thing: Will it support progressive Jpgs?
Reply
#4
rel: The speed is an excuse to keep introducing "serious programming" elements as pointers and things.. Btw your daughter picture in your sig is a jpeg with a "negative" compression ratio (bigger than a bmp of the same res)
dark: Progressive jpegs will have to wait to a next issue. Make that thing into alib will be hard enough...
Antoni
Reply
#5
Quote:rel: The speed is an excuse to keep introducing "serious programming" elements as pointers and things.. Btw your daughter picture in your sig is a jpeg with a "negative" compression ratio (bigger than a bmp of the same res)
dark: Progressive jpegs will have to wait to a next issue. Make that thing into alib will be hard enough...

Sad Sad Sad
y smiley is 24 bit.
[Image: anya2.jpg]

Genso's Junkyard:
http://rel.betterwebber.com/
Reply
#6
It might be useful to write a routine that maps a true color image to a palette by finding the nearest color. Even though it has to be applied to each pixel, it could be done fast enough for an acceptable speed.
Reply
#7
Quote:Btw your daughter picture in your sig is a jpeg with a "negative" compression ratio (bigger than a bmp of the same res)

No it isnt...

using 24 bit,
100x86x24/8/1024 = 25.2Kb
The JPG in the sig is only 3.34Kb
Reply
#8
I see...Houston, we have a problem!!
Antoni
Reply
#9
It remains an agonizingly adorable picture though.
Reply
#10
Quote:It remains an agonizingly adorable picture though.
Agreed!!!

She got to be the Bouquet bearer last may 24 at the coronation of my wife's town's Queen. ;*)
y smiley is 24 bit.
[Image: anya2.jpg]

Genso's Junkyard:
http://rel.betterwebber.com/
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)