PNG Coding

[ruben safir]

Does anyone know of any sample code for reading PNG files that doesn't
include using libpng.... just straight direct access.

[Alf P. Steinbach]

On 15.11.2016 20:46, ruben safir wrote:
> Does anyone know of any sample code for reading PNG files that doesn't
> include using libpng.... just straight direct access.
>

Find the specification, code it up?


Cheers!,

- Alf

[Scott Lurndal]

ruben safir <ru...@mrbrklyn.com> writes:
>Does anyone know of any sample code for reading PNG files that doesn't
>include using libpng.... just straight direct access.

libpng, being open source, would seem to be the best starting point
for someone who wishes to code the same functionality.

[Rick C. Hodgin]

On Tuesday, November 15, 2016 at 2:46:31 PM UTC-5, ruben safir wrote:
> Does anyone know of any sample code for reading PNG files that doesn't
> include using libpng.... just straight direct access.

On Windows and with a C++ compiler, you can use the built-in
Gdiplus::Bitmap object and load the png and then write it out
as a standard .bmp format, which is much easier to access
line-by-line.

See:

Bitmap class:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms534420(v=vs.85).aspx

Basically, load the image, convert it to a HBITMAP which you then
BitBlt onto another HBITMAP you've created using CreateDIBSection().
In that one you obtain a pointer to the bits and can write them out
in any format you desire:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms536295(v=vs.85).aspx

Some steps in this operation:

Make sure structures are packed to 1-byte (and not the default 8-
or 16-bytes).
Use GdiplusStartup() to engage the Gdiplus engine.
Use the image->GetWidth() and image->GetHeight() to determine size.
Use image->LockBits() to obtain a BitmapData object.
Use image->GetHorizontalResolution() * 39.700787f to get pixels
per meter for the output bmp setting. And GetVerticalResolution().
Use image->unlockBits() when finished.
Use GdiplusShutdown() to disengage the Gdiplus engine.

Best regards,
Rick C. Hodgin

[Christian Gollwitzer]

Am 15.11.16 um 20:46 schrieb ruben safir:

> Does anyone know of any sample code for reading PNG files that doesn't
> include using libpng.... just straight direct access.
>

Sean Barret has very impressive (compact) C code to write PNG files in
stb_image_write.h:

https://github.com/nothings/stb

I have not checked if this does reading of PNGs, too; however he has a
ite here on github which lists similar libraries, and this refers to

http://lodev.org/lodepng/

Christian

[Popping mad]

On Tue, 15 Nov 2016 21:31:16 +0100, Christian Gollwitzer wrote:

> https://github.com/nothings/stb

too complex. I'm just looking for PNG access

[Popping mad]

On Tue, 15 Nov 2016 12:06:12 -0800, Rick C. Hodgin wrote:

> On Windows

/dev/null

[Popping mad]

On Tue, 15 Nov 2016 19:58:33 +0000, Scott Lurndal wrote:

> libpng, being open source, would seem to be the best starting point for
> someone who wishes to code the same functionality.

maybe, but its complex and I think it is broken. At some point they
decided to fix a long standing bug that has rended most of my early png
files useless. And the programs design to fix them don't work, so I want
to excavate the problem myself. I'm not looking to create a huge
library, just to look at the files at this point under the hood,
perferably in a single file program

[Christian Gollwitzer]

Am 15.11.16 um 21:50 schrieb Popping mad:

> On Tue, 15 Nov 2016 21:31:16 +0100, Christian Gollwitzer wrote:
>
>> https://github.com/nothings/stb
>
> too complex. I'm just looking for PNG access
>

Are you sure you read my reply?

https://github.com/lvandeve/lodepng

this is a 2-file solution to read/write PNG. There is an even smaller
version for reading only: http://lodev.org/lodepng/picopng.cpp

Considering the complexity of the task (decoding PNG), it is extremely
impressive to stuff that into these small files.

Christian

[Popping mad]

On Wed, 16 Nov 2016 00:15:06 +0100, Christian Gollwitzer wrote:

> https://github.com/lvandeve/lodepng



ah, that is good. Thank you.

[Juha Nieminen]

Christian Gollwitzer <auri...@gmx.de> wrote:
> Sean Barret has very impressive (compact) C code to write PNG files in
> stb_image_write.h:
>
> https://github.com/nothings/stb

I appreciate simple projects being as minimal as possible in terms of source
files (ie. rather than have a million tiny source files, often requiring
configure scripts, makefiles and whatnot, just a few, preferably one or two,
source files that Just Work(TM), as they are. Just add them to your project
or compile command, and that's it. No fuss, no hassle. I like that.)

However, a header-only implementation using an enormous amount of very
large static functions (because C doesn't support inline)? Come on.
That goes a bit too far. If you ever include the header file in more
than one place, you'll be duplicating all the code in your executable.
(I don't think linkers will check if two static functions are
completely identical in content and merge them. If some do, great,
but AFAIK they usually don't.)

[Christian Gollwitzer]

Am 16.11.16 um 09:01 schrieb Juha Nieminen:

Well nothing stops you from removing the static declarations and
replacing it by either inline or turn the header file into a "real"
library. The license for all the libraries he lists at
https://github.com/nothings/single_file_libs is zlib, MIT or public
domain, i.e. basically "do whatever you want with it" - and for most
parts it is extremely impressive how they fit the functionality into
such a small numbero of LOCs with zero dependencies.

Partly the "static" seems to be motivated by the missing "inline" in
older C compilers.

You can also always wrap the functionality for you own use in your
larger project.


Christian

[Scott Lurndal]

Then look for netpbm.

[Wouter van Ooijen]

Op 16-Nov-16 om 9:01 AM schreef Juha Nieminen:

> Christian Gollwitzer <auri...@gmx.de> wrote:
>> Sean Barret has very impressive (compact) C code to write PNG files in
>> stb_image_write.h:
>>
>> https://github.com/nothings/stb
>
> I appreciate simple projects being as minimal as possible in terms of source
> files (ie. rather than have a million tiny source files, often requiring
> configure scripts, makefiles and whatnot, just a few, preferably one or two,
> source files that Just Work(TM), as they are. Just add them to your project
> or compile command, and that's it. No fuss, no hassle. I like that.)
>
> However, a header-only implementation using an enormous amount of very
> large static functions (because C doesn't support inline)? Come on.
> That goes a bit too far. If you ever include the header file in more
> than one place, you'll be duplicating all the code in your executable.

I don't see why that would lead to executable bloat. Did you try this?

Wouter "Objects? No Thanks!" van Ooijen

[Öö Tiib]

On Wednesday, 16 November 2016 10:01:49 UTC+2, Juha Nieminen wrote:
>
> However, a header-only implementation using an enormous amount of very
> large static functions (because C doesn't support inline)?

AFAIK 'inline' is in C since C99 and I remember that several
C compilers supported it before 1999.

[Alf P. Steinbach]

The keyword is there but it has slightly different semantics.

Cheers!,

- Alf

[Richard]

[Please do not mail me a copy of your followup]

ruben safir <ru...@mrbrklyn.com> spake the secret code
<o0fom4$ov$2...@reader2.panix.com> thusly:

>Does anyone know of any sample code for reading PNG files that doesn't
>include using libpng.... just straight direct access.

If I were to make a C++ PNG parser/emitter from scratch these days, I
might use Boost.Spirit (parser framework that can handle binary blobs
quite easily). Another approach might be to overlay a chunk iterator
view on top of the raw PNG stream. This would avoid copying of data
and might result in something really fast for reading. For writing,
its just a stream of chunks that are defined according to the things
in them. I don't think there's a way you can avoid at least 1
copying of data into an internal buffer when doing writing. I'm just
brainstorming here, so I could be wrong.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

Popping mad <rai...@colition.gov> spake the secret code
<o0fsef$k40$4...@reader2.panix.com> thusly:

>On Tue, 15 Nov 2016 12:06:12 -0800, Rick C. Hodgin wrote:
>
>> On Windows
>
>/dev/null

Nope, Windows uses NUL:.

[Richard]

[Please do not mail me a copy of your followup]

Popping mad <rai...@colition.gov> spake the secret code

<o0gjvh$k40$8...@reader2.panix.com> thusly:

>On Wed, 16 Nov 2016 00:15:06 +0100, Christian Gollwitzer wrote:
>
>> https://github.com/lvandeve/lodepng
>
>ah, that is good. Thank you.

Interesting, didn't know about that one.

"It's made for C (ISO C90), and has a C++ wrapper with a more
convenient interface on top."

Oddly, these days this sort of approach feels backward to me. I'd
rather see a library written in C++ with a C wrapper on top.