#1
Posted
:
Monday, October 23, 2017 12:34:47 PM(UTC)
Groups: Registered
Posts: 5
We recently moved from v16.5 to v17 of LEADTOOLS (due to the issue in Forums post LEAD:00330828) and are not encountering an issue with transparent png files in v17.
I have a very basic console app which just calls L_LoadBitmapMemory or L_LoadBitmap to load the file (I tried both ways) and then L_SaveBitmap to save the result.
input file:
saved from 16, the transparency isn't preserved, as expected, but the general image is close:
v17 using 24 for nBitsPerPixel (even though the source is 32 bit) :
nBitsPerPixel=32
nBitsPerPixel = 0 (looks like the result file is 8-bit? I would expect it to match the source file)
if attaching my sample application would be helpful, i can do that as well.
after loading the file, i also tried L_BitmapHasMeaningfulAlpha which returns false which is not what i would have expected but i'm not certain that it is related to the issue.
If i use a 24bit bmp with nBitsPerPixel = 0 I get a 24 bit file and it looks as expected.
I am also seeing similar issues with this as the source file:
#2
Posted
:
Monday, October 23, 2017 4:26:47 PM(UTC)
Groups: Registered, Tech Support, Administrators
Posts: 199
Was thanked: 28 time(s) in 28 post(s)
Transparency is only supported in 32-bit PNG. You probably just need to add the following flags to your LoadFileOptions in the L_LoadBitmap call: ELO_ALPHAINIT and ELO_PREMULTIPLY_ALPHA (you can see the docs about these here
https://www.leadtools.com/help/leadtools/v19/main/api/loadfileoption.html). I ran some tests with the file you attached with various bits-per-pixel (both input and output), here were my results: (“result_IN_OUT.png” where IN is the input bits-per-pixel and OUT is the output bits-per-pixel)
And here are the results using the Google logo (to test transparency as you mentioned).
The only files with transparency were result_00_32.png and result_32_32.png (the other 32-bit outputs [8/16/24 input] seemed to fail). Here’s a code snippet of what I did for those images:
Code:
L_INT nRet;
BITMAPHANDLE bitmap;
int inBits = 0;
int outBits = 32;
wchar_t name[17];
for (inBits = 0; inBits <= 32; inBits += 8) {
for (outBits = 0; outBits <= 32; outBits += 8) {
wsprintf(name, L"result_%0d_%0d.png", inBits, outBits);
nRet = L_LoadBitmap(TEXT("Map.png"), &bitmap, sizeof(BITMAPHANDLE),
inBits, ORDER_BGRORGRAYORROMM, NULL, NULL);
if (nRet != SUCCESS)
continue;
L_SaveBitmap(name, &bitmap, FILE_PNG, outBits, 0, NULL);
L_FreeBitmap(&bitmap);
}
}
If those options didn’t work, you can attach the small sample you mentioned and I’ll see if I can figure it out an alternative solution.
Anthony Northrup
Developer Support Engineer
LEAD Technologies, Inc.
#3
Posted
:
Tuesday, October 24, 2017 8:25:41 AM(UTC)
Groups: Registered
Posts: 5
Hi Anthony,
are you using v17 with that output?
ELO_PREMULTIPLY_ALPHA appears to require v18+
Code:
#if defined(LEADTOOLS_V18_OR_LATER)
#define ELO_PREMULTIPLY_ALPHA 0x40000000 // When loading images with alpha channel, premultiply the alpha and apply it to the image data.
#endif // #if defined(LEADTOOLS_V18_OR_LATER)
ELO_ALPHAINIT did not seem to have any effect, which is consistent with the documentation since i am using default load options, it should have been applied (and does not pertain to PNG files anyway)
"The default value for LOADFILEOPTION.Flags includes this flag.
This flag is ignored when loading the following formats:
..
FILE_PNG
..."
here's the sample code i'm running with V17:
Code:
#include "stdafx.h"
#include "stdio.h"
#include "iostream"
#define LTV17_CONFIG
#include "l_Bitmap.h"
#include "Ltfil.h"
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
char *filePath = "c:\\temp\\Sofia_Full_City_Map.png";
L_TCHAR *outFilePath = "c:\\temp\\afterSofia_Full_City_Map32.png";
BITMAPHANDLE bitmapHandle;
FILEINFO fileInfo;
L_INT nBitsPerPixel = 32;
L_INT result;
ZeroMemory(&bitmapHandle, sizeof(bitmapHandle));
ZeroMemory(&fileInfo, sizeof(fileInfo));
result = L_LoadBitmap(filePath, &bitmapHandle, sizeof(BITMAPHANDLE), nBitsPerPixel, ORDER_RGB, NULL, &fileInfo);
result = L_SaveBitmap(outFilePath, &bitmapHandle, FILE_PNG, nBitsPerPixel, 9, NULL);
L_FreeBitmap(&bitmapHandle);
return 0;
}
#4
Posted
:
Tuesday, October 24, 2017 2:15:08 PM(UTC)
Groups: Registered, Tech Support, Administrators
Posts: 199
Was thanked: 28 time(s) in 28 post(s)
I was using v17 for the code and outputs I showed previously, I just looked at the v19 documentation by mistake. You are zeroing out the memory for the BITMAPHANDLE and the FILEINFO, but not setting the uStructSize field after. Here's a snippet from the BITMAPHANDLE docs page (
v17 docs) "You must set the uStructSize member to the total size, in bytes, of the structure. Use the sizeof() macro to calculate this value." Once you zero out, just set the size:
Code:
ZeroMemory(&bitmapHandle, sizeof(BITMAPHANDLE));
bitmapHandle.uStructSize = sizeof(BITMAPHANDLE);
ZeroMemory(&fileInfo, sizeof(FILEINFO));
fileInfo.uStructSize = sizeof(FILEINFO);
I was able to get the program to run and output the file once I changed the code above. And once again, I tested with the Google logo and the transparency is preserved.
Anthony Northrup
Developer Support Engineer
LEAD Technologies, Inc.
#5
Posted
:
Tuesday, October 24, 2017 3:00:17 PM(UTC)
Groups: Registered
Posts: 5
Hi Anthony,
I am now setting the struct size for both, but I see the same output. Can i send you the executable and assemblies i'm using to see if you can reproduce it just running the sample application as built?
#6
Posted
:
Wednesday, October 25, 2017 8:32:08 AM(UTC)
Groups: Registered, Tech Support, Administrators
Posts: 199
Was thanked: 28 time(s) in 28 post(s)
Go ahead and send those, the Visual Studio solution would also be great (assuming that's what you built it with). If you're doing command-line compilation, if you could send the source with the compiler calls that would be helpful. Hopefully we can figure this out.
Edited by moderator Thursday, October 26, 2017 9:18:38 AM(UTC)
| Reason: Not specified
Anthony Northrup
Developer Support Engineer
LEAD Technologies, Inc.
#7
Posted
:
Thursday, October 26, 2017 8:58:07 AM(UTC)
Groups: Registered
Posts: 5
What is the best way to send the files? via ftp? the ftp login credentials I have from the last time support sent me files do not seem to have view/write privileges to the upload dir.
#8
Posted
:
Thursday, October 26, 2017 9:24:21 AM(UTC)
Groups: Registered, Tech Support, Administrators
Posts: 199
Was thanked: 28 time(s) in 28 post(s)
You should be able to attach them to your reply similar to how you attached the image in your first post. You can remove any dlls before zipping to reduce the file size, just let me know which ones I should copy.
Anthony Northrup
Developer Support Engineer
LEAD Technologies, Inc.
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.