Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 08 17:49

    randy408 on v070

    bump version to v0.7.0-rc3 add spng_get_gama_int(), spng_s… refactor testsuite, compare chu… (compare)

  • May 10 13:43

    randy408 on v0.7.0-rc2

    (compare)

  • May 10 12:24

    randy408 on circleci-project-setup

    Add .circleci/config.yml (compare)

  • May 10 12:19

    randy408 on v070

    adapt NEON filter optimizations docs: document SPNG_ARM (compare)

  • May 05 13:30

    randy408 on v070

    paeth_arm(): remove abort() ci… refactor indexed color decoding… (compare)

  • May 05 10:18

    randy408 on v070

    initial circleci integration a… (compare)

  • May 05 10:07

    randy408 on circleci-project-setup

    Updated config.yml (compare)

  • May 05 08:25

    randy408 on v070

    test: improve workaround for li… next release will be v0.7.0-rc2 (compare)

  • May 04 13:34

    randy408 on circleci-project-setup

    Updated config.yml (compare)

  • May 04 13:32

    randy408 on circleci-project-setup

    Updated config.yml (compare)

  • May 04 13:24

    randy408 on circleci-project-setup

    Updated config.yml (compare)

  • May 04 13:02

    randy408 on circleci-project-setup

    Updated config.yml (compare)

  • May 04 12:35

    randy408 on circleci-project-setup

    Updated config.yml (compare)

  • May 04 12:34

    randy408 on circleci-project-setup

    Updated config.yml (compare)

  • May 04 12:32

    randy408 on circleci-project-setup

    Updated config.yml (compare)

  • May 04 12:17

    randy408 on circleci-project-setup

    Updated config.yml (compare)

  • May 04 12:16

    randy408 on circleci-project-setup

    Updated config.yml (compare)

  • May 04 12:11

    randy408 on circleci-project-setup

    Add .circleci/config.yml (compare)

  • May 04 12:11

    randy408 on circleci-project-setup

    (compare)

  • May 04 11:53

    randy408 on v070

    fix indentation for arm neon op… oversize buffers used for defil… enable filter optimizations for… (compare)

Kleis Auke Wolthuizen
@kleisauke
Thanks! CI failure is due to broken HEIC write (strukturag/libheif#404 was fixed, so heifload and heifsave are working in the CI again)
I had a closer look at 4.png and 6.png and they seem to both originate from a faulty server which sets the wrong Content-Length header and thus basically causes the image to be truncated.
John Cupitt
@jcupitt
we should probably turn off travis now that github actions are working
sorry @randy408 we need our own chat, I'll make one
Kleis Auke Wolthuizen
@kleisauke
Production server is running on the 8.10 branch and libspng master. I can confirm that the error messages are now more obvious.
I monitored it for a few hours and could not find an image that caused a different error with pngcheck than those mentioned above. Will check the logs again within a couple of days.
Randy
@randy408
@kleisauke did any other issue come up?
Kleis Auke Wolthuizen
@kleisauke
@randy408 I've send you an e-mail with the second batch of new non-conforming PNG images. These were found in the logs from 6 January until now.
11.png and 12.png does not cause an pngcheck error, but cannot be decoded with libspng master, curious.
Randy
@randy408
@kleisauke those two have zero-length known chunks, maybe pngcheck skips those
Randy
@randy408
I couldn't load 13.pngwith any browser/image viewer, pngcheck also prints ERROR: ../i/13.png on the next line, I think IDAT stream error is the right error message
the errors for 14.png and 15.png can be made non-critical, the same github issue I mentioned earlier applies to these
Randy
@randy408
the latest master now returns invalid chunk length for the first two
Kleis Auke Wolthuizen
@kleisauke
Thanks! I could open 11.png and 12.png in the browser, and libpng is also able to decode those. 13.png is a black image here.
Randy
@randy408
yes, those would also be fixed by randy408/libspng#132
Kleis Auke Wolthuizen
@kleisauke
Ah, I though that the iDOT error from pngcheck was the reason why 13.png could not be decoded. https://github.com/tcltk/tk/raw/main/tests/iDOT.png seems to work fine.
Randy
@randy408
I couldn't load 13.png at all on firefox, the error happens on the first row so I doubt the black pixels come from the PNG itself
Kleis Auke Wolthuizen
@kleisauke
You're right, Chrome doesn't report it as broken (it looks like a transparent image and the dimensions are reported), but on Firefox it's clearly broken.
Randy
@randy408
@jcupitt I'm closing randy408/libspng#145 if libpng can't read the file either, see my last comment
Randy
@randy408
@kleisauke i'll add a stopgap fix for the invalid bKGD length and make a release soon, did you find any other corrupt PNG's that stand out or are very common?
Kleis Auke Wolthuizen
@kleisauke
Thanks! The invalid bKGD length of pngcheck was the most frequent error. Here are the statistics from last week:
$ grep -hro --include=error.log\* 'Cause: pngload_buffer: .*' /var/log/nginx | sort | uniq -c | sort -rn
   1024 Cause: pngload_buffer: invalid chunk length
    667 Cause: pngload_buffer: invalid chunk position
    254 Cause: pngload_buffer: end of stream
     80 Cause: pngload_buffer: invalid gAMA chunk
     54 Cause: pngload_buffer: duplicate iCCP chunk
     14 Cause: pngload_buffer: invalid cHRM chunk
     14 Cause: pngload_buffer: invalid argument
      5 Cause: pngload_buffer: unknown critical chunk
      3 Cause: pngload_buffer: invalid pHYs chunk
      3 Cause: pngload_buffer: duplicate pHYs chunk
      1 Cause: pngload_buffer: invalid eXIf chunk
      1 Cause: pngload_buffer: invalid color type
Kleis Auke Wolthuizen
@kleisauke
(I think the invalid argument error was fixed with randy408/libspng@d76e6d1, but I hadn't updated the production server yet)
Anyways, I just updated to libspng master (randy408/libspng@3c1bb4f) and can confirm that the images causing the invalid bKGD length errors are now loading correctly.
AlaBouza
@AlaBouza

Hi, compiling libspng with Visual Studio 17 (15.9.16) or Intel C 2018 I am getting errors when running "example.c"
I compiled the libspng with a project I created because there were some errors with CMAKE.
I compile for Windows 64 bits. I am using a full ZLIB dll, not the miniz.
When the library is compiled in DEBUG mode the following error is presented due to a wrong assert:
Expression: _osfile(fh) & FOPEN

Any idea?
Thanks

The error is triggered in the call:
r = spng_get_ihdr(ctx, &ihdr);
AlaBouza
@AlaBouza
Any one has a libspng compiled for Windows 64 bits for use with MSVC (it is good for me because I use Intel C as main compiler) ?
Randy
@randy408
@AlaBouza that's odd, is the file path the first argument?
AlaBouza
@AlaBouza

Hi. Thanks for answer.
Yes. Note that fopen() is successful:

png = fopen(argv[1], "rb");
if(png == NULL)
{
printf("error opening input file %s\n", argv[1]);
goto error;
}

so, png is not NULL

I tried in DEBUG, and RELEASE modes, always as x64.
The possible mistake comes from the fact that I could not get a good result with CMAKE (problem to find the zlib.h and zlib.lib - my lack of knowledge of CMAKE) so I created my own project to compile libspng.lib and the corresponding libspng.dll
Randy
@randy408
there's probably some kind of compiler/runtime mismatch going on, the simplest build would involve compiling spng.c/h and miniz.c/h together: https://libspng.org/docs/build/#miniz
Randy
@randy408
@/all Good news! NLNet will be funding encode support and improvements to decoding! The updated 0.7.0 milestone is a good summary of what's to come, this will be preceded by 0.6.x revisions.
John Cupitt
@jcupitt
Hey, that's great news! Well done @randy408
Randy
@randy408
@kleisauke the latest revision now ignores most non-critical errors (randy408/libspng#132), I believe it's stable enough to be worth trying out
Kleis Auke Wolthuizen
@kleisauke
Great! I'll test it next week.
Randy
@randy408
@kleisauke i'm planning on making a release a week from now, any image that doesn't have a critical error should just work
Kleis Auke Wolthuizen
@kleisauke
@randy408 Great! Sorry for the delay (a roommate tested positive for COVID-19). I'm now testing commit randy408/libspng@24110bb in production, will monitor it for a few days.
Kleis Auke Wolthuizen
@kleisauke
fwiw, I can confirm that 14.png and 15.png can be loaded without any problems now.
Kleis Auke Wolthuizen
@kleisauke
Looks like all previous failed chunk errors are working fine now, thanks! Statistics from last week:
$ grep -hro --include=error.log\* 'Cause: pngload_buffer: .*' /var/log/nginx | sort | uniq -c | sort -rn
    264 Cause: pngload_buffer: end of stream
      2 Cause: pngload_buffer: unknown critical chunk
      2 Cause: pngload_buffer: chunk exceeds maximum standard length
      1 Cause: pngload_buffer: invalid image height
Randy
@randy408
@kleisauke probably late at this point but v0.6.3 was shipped with the same code
Kleis Auke Wolthuizen
@kleisauke
@randy408 No worries, I noticed via https://release-monitoring.org/ that it was released (and updated it within our RPMs with commit weserv/rpms@56b5c9f), thanks.
Kleis Auke Wolthuizen
@kleisauke
Randy
@randy408
@kleisauke yes, avoiding the slow path in stock zlib is something i'll look into at some point
Kleis Auke Wolthuizen
@kleisauke
Do you know if the libspng benchmarks were ran with zlib-ng in the appendix?
Randy
@randy408
Not sure, all I know is wuffs has it's own DEFLATE algorithm
and having (height+1)*width memory overhead always helps performance :smile:
Kleis Auke Wolthuizen
@kleisauke
Yeah, I'm also not sure if the LD_LIBRARY_PATH / LD_PRELOAD trick is the right way to benchmark with zlib-ng, it might cause a slowdown compared to stock zlib, see for e.g. issue zlib-ng/zlib-ng#947.
Randy
@randy408
call overhead is not something I really considered, I could test static/dynamic builds some time to see if there's a difference
Randy
@randy408
regarding LD_PRELOAD: the perf ratios for libpng/spng and lodepng/stb (which don't use zlib) make sense so i assume the benchmarks are more or less accurate