Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 21 21:00

    randy408 on master

    README: minor usage example fix… (compare)

  • Apr 21 20:53

    randy408 on master

    cmake: make finding zlib in-tre… (compare)

  • Apr 11 08:36

    randy408 on master

    meson: update zlib wrap (compare)

  • Apr 07 16:18

    randy408 on master

    docs: improve wording on SPNG_S… (compare)

  • Mar 23 19:22

    randy408 on master

    docs: move section on untrusted… update comments on spng_format (compare)

  • Mar 07 18:17

    randy408 on master

    read_fuzzer: keep unknown chunks write_fuzzer: increase compress… (compare)

  • Feb 22 18:57

    randy408 on fuzz_coverage

    read_fuzzer: keep unknown chunks write_fuzzer: increase compress… (compare)

  • Feb 14 06:13

    randy408 on master

    read_scanline_bytes(): cleanup encode: clean up unknown chunk … read_non_idat_chunks(): fix red… (compare)

  • Feb 11 19:30

    randy408 on master

    bump version to v0.7.3 (compare)

  • Feb 11 19:29

    randy408 on cleanup_v073

    read_non_idat_chunks(): fix red… (compare)

  • Feb 11 19:06

    randy408 on cleanup_v073

    read_scanline_bytes(): cleanup encode: clean up unknown chunk … (compare)

  • Feb 11 16:08

    randy408 on v0.7.2

    (compare)

  • Feb 09 22:56

    randy408 on master

    decode: expose zlib FLEVEL for … (compare)

  • Feb 09 10:36

    randy408 on master

    write_fuzzer: reduce image comp… (compare)

  • Feb 09 09:55

    randy408 on master

    spng_encode_chunks(): add more … (compare)

  • Feb 09 07:21

    randy408 on decode_cmf_flg

    test: fix typo [skip-ci] (compare)

  • Feb 08 23:36

    randy408 on decode_cmf_flg

    test: fix double-free test: fix FLEVEL check for mini… (compare)

  • Feb 08 19:42

    randy408 on decode_cmf_flg

    decode: assume Z_DEFAULT_COMPRE… test: check image FLEVEL parsing (compare)

  • Feb 03 18:32

    randy408 on master

    Add issue template (compare)

  • Feb 03 16:12

    randy408 on encode_window_size

    disable deflate window bits opt… (compare)

Randy
@randy408
anyway this will be revisited when the PNG standards people get around to this, it's mostly just my opinion at this point
Randy
@randy408
parallel encoding can be done without having to agree on a spec
Randy
@randy408
@jcupitt I think the encode option optimizations will need some changes, if filtering is disabled zlib strategy will always be Z_DEFAULT_STRATEGY, it's a good guess but it should be possible to force any configuration
Randy
@randy408
One solution would be to only optimize options that weren't explicitly set
John Cupitt
@jcupitt
you mean the libspng encode API I guess?
sure, happy to wait on any changes you'd like to make
Randy
@randy408
yeah, the encoder may override user settings and there's no way to get around it at the moment
Randy
@randy408
basically there are no exact defaults, it optimizes options based on user settings and image type
in the next revision this will change slightly, if something is set with spng_set_option() it will not override that option anymore
Randy
@randy408
@jcupitt i have an idea on how to expose compression level to address this randy408/libspng#114
i'll tweak the decoder slightly to parse the deflate header in spng_decode_image() and the value would be retrieved with spng_get_option(ctx, SPNG_IMG_COMPRESSION_LEVEL, &value);
Randy
@randy408
spng_get_option() returns the default value of 6 since v0.7.0 even for decoders, that collides with FLEVEL=2 (zlib's default of 6)
Randy
@randy408
i would prefer to return the converted zlib compression level instead of the 4-bit FLEVEL
to get around the collision i think i'll set -value instead, no other values other than 6 can be retrieved for previous versions so if(value < 1) would indicate the value is derived from the zlib header.
John Cupitt
@jcupitt
my 2p would be to just return an estimated 0-9 ... the extra logic to handle -ve values would cause pain for many downstream projects, and it's a very small API change
but your choice (of course)
(AVX2 only)
Kirk Martinez
@kmartinez
I forsee another #define for AVX if its another speed boost ;-) Good for a lot of physical servers! Not sure if VMs inherit the hardware...
Randy
@randy408
zlib-ng has AVX2 optimizations, i have yet to integrate it into my benchmark tool
Randy
@randy408
fpnge doesn't compile for me with clang++ 11 nor gcc 10
Randy
@randy408
most of the optimizations in it are compression-related, spng relies on a zlib inteface
Randy
@randy408
regardless, if there are crazy speedups compared to zlib-ng then it should be merged with miniz or zlib-ng
Randy
@randy408
it's not practical for me to include hundreds of lines of SIMD compression code that doesn't even expose basic options like compression level
Randy
@randy408
@jcupitt the 32-bit limitation should be fixed with randy408/libspng#202
John Cupitt
@jcupitt
thanks!
Randy
@randy408
I just realized the default image compression level is not 6 but -1 (Z_DEFAULT_COMPRESSION), zlib will pick 6 for that value so it is possible to expose the compression level estimates as positive values without confusion
Randy
@randy408
randy408/libspng#204
value >= 0 will indicate the header was parsed and is derived from FLEVEL, -1 if not which is consistent with previous versions, it will always be a valid value for zlib
John Cupitt
@jcupitt
ok, that sounds great!
are these improvements for v0.8?
Randy
@randy408
technically there are no api changes, either next release (v0.7.2) or v0.7.3
John Cupitt
@jcupitt
ah, good stuff
Randy
@randy408
the 32-bit limit fix is definitely next release, i don't see a reason why that fix wouldn't work but a confirmation that the bug is 100% gone with libvips would be nice
John Cupitt
@jcupitt
ok, I'll try to make a win32 libvips binary and check it in wine
Randy
@randy408
@jcupitt if nothing comes up v0.7.2 will be out tomorrow, with the FLEVEL stuff
John Cupitt
@jcupitt
great!
sorry, I never fed back on the 32-bit fix, I got started but then was distracted by something else
Kleis Auke Wolthuizen
@kleisauke
I'm currently fiddling with the Windows builds (for the upcoming LLVM 14 update), so I might test this as well.
Randy
@randy408
there is a PR for optimizing the deflate window bits (randy408/libspng#206) but it still wouldn't produce bit-identical results to libpng without rewriting the zlib header manually
so i'm not merging that for this release, there is a non-zero risk it will mess something up with no real upside
Kleis Auke Wolthuizen
@kleisauke
I can confirm randy408/libspng#198 is resolved now (Windows binaries were built from commit libvips/build-win64-mxe@fdbf3ca).
$ vips-dev-w32-web-8.12.2-static\vips-dev-8.12\bin\vips.exe copy MapFishermansRowHexBigBig.png x.png
$ echo Exit Code is %errorlevel%
Exit Code is 0
Randy
@randy408
John Cupitt
@jcupitt
great!
John Cupitt
@jcupitt
I tested the add-spngsave libvips branch with 0.7.2 and it seems fine, let's merge
John Cupitt
@jcupitt
... spng save merged! I updated the meson build system too
Kleis Auke Wolthuizen
@kleisauke

Which tool was used to generate the graphic?
Originally posted by @randy408 in https://github.com/w3c/PNG-spec/issues/55#issuecomment-996230686

Given the standard colors and the legend, I think it's Microsoft Excel (I'm not the author of those graphs, so I thought I'd post it here).

Devon Sookhoo
@dukesook

I want to write a png image that is 16-bits grayscale no alpha channel. Here is the format enum:
enum spng_format {
SPNG_FMT_RGBA8 = 1,
SPNG_FMT_RGBA16 = 2,
SPNG_FMT_RGB8 = 4,

/* Partially implemented, see documentation */
SPNG_FMT_GA8 = 16,
SPNG_FMT_GA16 = 32,
SPNG_FMT_G8 = 64,

/* No conversion or scaling */
SPNG_FMT_PNG = 256, /* host-endian */
SPNG_FMT_RAW = 512  /* big-endian */

};

I don't see SPNG_FMT_G16 listed. Is this not supported by libspng?

John Cupitt
@jcupitt
Just set SPNG_FMT_PNG, bitdepth 16, color_type = SPNG_COLOR_TYPE_GRAYSCALE and give spng_encode_row() ushort pixels.
F. Nedelec
@nedelec

Hello, I have using SPNG to encode an image that I get from OpenGL's glReadPixels() and the result is flipped in the vertical direction.
I could fix that by moving all the pixels around, but that does not seem like a great idea.
So instead, I hacked spng_encode_image() like this:

    do {
    #if 0
             size_t ioffset = ri->row_num * ctx->image_width;
    #else
            // this will flip the image vertically
            size_t ioffset = ( ihdr->height - ri->row_num - 1 ) * ctx->image_width;
    #endif
             ret = encode_row(ctx, (unsigned char*)img + ioffset, ctx->image_width);
    }while(!ret);

and it works ... perhaps you would consider adding an option to perform this flipping in a cleaner way?
Or maybe you know a better way to achieve the same thing?
In any case, this works well and SPNG makes our life easier, saving us from installing libpng. Thank you so much!

John Cupitt
@jcupitt
I handle this by calling spng_encode_row() rather than spng_encode_image() --- you can just pass the scanline pointers in reverse order
In my experience almost all imaging libraries store data top to bottom, so GL is an extreme outlier here
I doubt if it's worth having a special mode just for this case
F. Nedelec
@nedelec
It's your call, but it was certainly easier for me to do this than anything else! I have pushed a request going with the modifications (3 lines)
There are 150 lines of code in spng_encode_image() before spng_encode_row() is finally called, and I certainly do not want to copy that.