Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #96631 > unrolled thread

PNG coding

Back to article view | Back to comp.lang.c

Contents

  PNG coding ruben safir <ruben@mrbrklyn.com> - 2016-11-15 14:40 -0500
    Re: PNG coding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-15 12:02 -0800
      Re: PNG coding ruben safir <ruben@mrbrklyn.com> - 2016-11-15 15:20 -0500
        Re: PNG coding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-15 12:25 -0800
    Re: PNG coding "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-15 15:34 -0500
      Re: PNG coding Popping mad <rainbow@colition.gov> - 2016-11-15 20:57 +0000
        Re: PNG coding "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-15 16:12 -0500
        Re: PNG coding jadill33@gmail.com - 2016-11-15 14:00 -0800
          Re: PNG coding Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-11-20 11:14 +0000
      Re: PNG coding Richard Heathfield <rjh@cpax.org.uk> - 2016-11-15 21:45 +0000
        Re: PNG coding "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-15 17:15 -0500
          Re: PNG coding Richard Heathfield <rjh@cpax.org.uk> - 2016-11-15 22:41 +0000
            Re: PNG coding Melzzzzz <mel@zzzzz.com> - 2016-11-15 23:49 +0100
            Re: PNG coding Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-11-16 15:23 +0300
              Re: PNG coding Richard Heathfield <rjh@cpax.org.uk> - 2016-11-16 13:57 +0000
                Re: PNG coding BGB <cr88192@hotmail.com> - 2016-11-18 01:24 -0600
                  Re: PNG coding BartC <bc@freeuk.com> - 2016-11-18 11:56 +0000
                    Re: PNG coding BGB <cr88192@hotmail.com> - 2016-11-18 12:48 -0600
                      Re: PNG coding BartC <bc@freeuk.com> - 2016-11-19 00:21 +0000
                        Re: PNG coding BGB <cr88192@hotmail.com> - 2016-11-19 01:50 -0600
          Re: PNG coding Melzzzzz <mel@zzzzz.com> - 2016-11-15 23:42 +0100
          Re: PNG coding BGB <cr88192@hotmail.com> - 2016-11-15 17:53 -0600
            Re: PNG coding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-15 16:25 -0800
          Re: PNG coding raltbos@xs4all.nl (Richard Bos) - 2016-11-18 08:15 +0000
            Re: PNG coding jameskuyper@verizon.net - 2016-11-18 09:35 -0800
            Re: PNG coding supercat@casperkitty.com - 2016-11-20 14:34 -0800
        Re: PNG coding BartC <bc@freeuk.com> - 2016-11-16 19:38 +0000
          Re: PNG coding Richard Heathfield <rjh@cpax.org.uk> - 2016-11-16 22:16 +0000
    Re: PNG coding "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-16 21:14 +0800
    Re: PNG coding Jean-marc Lienher <jean-marc.lienher@bluewin.ch> - 2016-11-16 20:55 +0100
      Re: PNG coding BartC <bc@freeuk.com> - 2016-11-16 20:31 +0000
      Re: PNG coding Richard Heathfield <rjh@cpax.org.uk> - 2016-11-16 22:24 +0000

Page 2 of 2 — ← Prev page 1 [2]

#96661

On Tue, 15 Nov 2016 17:15:55 -0500
"James R. Kuyper" <jameskuyper@verizon.net> wrote:

> On 11/15/2016 04:45 PM, Richard Heathfield wrote:
> > On 15/11/16 20:34, James R. Kuyper wrote:  
> >> On 11/15/2016 02:40 PM, ruben safir wrote:  
> >>> Does anyone know of any sample code for reading PNG files that
> >>> doesn't include using libpng.... just straight direct access.  
> >>
> >> How about looking at libpng itself? It is the official reference
> >> implementation for PNG, and the source code is available under a
> >> permissive free software license. I'd think you'd learn at least
> >> as much by looking at the code for the official reference
> >> implementation as you'd learn by looking at any other code.  
> >
> > Just to encourage people to take James up on his suggestion, here
> > are some statistics from the libpng code.  
> ...
> > Ah, that's very reassuring. Over a megabyte of C code. Let's remind
> > ourselves what we're doing: reading a PNG into memory, or writing it
> > out. Okay, a megabyte (of *source*) seems perfectly reasonable for
> > that.  
> 
> With you, it's sometimes hard to tell, but I'm going to assume you're 
> being sarcastic.
> 
> Keep in mind that this is the official reference implementation of
> PNG. Any fully functional alternative to libpng is likely to be
> comparably complicated - unless the implementors of libpng are
> exceptionally incompetent. I know nothing about that personally, but
> it seems unlikely that PNG would be as popular as it is if that were
> the case.
> 
> Would a less-than-fully-functional alternative be acceptable? In that 
> case, such an alternative could be a lot simpler - but that depends
> upon which features of PNG ruben needs to handle correctly.
> 

Well, how about Golang implementation?
[bmaxa@maxa-pc png]$ ls -l
total 28
drwxr-xr-x 3 bmaxa users    15 14.07.2015 20:01 testdata/
-rw-r--r-- 1 bmaxa users  3685 24.09.2016 02:52 example_test.go
-rw-r--r-- 1 bmaxa users  1768 11.12.2014 20:19 paeth.go
-rw-r--r-- 1 bmaxa users  2252 11.12.2014 20:19 paeth_test.go
-rw-r--r-- 1 bmaxa users 25588 28.10.2016 16:47 reader.go
-rw-r--r-- 1 bmaxa users 17597 28.10.2016 16:47 reader_test.go
-rw-r--r-- 1 bmaxa users 12530 01.10.2016 00:01 writer.go
-rw-r--r-- 1 bmaxa users  4670 11.12.2014 20:19 writer_test.go

reader/writer_test are bunch of golang routines to test every aspect of
library.
This is example decode:

func ExampleDecode() {
        // This example uses png.Decode which can only decode PNG images.
        // Consider using the general image.Decode as it can sniff and decode any registered image format.
        img, err := png.Decode(gopherPNG())
        if err != nil {
                log.Fatal(err)
        }

        levels := []string{" ", "░", "▒", "▓", "█"}

        for y := img.Bounds().Min.Y; y < img.Bounds().Max.Y; y++ {
                for x := img.Bounds().Min.X; x < img.Bounds().Max.X; x++ {
                        c := color.GrayModel.Convert(img.At(x, y)).(color.Gray)
                        level := c.Y / 51 // 51 * 5 = 255
                        if level == 5 {
                                level--
                        }
                        fmt.Print(levels[level])
                }
                fmt.Print("\n")
        }
}

-- 
press any key to continue or any other to quit

[toc] | [prev] | [next] | [standalone]

#96665

On 11/15/2016 4:15 PM, James R. Kuyper wrote:
> On 11/15/2016 04:45 PM, Richard Heathfield wrote:
>> On 15/11/16 20:34, James R. Kuyper wrote:
>>> On 11/15/2016 02:40 PM, ruben safir wrote:
>>>> Does anyone know of any sample code for reading PNG files that doesn't
>>>> include using libpng.... just straight direct access.
>>>
>>> How about looking at libpng itself? It is the official reference
>>> implementation for PNG, and the source code is available under a
>>> permissive free software license. I'd think you'd learn at least as much
>>> by looking at the code for the official reference implementation as
>>> you'd learn by looking at any other code.
>>
>> Just to encourage people to take James up on his suggestion, here are
>> some statistics from the libpng code.
> ...
>> Ah, that's very reassuring. Over a megabyte of C code. Let's remind
>> ourselves what we're doing: reading a PNG into memory, or writing it
>> out. Okay, a megabyte (of *source*) seems perfectly reasonable for that.
>
> With you, it's sometimes hard to tell, but I'm going to assume you're
> being sarcastic.
>
> Keep in mind that this is the official reference implementation of PNG.
> Any fully functional alternative to libpng is likely to be comparably
> complicated - unless the implementors of libpng are exceptionally
> incompetent. I know nothing about that personally, but it seems unlikely
> that PNG would be as popular as it is if that were the case.
>
> Would a less-than-fully-functional alternative be acceptable? In that
> case, such an alternative could be a lot simpler - but that depends upon
> which features of PNG ruben needs to handle correctly.
>

I have a basic PNG loader/saver in my 3D engine.

https://github.com/cr88192/bgbtech_engine2/blob/master/base/bufpng.c
https://github.com/cr88192/bgbtech_engine2/blob/master/base/inflate.c
https://github.com/cr88192/bgbtech_engine2/blob/master/base/deflate.c


it is about 1400 lines for the PNG part, 1000 lines for the inflate 
code, and 1200 lines for the deflate code, or about 4k lines overall.

capabilities are that it encodes/decodes PNG images given in buffers, 
and does a whole image at a time (no partial or stream decoding).

support is generally limited to 24 and 32-bit RGB/RGBA.
it does 8-bits/component, no 16-bit components, and 8-bit palette images 
don't work. there is no support for additional metadata.


externally, there is support for an HDR PNG variant (where logically 
components are floating-point numbers), but in the PNGs this is 
accomplished by sticking an exponent in the alpha channel (using an RGBE 
variant, with a sub-variant supporting signed components).

it is generally possible to distinguish between RGBA and the HDR RGB 
variants by "fingerprinting" the pixel data (actually works surprisingly 
well).

note that, in general, images which need both HDR and an alpha-channel 
are virtually non-existent in-practice (and not generally supported by 
graphics hardware, but it is possible to do this via shaders).

main reason for doing this was mostly as a cheaper/simpler alternative 
to EXR.

[toc] | [prev] | [next] | [standalone]

#96667

On Tuesday, November 15, 2016 at 6:53:04 PM UTC-5, BGB wrote:
> I have a basic PNG loader/saver in my 3D engine.
> 
> https://github.com/cr88192/bgbtech_engine2/blob/master/base/bufpng.c
> https://github.com/cr88192/bgbtech_engine2/blob/master/base/inflate.c
> https://github.com/cr88192/bgbtech_engine2/blob/master/base/deflate.c
>
> it is about 1400 lines for the PNG part, 1000 lines for the inflate 
> code, and 1200 lines for the deflate code, or about 4k lines overall.

I didn't go through it line by line, but at first glance it was very
nice looking code, Brendan.

Best regards,
Rick C Hodgin

[toc] | [prev] | [next] | [standalone]

#96790

"James R. Kuyper" <jameskuyper@verizon.net> wrote:

> official reference implementation

*Brrr*

Always a dire warning sign, if something is officially defined by a code
base. Bugs become mandatory and cruft can only accumulate.

Richard

[toc] | [prev] | [next] | [standalone]

#96869

On Friday, November 18, 2016 at 3:16:06 AM UTC-5, Richard Bos wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> wrote:
> 
> > official reference implementation
> 
> *Brrr*
> 
> Always a dire warning sign, if something is officially defined by a code
> base. Bugs become mandatory and cruft can only accumulate.

I agree, particularly given Richard's assessment of the code quality. But that
is how Wikipedia describes it. If anyone monitory this thread is certain that
Wikipedia is wrong about that, please say so.

[toc] | [prev] | [next] | [standalone]

#97155

On Friday, November 18, 2016 at 2:16:06 AM UTC-6, Richard Bos wrote:
> "James R. Kuyper" wrote:
> 
> > official reference implementation
> 
> *Brrr*
> 
> Always a dire warning sign, if something is officially defined by a code
> base. Bugs become mandatory and cruft can only accumulate.

There are advantages and disadvantages to such an approach.  If the goal is
to define a complete mapping which maps every possible input pattern of bits
to some specific output pattern, it may be easier to ensure that a reference
implementation does that than to ensure that a textual description covers all
possible cases.  While a complete mapping will be less flexible than one
which allows for implementations to make some choices in Unspecified fashion,
it has the advantage that it may be easier to test whether an implementation
yields output that exactly matches a reference implementation for all possible
inputs, than to test whether it yields acceptable output for all possible
inputs.

As an example, if IEEE-754 had specified that trig functions must always use
a certain formula which will for every input yield a particular value which
would in some cases be up to 0.6ulp away from the correct value, that would
have made trig functions more expensive to implement and less accurate than
they might otherwise be, but would have made it much easier to validate an
IEEE-754 implementation since for any sequence of inputs there would only be
one possible output.

[toc] | [prev] | [next] | [standalone]

#96712

On 15/11/2016 21:45, Richard Heathfield wrote:
> On 15/11/16 20:34, James R. Kuyper wrote:

>> How about looking at libpng itself?

(Sure! IME looking at an open source project that is usually futile.)
....

> Actually, since it's about 900 lines long, I don't think I'll show any
> more of it. It's obviously all quite self-explanatory, and you won't
> need any help at all in understanding it completely. Five minutes should
> do it. Maybe ten if you're having a bad day. For the whole library?
> Perhaps an hour. After all, it's only 40,000 lines.

You might be turning into me with an intolerance of needlessly complex 
software!

But I get this all the time. Eg. a 2GB (yes gigabyte) install of Haskell 
/that didn't work/.

The most recent was looking again at SDL ("Simple DirectMedia Layer" or 
something; note the work 'Simple'). The binary download for Windows was 
a single 500KB DLL. Oh! Something actually small and straightforward for 
a change?

Except it took the best part of an hour to find a basic hello 
world-style tutorial. It was either in C++ (SDL is a C library), or was 
the wrong version (there are incompatible 1.2 and 2.0 versions), or I 
just followed links until I ended up where I'd started from!

Eventually I found one, and it needed "SDL.h". OK, download all the 
include files, of which there are 80, some 35,000 lines' worth (not as 
many as your 40,000, but remember these are headers, not code).

(They are placed outside of any C compiler as I wanted this to be 
independent of a compiler, so that meant changing <SDL2.h> to "SDL2.h", 
which worked for my simple program. But I guess there are more such 
includes within the other 79 others.)

So, right version of test program, right version of headers, it 
compiles, but doesn't link. There is no 'main()' function. Even this 
program:

  #include <SDL2.h>
  int main (void) {}

doesn't work. It turns out that that header redefines my 'main' as 
'SDL_main', and I'm expected to statically link something else that 
contains 'main'.

This is no good: I don't want to have to source half a dozen libraries 
for the various compilers, and I'm planning to use it from outside C 
anyway. However I can just do this:

   #undef main

and it seemed to work (but I need to find out what initialisations are 
missing).

So that's that, but I need to find out if it's the same pattern on 
Linux, except the information available is abysmal. Look at the website: 
'For Linux binaries, contain your distributor.'; so I don't even know 
what the library is called. What does a Linux user who wants to RUN a 
program that uses SDL, not compile and build one, need to download? I 
still don't know.

(I believe the library is called libSDL2.so, at least on Ubuntu, and I 
got it I think as a result of installing 'libsdl2-dev', all 67MBs' 
worth. Would it have killed anyone to have given this basic info on the 
website?)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#96719

On 16/11/16 19:38, BartC wrote:
> On 15/11/2016 21:45, Richard Heathfield wrote:
<snip>
>> [...]  After all, it's only 40,000 lines.
>
> You might be turning into me with an intolerance of needlessly complex
> software!

The trick is to avoid making a habit of complaining about it.


-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#96683

On 16/11/2016 3:40 AM, ruben safir wrote:
> Does anyone know of any sample code for reading PNG files that doesn't
> include using libpng.... just straight direct access.

It's not just a format, it's data structure + algorithm.

How do you decode the PNG *without* forging extra evidences and 
obstruction of justice when the image is submitted to courts? :P

[toc] | [prev] | [next] | [standalone]

#96715

ruben safir wrote:
> Does anyone know of any sample code for reading PNG files that doesn't
> include using libpng.... just straight direct access.
>
>
Yes:
https://github.com/nothings/stb/blob/master/stb_image.h

[toc] | [prev] | [next] | [standalone]

#96716

On 16/11/2016 19:55, Jean-marc Lienher wrote:
> ruben safir wrote:
>> Does anyone know of any sample code for reading PNG files that doesn't
>> include using libpng.... just straight direct access.
>>
>>
> Yes:
> https://github.com/nothings/stb/blob/master/stb_image.h

That worked, eventually, but rather over-complicated by trying to have a 
.h file that both contained shared declarations, and code.

So you can't just stick a main() routine at the end of the file. And you 
  can't just #include the file as a header, it needs an extra #define.

It's better than the majority of such libraries however.

(I still wouldn't like to have to fix a bug in it, even if it's only 
6000 lines instead of 40000.)

-----------------------------------

  #define STB_IMAGE_IMPLEMENTATION
  #include "stb_image.c"             // or .h

  int main(void){
     char* data;
     int x,y,n;

     data = stbi_load("file.jpg", &x, &y, &n, 0);

     printf ("data = %p\n",data);
     printf ("x = %d y = %d n = %d\n",x,y,n);

  }


(I use stb_image.c not .h as my IDE can't compile standalone .h files.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#96721

On 16/11/16 19:55, Jean-marc Lienher wrote:
> ruben safir wrote:
>> Does anyone know of any sample code for reading PNG files that doesn't
>> include using libpng.... just straight direct access.
>>
>>
> Yes:
> https://github.com/nothings/stb/blob/master/stb_image.h

Don't they teach today's kids about modules?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web