ImageMagick writer/reader

[Myrsloik]

I made a simple image reader and writer since people don't have much luck with the existing ones.

Usage examples:

core.imwri.Read('E:/testdir/testimg000001.png', alpha=False)
core.imwri.Write(main, 'PNG32', 'E:/testdir/testimg%06d.png')

Documentation

imwri test9 32bit
imwri test9 64bit

[sneaker_ger]

How is the dllpath thing supposed to work after the plugin should've already been loaded?

[Myrsloik]

Originally Posted by sneaker_ger

How is the dllpath thing supposed to work after the plugin should've already been loaded?

That's a very good question. Basically ImageMagick decided that normal library ideas were too mundane.

So you not ONLY need to link against imagemagick using your standard .lib files in windows. The linking gives you access to a function in imagemagick so you can tell imagemagick where to find all its other dlls after the main dll has been loaded. It's dll hell illustrated.

A normal library (which this is most certainly not) simply would've loaded all its parts at once.

[sneaker_ger]

Well, I can't even get past LoadPlugin because of missing dlls even when they are in the same directory as imwri.dll.

[Myrsloik]

I'll look at it a bit more later but this is how I tested it:
I only used vspipe, I made sure both the script and all the plugin files are in the same directory AND that the working directory is the script directory.

I'll see if I can modify the source a bit and use mingw instead for the test versions as well...

[sneaker_ger]

Running the script from the same folder as the dlls yields success. I had only tried running vspipe from the dll folder prior to this.

[Mystery Keeper]

The most simple solution is to add dlls folder to PATH environment variable.

[Myrsloik]

I've added a second test version that's compiled for 64 bits (link in the first post). Nodame worked long and hard and managed to make it a single dll so the dllpath argument isn't needed anymore.

Report on your success/failures with unicode filenames.

This plugin will be added to the main source tree once it's working well enough.

[LoRd_MuldeR]

Originally Posted by sneaker_ger

Well, I can't even get past LoadPlugin because of missing dlls even when they are in the same directory as imwri.dll.

Originally Posted by sneaker_ger

Running the script from the same folder as the dlls yields success. I had only tried running vspipe from the dll folder prior to this.

Keep in mind that Windows only looks for DLL's in the same folder where the main EXE file is located. But if some DLL depends on additional DLL's, it will not necessarily look in the folder where the DLL is located.

For example, if some EXE file explicitly loads a plug-in DLL from a certain "plug-ins" directory that differs from the directory where the EXE file itself is located and if that plug-in DLL depends on yet another DLL, then Windows will not look in the "plug-ins" directory for that other DLL (as one might expect) - it still only looks in the folder where the main EXE resides!

If the required DLL could not be found in the directory where the EXE file is located, Windows falls back to certain system directories (C:\Windows\System32, C:\Windows, etc). Then to the directories contained in the PATH environment variable. And finally it falls back to the "current" directory. So that's probably why "running the script from the same folder as the dlls" worked, because that happened to be your "current" directory then.

[Myrsloik]

First post once again updated with an improved version. Nodame managed to add in support for even more formats in the static builds and now both versions are a single simple dll.

The dllpath argument is dead!

So start testing. This should work and only be a minimal hassle to use now.

[alexxdls]

Can this plugin read image sequence? I've tried

ext = '.png'
dir = r"F:\TEMP\50-SHADES_TRL-A_RU-XX_RU_51_1080P_UP_20140725_MPS_IOP_OV\REEL1/"
srcs = [dir + src for src in os.listdir(dir) if src.endswith(ext)]
v1 = core.imwri.Read(srcs)

like with previoous ImageReader, but it now outputs only the first image and all frames are equal. Checking the script gives

Script was successfully evaluated. Output video info:
Frames: 341 | Time: 0:00:14.208 | Size: 1920x1080 | FPS: 24/1 = 24 | Format: YUV444P10

[Myrsloik]

Originally Posted by alexxdls

Can this plugin read image sequence? I've tried

ext = '.png'
dir = r"F:\TEMP\50-SHADES_TRL-A_RU-XX_RU_51_1080P_UP_20140725_MPS_IOP_OV\REEL1/"
srcs = [dir + src for src in os.listdir(dir) if src.endswith(ext)]
v1 = core.imwri.Read(srcs)

like with previoous ImageReader, but it now outputs only the first image and all frames are equal. Checking the script gives

Script was successfully evaluated. Output video info:
Frames: 341 | Time: 0:00:14.208 | Size: 1920x1080 | FPS: 24/1 = 24 | Format: YUV444P10

Found the typo in the code. Will post a fixed version in a bit.

[kolak]

Does it read fps from DPX header?
Does read support same % mode as write, eg.
test_%03d.tiff for test_001, test_002, test_003,..... image sequence?

[Myrsloik]

Originally Posted by kolak

Does it read fps from DPX header?

No, not yet at least.

[kolak]

What format are files decoded to, x bit RGB?

[Myrsloik]

IMPORTANT ANNOUNCEMENT
The test2 archive has been updated. It now handles reading lists of files properly. Before it would simply return the first image over and over again due to a typo. Get it from the first post.

Originally Posted by kolak

What format are files decoded to, x bit RGB?

Only 8-16 bit rgb for now. Going to try to add proper grayscale and yuv in a bit. Returning original subsampled data (such as 420 jpeg) is probably impossible with imagemagick.

[kolak]

RGB is good in this case, I assume.

[Wilbert]

Returning original subsampled data (such as 420 jpeg) is probably impossible with imagemagick.

I never implemented this in Immaavs, but i always thought that this would be possible. Please let us know if that's not the case.

[Myrsloik]

Now I've encountered another problem. I have no test images that are identified as being in a yuv-ish colorspace so I can't add support for reading them. Apparently jpeg images aren't considered yuv.

My own web hunt for this kind of image failed so sample images are requested.

[foxyshadis]

Originally Posted by Wilbert

I never implemented this in Immaavs, but i always thought that this would be possible. Please let us know if that's not the case.

I did see that thread you made, but I see your last question was never answered. You'd have to mod coders/jpeg.c to change:

  i=(ssize_t) jpeg_read_header(&jpeg_info,TRUE);
  if ((image_info->colorspace == YCbCrColorspace) ||
      (image_info->colorspace == Rec601YCbCrColorspace) ||
      (image_info->colorspace == Rec709YCbCrColorspace))
    jpeg_info.out_color_space=JCS_YCbCr;

to:

  i=(ssize_t) jpeg_read_header(&jpeg_info,TRUE);
  if (image_info->colorspace == UndefinedColorspace)
    jpeg_info.out_color_space=jpeg_info.jpeg_color_space;
  else if ((image_info->colorspace == YCbCrColorspace) ||
      (image_info->colorspace == Rec601YCbCrColorspace) ||
      (image_info->colorspace == Rec709YCbCrColorspace))
    jpeg_info.out_color_space=JCS_YCbCr;

and then rebuild. Or just use your own code to detect it ahead of time.

There is a flag that IM doesn't use, jpeg_info.raw_data_out, that will give you non-upsampled pixels. Without it they're always upsampled with a bilinear filter. You'd have to write a bit of code to trick IM into working, since its routines won't work; you have to use jpeg_read_raw_data() instead of jpeg_read_scanlines() and fill the RGB buffers as you wish.

(I forgot how much of a migraine reading IM's source gives me.)