Legacy ImageMagick Discussions Archive

Hey, first of all I would like to thank you for such a great software your creating... it has helped me so much I don't even know how can I repay you.

I'm using your .NET COM library and I'm having some problems.
I appreciate if you'd help me with these three problems:

1. Everything is working great, images are being resized perfectly when there are no non-ascii characters in the path (eg. C:/Whatsup/yogi.jpg), but whenever I try to resize an image which has non-ascii characters in it, as in hebrew characters (eg. C:/שלום/2.jpg - C:/Whatsup/יוגב.jpg) either in the filename itself or in the path, it's just not working and returns a blank result (return "").

2. I have a script which resizes pictures in a directory (which works great, thanks to your great solution), it works whenever I select a folder with small sized images (eg. 0.5-2 MB) but when I try resizing a folder with bigger images in size (5MB or so), after a few images, the script just gets stuck in ImageMagickObject.Convert line (where the image is being resized). Again, this won't happen with smaller sized files therefor the script is ok. Have anyone got into a similiar problem before? is there a way to solve it? BTW: I'm using 3 background threads simultaneously and each one resizes, could that be the problem?



another problem which maybe irrelevant
3. I've added ImageMagick's dll to a visual studio setup project, but when I install it on another computer the setup says it cannot register the dll, is it a problem with imagemagick or is there another way to register it? any suggestions on how could I register it?

I am using ImageMagcik 6.4.7 Q16 dll

Thanks in advanced guys, you're great!

1. Everything is working great, images are being resized perfectly when there are no non-ascii characters in the path (eg. C:/Whatsup/yogi.jpg), but whenever I try to resize an image which has non-ascii characters in it, as in hebrew characters (eg. C:/שלום/2.jpg - C:/Whatsup/יוגב.jpg) either in the filename itself or in the path, it's just not working and returns a blank result (return "").

We account for wide paths in magick/utility.c/OpenMagickStream() where we call _wfopen(). The original filepath is passed as a non-wide string. Its possible there is a bug in the conversion of a non-wide path to a wide-path. If so we could use your help in identifying the problem.

2. I have a script which resizes pictures in a directory (which works great, thanks to your great solution), it works whenever I select a folder with small sized images (eg. 0.5-2 MB) but when I try resizing a folder with bigger images in size (5MB or so), after a few images, the script just gets stuck in ImageMagickObject.Convert line (where the image is being resized). Again, this won't happen with smaller sized files therefor the script is ok. Have anyone got into a similiar problem before? is there a way to solve it? BTW: I'm using 3 background threads simultaneously and each one resizes, could that be the problem?

Multiple threads are fine. Converting a large number of images at once can slow the process down considerably as it consumes more memory for each image. ImageMagickObject.Mogrify() is more efficient since it converts one image at a time. If you are creating thumbnails from JPEG you can gain speed and efficiency by taking advantage of JPEG subsampling. Specify the thumbnail sizes like this:

• convert -size 128x128 image.jpg -thumbnail 128x128 thumb.jpg

another problem which maybe irrelevant
3. I've added ImageMagick's dll to a visual studio setup project, but when I install it on another computer the setup says it cannot register the dll, is it a problem with imagemagick or is there another way to register it? any suggestions on how could I register it?

We are primarily Linux developers and must depend on the Windows user community for help with these types of questions. Anyone?

Hey,

First of all, thanks for the reply

I will be glad to help by every mean... just tell me what information should I supply and I will. Your work is priceless..

I have managed to solve the second with the 5MB files, it was all about the order of the actions i used for the resize

this was the first order I was using:
-resize=600x600", "-filter=Lanczos", "-resample=72", "-depth=8", "-antialias", "-quality=80", "auto-orient", srcfile, "jpg:destfile"

and this is the second one, which is not getting stuck and works a lot faster:
-resize=500x500", "-filter=Lanczos", "-depth=8", "-quality=70", "-auto-orient", srcfile, "jpg:destfile"}

as you can see, I have changed the order of the actions and removed some of the resizing procedures which I found to be non-effective for the size of the image and it's quality.

Does Mogrify gets the same params as the Convert function?

By subsampling, do you mean the exif thumb data that exists in the JPG? I was looking for information about it everywhere, Thank You! again.

the first problem though, still exists, I cannot resize images with non-ascii path

anyone?

Thanks

Using -size permits the JPEG library to quickly generate an image at the size you specify which makes resizing faster since it will be nearly the requested size. For example, assume a 1000x1000 JPEG image resized to 128x128. This command is very fast:

• convert -size 128x128 image.jpg -resize 128x128 thumb.jpg

We can't help much with the file path problem other than to point you to the source where file paths are converted from a string to a wide-path. A previous user suggested this code and they claimed it worked for them for wide-paths. We're not sure why its failing for you.

Hey, I've noticed OpenMagickStream converts the path's encoding from UTF-8 to UTF-16, and what if the path is already in UTF-16? .NET works with Unicode (UTF-16). could that be the problem? I know so little about encoding and I got stuck on this encoding issue, I'm tearing my hairs out, I can't get the non-ascii path image conversion to work.. I'm getting black images for each image I'm trying convert which has non-ascii chars (Hebrew) in it's path.. help!!

MagickExport FILE *OpenMagickStream(const char *path,const char *mode)
{
FILE
*file;

if ((path == (const char *) NULL) || (mode == (const char *) NULL))
{
errno=EINVAL;
return((FILE *) NULL);
}
file=(FILE *) NULL;
#if defined(MAGICKCORE_HAVE__WFOPEN)
{
wchar_t
*unicode_mode,
*unicode_path;

unicode_path=ConvertUTF8ToUTF16(path);
if (unicode_path == (wchar_t *) NULL)
return((FILE *) NULL);
unicode_mode=ConvertUTF8ToUTF16(mode);
if (unicode_mode == (wchar_t *) NULL)
{
unicode_path=(wchar_t *) RelinquishMagickMemory(unicode_path);
return((FILE *) NULL);
}
file=_wfopen(unicode_path,unicode_mode);
unicode_mode=(wchar_t *) RelinquishMagickMemory(unicode_mode);
unicode_path=(wchar_t *) RelinquishMagickMemory(unicode_path);
}
#endif
if (file == (FILE *) NULL)
file=fopen(path,mode);
return(file);
}

If the file path in .NET is UTF-16 it would need to be converted to UTF-8 before passing them to ImageMagick.

Lol, sounds logical
Didn't think about it

Hey, I came back with some research

There is some bug with non-english encoding of image paths, you've got to check it out...

I have made some research:

I made OpenMagickStream printf the original path and mode of the file and the unicode ones (after ConvertUTF8toUTF16)

Weirdly enough it does manage to get the path (the one the does exist) successfuly and wfopen it for reading and then wfopen the created file for writing, something which doesn't happen if you supply a path with non-english letters that doesn't exists(!), which means it's finding the file of the non-english path, but when it tries to read from it's content while creating the new file, it just gets you a new clean gray image. Again, it won't open a non-english file path that doesn't exist, it won't open it at all, but if the file does exist, it will open it and open the new file for writing but won't manage to write to the new image file and you just get a gray image.

this is my output:

mode: rb path: C:/שתוק.jpg
UNICODE - mode: rb path: C:/שתוק.jpg
mode: rb path: C:/שתוק.jpg
UNICODE - mode: rb path: C:/שתוק.jpg
mode: w+b path: C:/sdfg.jpg
UNICODE - mode: w+b path: C:/sdfg.jpg

I guess it is something with the writing of the new file, or something with reading management of the source file.

I'll keep researching, but as I don't have so much knowledge with C, I hope you could help me out with this guys. I've spent the last 3 days trying to solve this but came up with nothing.

Thanks

Anyone?