bkaradzic / bimg Goto Github PK

I noticed a mismatched #pragma warning(push) #pragma warning(pop) in tinyexr.h regarding the MINIZ_HEADER_FILE_ONLY macro on a Win build:

tinyexr.h
1891 #ifndef MINIZ_HEADER_FILE_ONLY
...
4453 #pragma warning(push)
...
6925 #endif // MINIZ_HEADER_FILE_ONLY
...
6961 #pragma warning(pop) <--- that should be in the MINIZ_HEADER_FILE_ONLY scope

https://github.com/bkaradzic/bimg/blob/master/src/image_decode.cpp#L110

Example image: https://tile.openstreetmap.org//5/13/13.png

The image is only 1bit bitdepth, but the colortype is LCT_PALETTE

Might be better to switch on colortype then bitdepth

Output from pnginfo

13.png...
  Image Width: 256 Image Length: 256
  Bitdepth (Bits/Sample): 1
  Channels (Samples/Pixel): 1
  Pixel depth (Pixel Depth): 1
  Colour Type (Photometric Interpretation): PALETTED COLOUR (1 colours, 0 transparent)
  Image filter: Single row per byte filter
  Interlacing: No interlacing
  Compression Scheme: Deflate method 8, 32k window
  Resolution: 0, 0 (unit unknown)
  FillOrder: msb-to-lsb
  Byte Order: Network (Big Endian)
  Number of text strings: 0

Whilst attempting to build bgfx using mingw-gcc-release64 and, as a result, the associated bimg_encode dependency, an error occurs due to the recent commit 03ad392 adding new third-party sources.

In file included from ../../../../bimg/3rdparty/astc/astc_codec_internals.h:22:0,
from ../../../../bimg/3rdparty/astc/astc_averages_and_directions.cpp:17:
../../../../bimg/3rdparty/astc/mathlib.h:30:7: warning: "_MSC_VER" is not defined [-Wundef]
#if (!_MSC_VER) && (__cplusplus < 201103L)
^~~~~~~~
In file included from /usr/lib/gcc/x86_64-w64-mingw32/6.3-win32/include/c++/cmath:45:0,
from /usr/lib/gcc/x86_64-w64-mingw32/6.3-win32/include/c++/math.h:36,
from ../../../../bimg/3rdparty/astc/astc_averages_and_directions.cpp:19:
/usr/share/mingw-w64/include/math.h: In function ‘int __isnanl(long double)’:
/usr/share/mingw-w64/include/math.h:573:65: error: lvalue required as left operand of assignment
xx = (int) (ld.ldt->lh.low | (ld.ldt->lh.high & 0x7fffffffu)); /* explicit */
^

Unsure whether this is a bug in MinGW or improper use of the headers - it is preventing the build either way and the only non-intrusive solution is to rollback to an older version.

According to my mesurements and a couple of other people - lodepng is way slower than stb and libpng in both with/without optimizations its actually 2-3 times slower. Is there a reason why are you using it over stb?

error C2039: “vec3Norm”: 不是“bx”的成员

https://github.com/fish2000/homebrew-praxa/blob/master/bimg.rb

… notes and/or PRs are always welcome. Cheers!

Build a texturec in debug mode, and use this command line:

texturec.exe -f d:/test.png -o d:/main.dds -t BC3 -q fastest --max 256 -m

It will cause assert in stb_image_resize.h:
https://github.com/bkaradzic/bimg/blob/master/3rdparty/stb/stb_image_resize.h#L1106

I try to update stb_image_resize.h from:
https://github.com/nothings/stb/blob/master/deprecated/stb_image_resize.h

It fix this issue.

OS: Win7 64 bits 6.1.7601 Service Pack 1 Build 7601
Compilers ( I tried both)
VS 2015 (Version 14.0.25431.01 Update 3)
VS 2017 (Version 15.7.3 VisualStudio.15.Release/15.7.3+27703.2026)

bimg: 56315c6
bx: 628b81ffec80eeb33fa4b723369e558b237e4f0b
bgfx: fbc572ee12268c5b1e42e4f94f75b3b793125e02

I compiled everything with examples using Genie.
Then, I just run some examples. Several crash with some memory corruption errors.
For instance example-16-shadowmaps crashes with the following callstack on debug:
*** Main thread ***

example-16-shadowmapsDebug.exe!free_dbg_nolock(void * const block, const int block_use) Line 940 C++
example-16-shadowmapsDebug.exe!_free_dbg(void * block, int block_use) Line 1011 C++
example-16-shadowmapsDebug.exe!free(void * block) Line 16 C++
example-16-shadowmapsDebug.exe!bx::DefaultAllocator::realloc(void * _ptr, unsigned int _size, unsigned int _align, const char * _file, unsigned int _line) Line 33 C++
example-16-shadowmapsDebug.exe!bimg::imageFree(bimg::ImageContainer * _imageContainer) Line 2923 C++
example-16-shadowmapsDebug.exe!imageReleaseCb(void * _ptr, void * _userData) Line 158 C++
example-16-shadowmapsDebug.exe!bgfx::release(const bgfx::Memory * _mem) Line 3379 C++
example-16-shadowmapsDebug.exe!bgfx::Context::rendererExecCommands(bgfx::CommandBuffer & _cmdbuf) Line 2534 C++
example-16-shadowmapsDebug.exe!bgfx::Context::renderFrame(int _msecs) Line 1900 C++
example-16-shadowmapsDebug.exe!bgfx::renderFrame(int _msecs) Line 1096 C++
example-16-shadowmapsDebug.exe!entry::Context::run(int _argc, const char * const * _argv) Line 519 C++

*** Worker Thread example-16-shadowmapsDebug.exe!bx::ThreadInternal::threadFunc�() example-16-shadowmapsDebug.exe!bx::Semaphore::wait Normal ***

example-16-shadowmapsDebug.exe!bx::Semaphore::wait(int _msecs) Line 269 C++
example-16-shadowmapsDebug.exe!bgfx::Context::renderSemWait() Line 4577 C++
example-16-shadowmapsDebug.exe!bgfx::Context::frame(bool _capture) Line 1793 C++
example-16-shadowmapsDebug.exe!bgfx::frame(bool _capture) Line 3309 C++
example-16-shadowmapsDebug.exe!`anonymous namespace'::ExampleShadowmaps::update() Line 3215 C++
example-16-shadowmapsDebug.exe!entry::runApp(entry::AppI * _app, int _argc, const char * const * _argv) Line 523 C++
example-16-shadowmapsDebug.exe!main(int _argc, char * * _argv) Line 3264 C++
example-16-shadowmapsDebug.exe!entry::main(int _argc, const char * const * _argv) Line 626 C++
example-16-shadowmapsDebug.exe!entry::MainThreadEntry::threadFunc(bx::Thread * __formal, void * _userData) Line 1138 C++
example-16-shadowmapsDebug.exe!bx::Thread::entry() Line 294 C++
example-16-shadowmapsDebug.exe!bx::ThreadInternal::threadFunc(void * _arg) Line 77 C++

If I revert 56315c6, it works.
Cheers,
Ben

When encoding a 256x256 n.png with astc6x6 format, the size is changed to 258x258 (for 6x6 alignment)

texturec -f n.png -o n.ktx -t astc6x6

And it may cause segment fault because of accessing memory beyond boundary. See #28 . My solution is not suitable， but I need a correct solution. Our tool chain is broken because of it.

I think the texturec should remain the original size (256x256) for astc6x6 format like astcenc.exe does ( https://github.com/ARM-software/astc-encoder/blob/master/Binary/windows-x64/astcenc.exe ) .

According to https://www.khronos.org/registry/OpenGL/extensions/OES/OES_texture_compression_astc.txt

For images which are not an integer multiple of the block size, additional texels are added to the edges with maximum X and Y (and Z for 3D textures). These texels may be any color, as they will not be accessed.

Although these are not all powers of two, it is possible to calculate block addresses and pixel addresses within the block, for legal image sizes, without undue complexity.

We may remain width 256 and height 256 in .ktx file header in this case. But now, it's 258.

@andrewwillmott

When loading KTX files that contain RGBA_SRGB data, parseFnT in image.cpp will correctly identify the srgb type and set it to true. However, the next step in imageParseT creates the output image container and makes no effort to copy this parameter to the output image. The contents of the file are loaded using memcpys, so no data transform occurs, the meta data is simply lost.

if (!parseFnT(imageContainer, &reader, _err) )        /// <<< ======= image container has srgb set
{
	return NULL;
}

ImageContainer* output = imageAlloc(_allocator        /// <<< ======= output does not
	, imageContainer.m_format
	, uint16_t(imageContainer.m_width)
	, uint16_t(imageContainer.m_height)
	, uint16_t(imageContainer.m_depth)
	, imageContainer.m_numLayers
	, imageContainer.m_cubeMap
	, 1 < imageContainer.m_numMips
);

Hi there!

Just got curious why bimg depends on both these libraries while stb_image handles PNG files quite well.

The implementations has another uint32_t for the num_layers which is missing in the header.

Hi, I spoke with you on the discord channel about this issue. I'm getting a runtime error in memcpy stemming from bimg::ImageParseDds(). Here is a sample DDS file which has this issue.

test.dds.zip

load ktx2 texture error. How to solve this problem?

pipes.zip
This image clearly shows the artifacts.

One problem seems to be the incorrect punchthrough flag. According to the specs (table 173) it is at bit 32.
https://www.khronos.org/registry/DataFormat/specs/1.3/dataformat.1.3.html#_format_pvrtc1_4bpp

Current values are (bc[7]&1) which is bit 56.

Other problem is that with punchthrough:
"If punch-through mode is selected, and the modulation bits for a given pixel have a value of 0b10, the alpha value of the resulting color is 0x00. This is irrespective of the presence or values of any alpha channel in the input colors."

image decoder uses s_pvrtcWeights table for weights. Outputting 0 can be implemented by settings alpha weights to 0 when punchtrough is on and modulation is 0b10.

bkaradzic/bgfx#792

If an ImageContainer has a non-default (R0) m_orientation and is passed into imageConvert, the returned ImageContainer does not retain the same m_orientation and as a result the image will be misinterpretted by consumers that respect the orientation (e.g. rotating and/or flipping the image data when loading it into a texture in bgfx). I am guessing this is a just a bug/oversight?

The first overload of imageWriteKtx() is writting the image content layer by layer, but still passing the size of the whole image for each one (link to source):

total += bx::write(_writer, src, size, _err);
src += size;

Those lines should be:

total += bx::write(_writer, src, mipSize, _err);
src += mipSize;

(The 2nd overload is correct in this regard)

Morton offset should take texture dimensions into account see reflectedMortonOffset function:

https://www.khronos.org/registry/DataFormat/specs/1.3/dataformat.1.3.html#_format_pvrtc1_4bpp

Current implementation https://github.com/bkaradzic/bimg/blob/master/src/image.cpp#L2973 causes crashes/incorrect textures for non-square textures.

I can send PR with the function in specs, but current implementation seems more optimized.

我在使用image_decode.cpp中的imageParse方法解析png图片遇到问题。
问题原因：

ImageContainer* input = imageParseDds     (_allocator, _data, _size, _err)        ;
		input = NULL == input ? imageParseKtx     (_allocator, _data, _size, _err) : input;
		input = NULL == input ? imageParsePvr3    (_allocator, _data, _size, _err) : input;
		input = NULL == input ? imageParseGnf     (_allocator, _data, _size, _err) : input;
		input = NULL == input ? imageParseLodePng (_allocator, _data, _size, _err) : input;
		input = NULL == input ? imageParseTinyExr (_allocator, _data, _size, _err) : input;
		input = NULL == input ? imageParseJpeg    (_allocator, _data, _size, _err) : input;
		input = NULL == input ? imageParseStbImage(_allocator, _data, _size, _err) : input;

在执行imageParseLodePng方法前，_err因为不是其他格式被设置错误

BX_ERROR_SET(_err, BIMG_ERROR, "Invalid header magic.");

imageParseLodePng执行完之后，_err还是存在，没有被重置，导致错误。

--- Google translate ---

I'm having trouble parsing png images using the imageParse method in image_decode.cpp.
problem causes:

ImageContainer * input = imageParseDds (_allocator, _data, _size, _err);
input = NULL == input? imageParseKtx (_allocator, _data, _size, _err): input;
input = NULL == input? imageParsePvr3 (_allocator, _data, _size, _err): input;
input = NULL == input? imageParseGnf (_allocator, _data, _size, _err): input;
input = NULL == input? imageParseLodePng (_allocator, _data, _size, _err): input;
input = NULL == input? imageParseTinyExr (_allocator, _data, _size, _err): input;
input = NULL == input? imageParseJpeg (_allocator, _data, _size, _err): input;
input = NULL == input? imageParseStbImage (_allocator, _data, _size, _err): input;

Before executing the imageParseLodePng method, _err was set incorrectly because it is not in another format

BX_ERROR_SET (_err, BIMG_ERROR, "Invalid header magic.");

After imageParseLodePng is executed, _err still exists and has not been reset, resulting in an error.

I was trying to build bgfx with the mingw-gcc-release64 target, but it failed with the following error:

In file included from C:/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/cmath:45,
                 from C:/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/math.h:36,
                 from ../../../../bimg/3rdparty/astc/astc_averages_and_directions.cpp:19:
C:/mingw64/x86_64-w64-mingw32/include/math.h: In function 'int __isnanl(long double)':
C:/mingw64/x86_64-w64-mingw32/include/math.h:573:65: error: lvalue required as left operand of assignment
     xx = (int) (ld.ldt->lh.low | (ld.ldt->lh.high & 0x7fffffffu)); /* explicit */
                                                                 ^
make[2]: *** [bimg_encode.make:713: ../../win64_mingw-gcc/obj/x64/Release/bimg_encode/bimg/3rdparty/astc/astc_averages_and_directions.o] Error 1
make[1]: *** [Makefile:33: bimg_encode] Error 2
make[1]: Leaving directory 'E:/repositories/bgfx/bgfx/.build/projects/gmake-mingw-gcc'
make: *** [makefile:125: mingw-gcc-release64] Error 2

Don't know, if this is a MinGW issue or not, but in a past issue a similar (?) error has been fixed in this repo.

Before trying to build the release target, it built mingw-gcc-debug64 without errors by the way.

Unlike bx and bgfx, there's no amalgamated build for this project. This makes it hard to integrate new bgfx versions into my build system since bgfx now includes bimg.

I have a BC3 format texture with mipmaps, and I want to convert it to RGBA32F format with mipmaps. It will cause memory writen out of bounds (The texture I tested is attached in this issue).

Compile texturec tools, and run this command line:
> texturecDebug -f {yourdir}/test_BC3.dds -o {outputdir}/out_RGBA32F.dds -t RGBA32F -q fastest --mips

It will throw an exception in this code line:
https://github.com/bkaradzic/bimg/blob/master/src/image.cpp#LL4465C32-L4465C32

(The heap is broken right now)

The reason I found in the code:
https://github.com/bkaradzic/bimg/blob/master/src/image.cpp#L1284

The attach file is BC3 format with mipmaps, it's resolution is 8x8. In mip level 2, the resolution should be 2x2, but the lowest block size of BC3 format is 4x4, so imageGetRawData function return m_width and m_height in var mip are 4. But RGBA32F format resolution in mip level 2 must be 2x2, then it will cause memory writen out of bounds.

test_BC3.zip

please add support for ETC2A and ETC2A1 texture formats