bkaradzic / bimg Goto Github PK
View Code? Open in Web Editor NEWImage library.
License: BSD 2-Clause "Simplified" License
Image library.
License: BSD 2-Clause "Simplified" License
please add support for ETC2A and ETC2A1 texture formats
我在使用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.
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
);
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.
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?
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
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.
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.
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.
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.
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.
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.
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?
load ktx2 texture error. How to solve this problem?
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
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.
Line 3044 in 82738cd
Line 3152 in 82738cd
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.
Line 2969 in 82738cd
{ 4, 4, 0, 0 },
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.
error C2039: “vec3Norm”: 不是“bx”的成员
https://github.com/fish2000/homebrew-praxa/blob/master/bimg.rb
… notes and/or PRs are always welcome. Cheers!
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)
Line 486 in 0fb7ef5
The implementations has another uint32_t for the num_layers which is missing in the header.
Hi there!
Just got curious why bimg
depends on both these libraries while stb_image
handles PNG files quite well.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.