Activity for Mihail Naydenov
-
Mihail Naydenov posted a comment on discussion Open Discussion
Is there a lib to use? If not this will be quite a lot of work.
-
@Johnny Petersen The original is in the zip 5d630284307d0a64696d10b26d13f6af.png
-
Can you copy the image then edit out the sensitive data (pixels/metadata) and upload it so we will have something to work with. Parsing TIFF tags is not a trivial task and we have to see what is going on.
-
Hi, undefined tags are not garbage in TIFF, they are simply unknown. Also even garbage icc profile should not make FreeImage crash. If you are able to preproduce the scenario with another image it will be great.
-
I have created https://github.com/mnaydenov/FreeImage-Sidecar as a small "add-on" library to load HEIF and AVIF. Because of the restrictive FreeImage license, which is not compatible with LGPL, I was forced to make the plugin stand alone and not as a path to FreeImage.
-
Hello, I have created https://github.com/mnaydenov/FreeImage-Sidecar which is a small "add-on" (to FreeImage) library to load HEIF and AVIF. It is basically just a wrapper for a single plugin file that loads both. Because of the restrictive FreeImage license, which is not compatible with LGPL (the license of libhief), I was forced to make the plugin stand alone and not as a path to FreeImage.
-
This is very interesting. Where exactly does it overflow. You changed many unsigned to size_t, but this way we mask the issue. Can you please add a comment where the size_t is required to draw attention, please!
-
Hi, looking at the code, FreeImage_ConvertToGreyscale does not work with FIT_RGB16 images. If you don't care about 16bit color, convert first to FIT_BITMAP, then run ConvertToGrayscale. If you do care about 16bit, I think you can simply convert to FIT_UINT16
-
Are you sure Plus is build, because it is a separate project. Also note Plus is a bit dated in many aspects.
-
RAII for easier memory management
-
If you know cmake good enough to make it do what you need, I have a FreeImage version that uses cmake. It does not export/install a package that you can use directly, so it will be only a starting point for you. https://github.com/mnaydenov/FreeImage-Adv/tree/master Read the readme because the are multiple branches "with different things".
-
Considering freeimage does not have cmake support in this main repo, I guess you are using some package from a third party. May be you should ask the people that created it?
-
Well, in any case it is inconsistent, you can file a bug and please attach the images. Does at least checking the profile works?
-
GetColorType is not very reliable because the bitmap is 4 channel (C,M,Y,K) and it is not correctly initialized, thinking 4 channels is always RGBA. More reliable way is to test the profile FreeImage_GetICCProfile(dib)->flags & FIICC_COLOR_IS_CMYK. If the image does not have a profile, I am not sure if there is a reliable way to tell RGBA and CMYK apart. Still try the steps I wrote you - load, convert, save. If the source image is CMYK, it has a profile, and result is not CMYK, you might submit a...
-
Try ConvertToStandardType, then simply save the result as jpeg. The jpeg supports saving CMYK, hopefully ConvertToStandardType supports it also, but I am not sure. After you ConvertToStandardType you can check GetColorType to be sure after the conversion the image is still FIC_CMYK
-
Where is this libfreeimage.so.3 coming from?
-
"Patches always welcome", I guess :) Joke aside, no bounds checking is indeed wrong. Note that the bulk of FreeImage is written 20 years ago where the coding standards were not that high (for a mainstream, free library), not to mention availability of static sanitizers and alike.
-
Is your image CMYK? Is it CMYK and 16 bit? I don't think it can be both, because 16 bit is compression of RGB, each channel being 5,6,5 bits respectively. Or you are talking about 16bit per channel? In any case PSD_CMYK flag simply reserves the 4 channels if the image is already CMYK. PSD_DEFAULT will convert to RGB on load. If your image is 16 bit per channel, and is CMYK and you want to save it as JPEG, you first need to convert it to 8bit per channel because this is what JPEG can handle.
-
Is your image CMYK? Is it CMYK and 16 bit? I don't think it can be both, because 16 bit is compression of RGB, each channel being 5,6,5 bits respectively. Or you are talking about 16bit per channel? In any case PSD_CMYK flag simply reserves the 4 channels if the image is already CMYK. PSD_DEFAULT will convert to RGB on load. If your image is 16 bit per channel, and is CMYK and you want to save it as JPEG, you first need to convert it to 8bit per channel because this is what JPEG can handle.
-
I don't know, it is up to @drolon, I am not a maintainer. That being said, I have GitHub clone of FreeImage that probably includes this patch (can't remember honestly). https://github.com/mnaydenov/FreeImage-Adv If you are not afraid to compile from code, you can give it a try. (Read about the branches, because it is quite busy there!)
-
I am also maintaining cmake FreeImage at https://github.com/mnaydenov/FreeImage-Adv you can take a look. The main difference compared to all other similar clones is that it does not compile all files as one blob, but makes individual subdirectories for each library, adding or fixing CMakeLists for each subproject. Currently only the main lib is supported (no plus or tests)
-
PluginWebP fails to load exif
-
Here is a patch.
-
Bugfix for #299,#303,#304,#305,#308,#309,#310, #320
-
The attached gimp-red.bmp is not PNG compressed, according to its header, but BITFIELDS. At the moment FreeImage aborts loading, as only jpeng and png compressed BMPs are supported.
-
The bug is really silly. FreeImage expects single and duo channel images to be named "Y" ("gray/luminance") or "Yx" (x being any other channel that will be ignored) . Your image has a single channel named "R" as no channel Y is found and black is filled. Really silly, the fix is trivial - we can preserve the original channel name and request that. Now, a point must be made OpenEXR should have thrown some warning there is not such channel.
-
Also #298 is to be closed, which is a duplicate .
-
As of Jan 2021 I can't reproduce using MSVC ASAN. OpenEXR reports an image read error.
-
As of Jan 2021, can not reproduce on Windows ASAN. LoadPixelDataRLE8 is not called for that image. @drolon please, close
-
As of Jan 2021, can not reproduce on Windows ASAN. Image loading aborted early on. @drolon please, close
-
As of Jan 2021, can not reproduce on Windows ASAN. LoadPixelDataRLE8 is not called for that image.
-
As of Jan 2021, can not reproduce on Windows. LoadPixelDataRLE8 is not called for that image.
-
This also fixes #318
-
This also also fixes #318
-
Bugfix for bugs #306 #307 as well as problem from patch #139
-
Updated CMakeLists.txt. Replace the one in zip.
-
No profile is attached on new images. Old profile is copied when transforming existing ones. Some viewers might display a profile because they themselves have a default one to do color matching to the screen. As Johnny Petersen said - FreeImage does not deal w/ profiles beyond copying them around.
-
The internal FreeImage issues (the last two) are fixed in trunk. Examples no longer crash.
-
The internal FreeImage issues (the last two) are fixed on master. Examples no longer crash.
-
IIRC changing the license is hard, because the original authors are no longer involved and only they can do that.
-
CMake support patch
-
Thanks for reporting these. I will look into them at some point
-
Few patches from vspkg
-
This issue should be closed now.
-
This sounds a decent idea, considering we will also get libjpeg-turbo with it and how well maintained it is.
-
I will take a look at that again. I also played around some 10 years ago, but dropped it because it was not important enough for me at the time. In any case multipage is becoming more and more important w/ basically ALL modern formats having animation or burst-mode in them.
-
Looks like libheif can handle both AVIF and HEIF, why use libavif?
-
Does this improve the overall performance of the loader? In my experience the GIF loading is quite slow. I haven't profiled it, but the std::string manipulations might have something to do with it.
-
This is nice, but we also need to incorporate libavif in some way as well. Other then that, I am not sure how correct it is to modify the source image on save - do other plugins do that? This is not thread safe - save should be a "const" operation. Is there a line-by-line API in libavif? This would be the correct way to save upside-down, other then creating a copy of course.
-
I checked my local copy of FreeImage and there both loadRLE and loadTrueColor accept FIBITMAP*&, not just a pointer, which solves the issue as well. I am not sure when this error was introduced (and/or solved in my copy). In any case you are right, there is bug.
-
This is part of LibRaw, no?
-
I see. Yes, in general works fine, but Apple now uses these latest tags and they show up with empty names and the value is in numeric instead of textual one. In what form do you prefer the patch? I think in this case only the exif-tag.h/c need to be changed. I might try to modify it and post them here. Will this be ok?
-
The library lags behind from the exif standard.
-
Bugfix: Tiff thumbnails fails to load if exif is present
-
We should consider the following advanced user API: Create a FILOADER object, passing...
-
In the last few days I was digging around MultiPage and its related CacheFile class,...
-
In the last few days I was digging around MultiPage and its related CacheFile class,...
-
In the last view days I was digging around MultiPage and its related CacheFile class,...
-
Second: The class for holding "page blocks" is no longer virtual. Some helper member...
-
First: MULTIBITMAPHEADER now has no owning pointers. It default-constructs itself....
-
Second: The class for holding "page blocks" is no longer virtual. Some helper member...
-
First: MULTIBITMAPHEADER now has no owning pointers. It default-constructs itself....
-
Refactor: Streamline MultiPage and CacheFile
-
FreeImage loads user plugins in 3 ways under Windows, and 1 way everywhere else....
-
FreeImage uses both external (user provided) and internal (embedded into the dll)...
-
FreeImage uses both external (user provided) and internal (embedded into the dll)...
-
Is there a metadata for that? Can in pre V17 be determined if there is a tRNS? In...
-
GetBPP is correct. It depicts the size of a pixel in memory. It is not metadata about...
-
GetBPP is correct. It depicts the size of a pixel in memory. It is not metadata about...
-
GetBPP is correct. It depicts the size of a pixel in memory. It is not metadata about...
-
Johnny, I believe your post belong to https://sourceforge.net/p/freeimage/discussion/36111/thread/7c10219d/...
-
About - can we "fix" FREE_IMAGE_TYPE Well, we can. But it is a bit messy. We can...
-
And one more thing - how can we add Grayscale With Alpha now? It is not trivial -...
-
Here it is struct FITAGHOLDER { FITAGHOLDER(FITAG* tag = NULL) : _tag(tag) {} FITAGHOLDER(const...
-
I was wondering why does the metadata member was created as fih->metadata = new METADATAMAP;...
-
Here it is struct FITAGHOLDER { FITAGHOLDER(FITAG* tag = NULL) : _tag(tag) {} FITAGHOLDER(const...
-
To store metadata FreeImage uses these two: typedef std::map<std::string, FITAG*>...
-
I was wondering why does the metadata member was created as fih->metadata = new METADATAMAP;...
-
FREE_IMAGE_TYPE has two problems: 1) It is inconsistent in the information it provides...
-
It gets better: Because the container is now a simple array AND it is contiguous...
-
BMP is special, because FreeImage internal bitmap representation is lifted from it...
-
not necessary in order of importance Core improvements 1) Update the License to MPL...
-
Simplest implementation: We don't need either a Container class or a separate key....
-
Simplest implementation: We don't need either a Container class or a separate key....
-
not necessary in order of importance Core improvements 1) Update the License to MPL...
-
not necessary in order of importance Core improvements 1) Update the License to MPL...
-
not necessary in order of importance Core improvements 1) Update the License to MPL...
-
not necessary in order of importance Core improvements 1) Update the License to MPL...
-
not necessary in order of importance Core improvements 1) Update the License to MPL...
-
@Carsten What parts do you consider unneeded and need to be dropped? Also, what parts...
-
If you mean to dump the pixel data to a file, yes you must save it as some uncompressed...
-
Here's another neat feature, we could have if we have "extra params" - we could pass...
-
About FIMETADATA and FITAG I spent the last day researching further. Turned out FIMETADATA...
-
Bugfix: Image View broken save as BMP
-
About FIMETADATA and FITAG I spent the last day researching further. Turned out FIMETADATA...
-
About FIMETADATA and FITAG. I spent the last day researching further. Turned out...
1 >