BeRoPNG - A very tiny but complete PNG loader

[Cybermonkey]

Ah yes danke. Whats the license? I'd like to use it in Prometheus to help replace sdl_image (sloow) to go with the new Win32 and X11 code to finish phasing out sdl for video...

What about the Vampyre Imaging Library? It can handle lots of more formats.(JPEG, BMP,GIF etc.) I use it in my EGSL interpreter project and it works pretty well. But of course, if you only need PNG support ...

[code_glitch]

I'm looking at slimming Prometheus down. From what I've seen Vampyre has a lot features that would never be used, this is literally just a loader by the looks of it and a pretty small one so from that standpoint its perfect. Aside, I already have written up the file type detection system (not the file extension, the binary file headers) so I just need to tell it what proc to use and I'm golden.

[BeRo]

What about the Vampyre Imaging Library? It can handle lots of more formats.(JPEG, BMP,GIF etc.) I use it in my EGSL interpreter project and it works pretty well. But of course, if you only need PNG support ...

BeRoPNG is designed for small binarysize projects and for embedded projects on embedded devices with limited resources. For example my android game FoembJump uses BeRoPNG together with OpenGL ES 2.0. I'm demoscener and a Farbrausch member, so I've fondness for small sized stuff

[BeRo]

I've uploaded a new pure pascal version under the same url http://rootserver.rosseaux.net/stuff/BeRoPNG.pas , which's a bit faster and also compatible to Delphi XE3 & XE4 now.

And the other http://rootserver.rosseaux.net/stuff...oidSpecial.pas variant fallbacks to cpng (a wrapper unit to the on ARM Android faster c-based libpng implementation, which's a bit for Android's own libpng.so modified png.pas from FPC, so you do need http://rootserver.rosseaux.net/stuff/cpng.pas ), if you're building for the Android target, otherwise the pure pascal code part will be used, if you're building for other targets than Android.

[imcold]

I tried the pure pas version in freepascal, works nicely I'd add a comment that ImageData is a PPNGPixel for clarity, not that it mattered much.

[User137]

I feintly remembered reading long time ago, that FPC PNG would have some non-free licence. But now that i tried to find information, i found nothing. All FPC graphics seem to be of same modifiedLGPL that all the other code. But is FPC implementation heavier than this? Maybe it's coming at the cost of supporting more formats, i don't know. I went through all PNG related source files i could find, and there were none licence differences.

[phibermon]

I think that while the full blown libs might support more image types, something like BeroPNG is a far better choice in order to avoid library dependencies, you're going to to be able to load 9x% of the PNGs you find using it and you're defining your own content usually.

There might be some differences in speed but it's negligable, only the most chuggy old iphones are going to show much difference between some native arm lib or arm compiled bero.

[Cybermonkey]

Sorry, I know this is an old thread but I tried BeRoPNG to work with ptcgraph. This is my (simple) example:

var
  f: file;
  fsize: longword;
  buffer: pbyte;  
  ImageData: PPNGPixel;
  ImageWidth,
  ImageHeight:longint;
    gd,gm:smallint;
BEGIN
  AssignFile(f, 'bluepointer.png');
  Reset(f, 1);
  fsize := FileSize(f);
  buffer := getmem(fsize);
  blockread(f, buffer^, fsize);
  CloseFile(f);

  BeRoPNG.LoadPNG(buffer, fsize, ImageData, ImageWidth, ImageHeight, false);
  
  Gd:=D16bit;
  Gm:=m800x600;
  InitGraph(Gd, Gm, 'Test'); 
  
  
   if GraphResult <> grOk then begin
         Writeln('Graphics error: ', GraphErrorMsg(ErrorCode));
    Halt(1);
    end;
  
  putimage (10,10,imageData^,1);
  delay (2000);
  closegraph;
  
  
  freemem(buffer);
  freemem(ImageData);
    
   
END.

But the result isn't correct (see the attached screenshot). I think the problem is that ptcgraph uses a 16 bit colour format with no alpha channel. Any ideas how this can work?
beropngtest.jpg

[deathshadow]

What about the Vampyre Imaging Library?

... and it's massive (relying on the monstrous zlib library for png decode), slow (often painfully so), and on the whole completely unsuited to many projects because of it.

Take on windows for example, where a game I've been puttering around on making for a year or so just had it's executable size cut by two-thirds just by switching to this.

Could be worse though, could be SDLImage, were you need 200k in two DLL's just to unpack .png

Thanks BeRo -- this looks to be getting a lot of use from me.

I should clean up my BMP loader (with RLE4 and RLE8 support) and upload it sometime... sad part is I just ported my BMP loader to PHP as GD actually lacks BMP support. (crappy little one-bit WBMP is NOT Windows BMP!)

[deathshadow]

Uhm... one thing...

function Swap32(x:word):word;
begin
 result:=(Swap16(x and $ffff) shl 16) or Swap16((x and $ffff0000) shr 16);
end;

That doesn't make any sense. Shouldn't X be longword? Word and $FFFF0000 should always return zero on this. Also, if you are shifting right off a 32 bit integer by 16, there's no reason to do an AND on it.

I'd probably also hardcode the byte swaps -- the overhead of the function calls slows down each of these functions in turn.

Playing with checking ifdef cpui386 to add assembler optimized versions of your various routines...

{$ifdef cpui386}
function Swap16(x:word):word; assembler;
asm
	mov ax,x
	xchg ah,al { thankfully FPC/Delphi treat AX as the return value }
end;
{$else}
function Swap16(x:word):word;
begin
 result:=(x shl 8) + (x shr 8);
end;
{$endif}

(also another case where the "and" is unnecessary due to the bit width and pascal's strict typecasting.)

also playing with making a TP7 back-port as I'm still churning out DOS games, and PNG support would be really handy there.