Firstly, thank you very much for your contribution and making your source code available for the public. I have been building the MtfMapper files with my own project in Visual Studio. I noticed that there are two places where I have to modify the code to build properly. The first is within tiffsniff.h:
adding the name icc_tag here => typedef struct icc_tag { prevents a compile error.
The second is within tiffsniff.cc:
//#include "config.h"
Can this be placed within the #if mtfmapper_ZLIB_FOUND == 1 block?
I am guessing this is for a dependency I don't have, but these are the only two places I need to modify to build the code.
Thanks,
-Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that both the issues you describe are due to the fact that I build MTF Mapper on Windows using the solution file generated by cmake, whereas it sounds as if you are including MTF Mapper source files into your own independent VS solution / project.
The "typedef struct icc_tag {" error is possibly caused by the compiler language standard setting on your project. I usually build MTF Mapper with the compiler set to the C++11 standard (but I recently bumped it to C++17). I am booted into Linux right now, so I cannot check to see if this is the exact cause when using VS, but that is my best guess.
Reading up on the issue, it seems like there are two different namespaces, even going back to C ("tag namespace", and "ordinary identifiers"). It looks like I am creating an anonymous struct in the tag namespace, and immediately typedef-ing it. This may be a problem with the C++20 standard (see here), so perhaps I will have to update the code for future compatibility. But at least we know that this will not cause any runtime issues, you just have to get past the compiler :)
The other issue is related to the "config.h" file created by cmake. I mostly use the config file to specify MTF Mapper versions, but if you have ZLIB available at cmake-configuration time, then it will set up the project to use ZLIB, which adds the line #define mtfmapper_ZLIB_FOUND 1
to config.h. So you cannot move the #include "config.h" into the #if block.
Perhaps the simplest solution is to just add a mostly empty config.h to your project, then you do not have to modify tiffsniff.h, which might make it easier in future to merge newer MTF Mapper revisions.
Just for completeness: the tiffsniff code will read the ICC profile of the input file, if present, to extract the tone response curve (TRC), which MTF Mapper will use to linearize the image intensity if necessary. PNG files store their ICC profiles in a block that is compressed with the DEFLATE method, which is why I need ZLIB to decompress said block. If you don't have ZLIB in your project, and you do not have mtfmapper_ZLIB_FOUND defined, then MTF Mapper will not attempt to extract ICC profiles from PNG files. Other supported formats (TIFF, and JPEG) should still have full ICC functionality.
Regards,
Frans
ps: just out of interest, are you allowed to say what you are linking MTF Mapper into?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are correct - I am building using an independent Visual Studio
project. I am building a DLL so that I am able to use the functionality of
mtfmapper from images that are already loaded into memory, so that I am
able to operate without using files to improve processing time. Thanks for
your excellent explanation. I am not sure why I didn't think of the empty
config.h file - that is a good option, although I was worried that I was
missing something else.
I think that both the issues you describe are due to the fact that I build
MTF Mapper on Windows using the solution file generated by cmake, whereas
it sounds as if you are including MTF Mapper source files into your own
independent VS solution / project.
The "typedef struct icc_tag {" error is possibly caused by the compiler
language standard setting on your project. I usually build MTF Mapper with
the compiler set to the C++11 standard (but I recently bumped it to C++17).
I am booted into Linux right now, so I cannot check to see if this is the
exact cause when using VS, but that is my best guess.
Reading up on the issue, it seems like there are two different namespaces,
even going back to C ("tag namespace", and "ordinary identifiers"). It
looks like I am creating an anonymous struct in the tag namespace, and
immediately typedef-ing it. This may be a problem with the C++20 standard
(see here https://en.cppreference.com/w/cpp/language/typedef), so
perhaps I will have to update the code for future compatibility. But at
least we know that this will not cause any runtime issues, you just have to
get past the compiler :)
The other issue is related to the "config.h" file created by cmake. I
mostly use the config file to specify MTF Mapper versions, but if you have
ZLIB available at cmake-configuration time, then it will set up the project
to use ZLIB, which adds the line
define mtfmapper_ZLIB_FOUND 1
to config.h. So you cannot move the #include "config.h" into the #if block.
Perhaps the simplest solution is to just add a mostly empty config.h to
your project, then you do not have to modify tiffsniff.h, which might make
it easier in future to merge newer MTF Mapper revisions.
Just for completeness: the tiffsniff code will read the ICC profile of the
input file, if present, to extract the tone response curve (TRC), which MTF
Mapper will use to linearize the image intensity if necessary. PNG files
store their ICC profiles in a block that is compressed with the DEFLATE
method, which is why I need ZLIB to decompress said block. If you don't
have ZLIB in your project, and you do not have mtfmapper_ZLIB_FOUND
defined, then MTF Mapper will not attempt to extract ICC profiles from PNG
files. Other supported formats (TIFF, and JPEG) should still have full ICC
functionality.
Regards,
Frans
ps: just out of interest, are you allowed to say what you are linking MTF
Mapper into?
Good day. I have gotten everything to run, but I now have a run-time error on a file that runs on the CLI version 0.7.32. The issue is caused by an assert on line 625 of mtf_core: assert(fabs(magnitude[0] - 1.0) < 1e-6); magnitude[0] = 0.9, so it is clearly not as close to 1 as it should be. Is there some default parameter that I am missing, perhaps?
I am feeding in:
tc_wdir.setValue(".");
tc_linear.setValue(1);
tc_edges.setValue(1);
tc_annotate.setValue(1);
tc_thresh.setValue(0.25);
tc_checkerboard.setValue(1);
tc_surface.setValue(1);
tc_gnuplot.setValue("C:\Program Files\MTF Mapper\bin\gnuplot\gnuplot.exe");
It also happens if I am only setting wdir and checkerboard, but the value is slightly different.
Thanks,
-Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are building your project in a Debug mode, then the assert() statements will be enabled, causing that particular line to abort the program. The Windows binaries that I release are compiled in Release mode, which means the assert() statements are simply ignored (more like 'not there'), so the CLI version will happily allow a magnitude[0] = 0.9 to pass through without checking if it is close to 1.0.
Two practical solutions come to mind:
1. add the NDEBUG pre-processor definition to your Debug build properties (but this will disable all asserts() in your project), or
2. Simply comment out the offending line (625) in mtf_core.
That will help cover up the problem in the same way that a tweed coat is good for dandruff :)
The underlying problem may be a bit harder to solve. I would recommend that you follow one of the two steps above, and then look at the "edge_sfr_values.txt" output produced by the tc_edges flag. You should be able it locate the offending edge, and see what the SFR curve of said edge looks like.
I have seen this particular error before, but I cannot recall what the origin of the error is. It may be something obvious, like MTF Mapper trying to extract an SFR of something in the background, or some other objects on your test chart falling within the ROI of a valid edge. (normally MTF Mapper can tolerate some interference between objects on the chart, but there are limits).
Or it could be that the targets are a bit small. With a checkerboard, you want the individual squares to be at least 25 pixels a side (the minimum just to get some output), but preferably the squares should be larger than 35 pixels to avoid issues with the edge ROI overlapping with the next square.
If it is not one of those issues, and it is not immediately clear why the SFR is bad (0.9 at 0 frequency is not normal), you are welcome to send me a sample. I will try my level best to take a look at it soon (ish). (you can send to fvdbergh@gmail.com if you do not want to post here).
Regards,
Frans
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Firstly, thank you very much for your contribution and making your source code available for the public. I have been building the MtfMapper files with my own project in Visual Studio. I noticed that there are two places where I have to modify the code to build properly. The first is within tiffsniff.h:
adding the name icc_tag here => typedef struct icc_tag { prevents a compile error.
The second is within tiffsniff.cc:
//#include "config.h"
Can this be placed within the #if mtfmapper_ZLIB_FOUND == 1 block?
I am guessing this is for a dependency I don't have, but these are the only two places I need to modify to build the code.
Thanks,
-Kevin
Hi Kevin,
I think that both the issues you describe are due to the fact that I build MTF Mapper on Windows using the solution file generated by cmake, whereas it sounds as if you are including MTF Mapper source files into your own independent VS solution / project.
The "typedef struct icc_tag {" error is possibly caused by the compiler language standard setting on your project. I usually build MTF Mapper with the compiler set to the C++11 standard (but I recently bumped it to C++17). I am booted into Linux right now, so I cannot check to see if this is the exact cause when using VS, but that is my best guess.
Reading up on the issue, it seems like there are two different namespaces, even going back to C ("tag namespace", and "ordinary identifiers"). It looks like I am creating an anonymous struct in the tag namespace, and immediately typedef-ing it. This may be a problem with the C++20 standard (see here), so perhaps I will have to update the code for future compatibility. But at least we know that this will not cause any runtime issues, you just have to get past the compiler :)
The other issue is related to the "config.h" file created by cmake. I mostly use the config file to specify MTF Mapper versions, but if you have ZLIB available at cmake-configuration time, then it will set up the project to use ZLIB, which adds the line
#define mtfmapper_ZLIB_FOUND 1to config.h. So you cannot move the #include "config.h" into the #if block.
Perhaps the simplest solution is to just add a mostly empty config.h to your project, then you do not have to modify tiffsniff.h, which might make it easier in future to merge newer MTF Mapper revisions.
Just for completeness: the tiffsniff code will read the ICC profile of the input file, if present, to extract the tone response curve (TRC), which MTF Mapper will use to linearize the image intensity if necessary. PNG files store their ICC profiles in a block that is compressed with the DEFLATE method, which is why I need ZLIB to decompress said block. If you don't have ZLIB in your project, and you do not have mtfmapper_ZLIB_FOUND defined, then MTF Mapper will not attempt to extract ICC profiles from PNG files. Other supported formats (TIFF, and JPEG) should still have full ICC functionality.
Regards,
Frans
ps: just out of interest, are you allowed to say what you are linking MTF Mapper into?
Frans,
You are correct - I am building using an independent Visual Studio
project. I am building a DLL so that I am able to use the functionality of
mtfmapper from images that are already loaded into memory, so that I am
able to operate without using files to improve processing time. Thanks for
your excellent explanation. I am not sure why I didn't think of the empty
config.h file - that is a good option, although I was worried that I was
missing something else.
Thanks,
-Kevin
On Sun, Feb 28, 2021 at 10:05 AM Frans van den Bergh fvdbergh@users.sourceforge.net wrote:
Frans,
Good day. I have gotten everything to run, but I now have a run-time error on a file that runs on the CLI version 0.7.32. The issue is caused by an assert on line 625 of mtf_core: assert(fabs(magnitude[0] - 1.0) < 1e-6); magnitude[0] = 0.9, so it is clearly not as close to 1 as it should be. Is there some default parameter that I am missing, perhaps?
I am feeding in:
tc_wdir.setValue(".");
tc_linear.setValue(1);
tc_edges.setValue(1);
tc_annotate.setValue(1);
tc_thresh.setValue(0.25);
tc_checkerboard.setValue(1);
tc_surface.setValue(1);
tc_gnuplot.setValue("C:\Program Files\MTF Mapper\bin\gnuplot\gnuplot.exe");
It also happens if I am only setting wdir and checkerboard, but the value is slightly different.
Thanks,
-Kevin
Hi Kevin,
If you are building your project in a Debug mode, then the assert() statements will be enabled, causing that particular line to abort the program. The Windows binaries that I release are compiled in Release mode, which means the assert() statements are simply ignored (more like 'not there'), so the CLI version will happily allow a magnitude[0] = 0.9 to pass through without checking if it is close to 1.0.
Two practical solutions come to mind:
1. add the NDEBUG pre-processor definition to your Debug build properties (but this will disable all asserts() in your project), or
2. Simply comment out the offending line (625) in mtf_core.
That will help cover up the problem in the same way that a tweed coat is good for dandruff :)
The underlying problem may be a bit harder to solve. I would recommend that you follow one of the two steps above, and then look at the "edge_sfr_values.txt" output produced by the tc_edges flag. You should be able it locate the offending edge, and see what the SFR curve of said edge looks like.
I have seen this particular error before, but I cannot recall what the origin of the error is. It may be something obvious, like MTF Mapper trying to extract an SFR of something in the background, or some other objects on your test chart falling within the ROI of a valid edge. (normally MTF Mapper can tolerate some interference between objects on the chart, but there are limits).
Or it could be that the targets are a bit small. With a checkerboard, you want the individual squares to be at least 25 pixels a side (the minimum just to get some output), but preferably the squares should be larger than 35 pixels to avoid issues with the edge ROI overlapping with the next square.
If it is not one of those issues, and it is not immediately clear why the SFR is bad (0.9 at 0 frequency is not normal), you are welcome to send me a sample. I will try my level best to take a look at it soon (ish). (you can send to fvdbergh@gmail.com if you do not want to post here).
Regards,
Frans