New Post: ImageMagick reads/converts TrueColor TIF as Grayscale?

April 28, 2014, 12:17 pm

≫ Next: New Post: Combining two multi-page TIFF images

≪ Previous: New Post: Combining two multi-page TIFF images

$

0

0

Viewpoint 1 - The developer perspective

Your comments made me dig into the code and figure out what is happening. It turns out that requesting the ColorType changes the ColorType and ColorSpace. I have modified ImageMagick and moved this to a separate method. This method will be called DetermineColorType and available in the next version of Magick.NET. This means that image.ColorType will return the original ColorType instead of the automatically detected ColorType. But this will still result in an output image with a gray ColorType. You can prevent this by explicitly telling ImageMagick to preserve the ColorType:

using (MagickImage image = new MagickImage(@"F:\wireframe.tif"))
{
  image.PreserveColorType = true;
  /*
    This will internally do the following statement that sets an internal option to explicitly use this ColorType.
    image.ColorType = image.ColorType;
  */
  image.Write(@"F:\same_wireframe.tif");
}

Viewpoint 2 - The theoretical perspective or as science guys talk ( also not me :) )

I am also not a color expert so my explanation may sound confusing. I am also still learning. If you want some more information on how ImageMagick interprets color spaces you should visit the following page: http://www.imagemagick.org/Usage/color_basics. Anthony can explain it much better then me.

---

New Post: Combining two multi-page TIFF images

April 28, 2014, 12:21 pm

≫ Next: New Post: Combining two multi-page TIFF images

≪ Previous: New Post: ImageMagick reads/converts TrueColor TIF as Grayscale?

$

0

0

Can you post a link to both your images? And what do you consider super slow?

New Post: Combining two multi-page TIFF images

April 28, 2014, 12:52 pm

≫ Next: New Post: Combining two multi-page TIFF images

≪ Previous: New Post: Combining two multi-page TIFF images

$

0

0

I cannot post the images due to them containing confidential information. They are both 2480 by 3475. One file has 5 pages, the other has 40. When I iterate through both files, it runs in about 4 minutes. If I just use the command line to do this merge, it runs in a little over 1 minute.

mchris, thanks for your post. I will try it out.

New Post: Combining two multi-page TIFF images

April 28, 2014, 1:28 pm

≫ Next: New Post: Combining two multi-page TIFF images

≪ Previous: New Post: Combining two multi-page TIFF images

$

0

0

You are probably using the Q16 version of Magick.NET The Q16 version uses HDRI and requires a lot of memory 2480 * 3475 * 16 bytes per pixel = 131MB per page. This is a total of 45 * 131MB = 5.9 GB. When there is not enough memory available Magick.NET will use the hard disk to store the images. And this will make the conversion much slower. If you switch to the Q8 version you will only need 1.5 GB (2480 * 3475 * 4 bytes per pixel).

I will add new methods to the MagickImageCollection class that will make it easier for you to add a set of images.

using (MagickImageCollection image= new MagickImageCollection())
{
  foreach(string fileName in GetFileNames())
  {
     image.AddRange(fileName);
  }
}

// And:using (MagickImageCollection image= new MagickImageCollection())
{
  foreach(string fileName in GetFileNames())
  {
    using (MagickImageCollection other = new MagickImageCollection(fileName))
    {
      image.RemoveAt(1);
      image.AddRange(other);
  }
}

New Post: Combining two multi-page TIFF images

April 28, 2014, 1:28 pm

≫ Next: New Post: Possible bug with large file streams?

≪ Previous: New Post: Combining two multi-page TIFF images

$

0

0

This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.

New Post: Possible bug with large file streams?

April 28, 2014, 4:25 pm

≫ Next: New Post: Possible bug with large file streams?

≪ Previous: New Post: Combining two multi-page TIFF images

$

0

0

Using this image: https://www.dropbox.com/s/hvgfu4f6s25zhqu/PreviewforTif.tif. It's large(191 MB)

       var destinationStream = new FileStream("test.pdf", FileMode.Create);

        //this is the image in dropbox
        string sourceFilePath = tifFile;

        MagickImage magickImage1 = new MagickImage(sourceFilePath);

        magickImage1.Strip();
        magickImage1.Format = MagickFormat.Pdf;
        magickImage1.Density = new MagickGeometry(300, 300);

        destinationStream.SetLength(0);
        magickImage1.Write(destinationStream);

       //if I stop right here, I get a .pdf at 300 dpi.  Perfect.  but as I continue...

        destinationStream.Seek(0, SeekOrigin.Begin);
        MagickImage magickImageDestination = new MagickImage(destinationStream);

        MagickImage magickImageSource = new MagickImage(sourceFilePath);

        ColorProfile cp = magickImageSource.GetColorProfile();

        if (cp != null)
        {
            magickImageDestination.AddProfile(cp);
        }

        destinationStream.SetLength(0);

         try
        {
            magickImageDestination.Write(destinationStream);
        }
        catch (Exception e)
        {

        }

Here I end up with a .pdf that is sometimes corrupted. It's also only like 8 mb, which can't be right. And if it's not corrupted, it's only 72 dpi.

Let me know if you need more information or if I am missing something.

Thanks, Tim

New Post: Possible bug with large file streams?

April 29, 2014, 4:18 am

≫ Next: New Post: Possible bug with large file streams?

≪ Previous: New Post: Possible bug with large file streams?

$

0

0

You need to set the density when you read the PDF that you have just created, otherwise it will use 72 dpi as the default.

MagickReadSettings settings = new MagickReadSettings();
settings.Density = new MagickGeometry(300, 300);
MagickImage magickImageDestination = new MagickImage(destinationStream, settings);

I would however advise you to not use a PDF file as an intermediate format. This format use the GhostScript program and creates PNG files on disk. You are probably better of to use TIFF or PNG as the intermediate format.

New Post: Possible bug with large file streams?

April 29, 2014, 4:35 am

≫ Next: New Post: Combining two multi-page TIFF images

≪ Previous: New Post: Possible bug with large file streams?

$

0

0

Shouldn't the density and format already be a part of the destination stream that was created on this line:

magickImage1.Write(destinationStream);

So when I read from that stream, the density and format should carry over?

---

New Post: Combining two multi-page TIFF images

April 29, 2014, 5:02 am

≫ Next: New Post: Combining two multi-page TIFF images

≪ Previous: New Post: Possible bug with large file streams?

$

0

0

dlemstra,

Thank you for mentioning the Q8 version. Using this drastically cut down run time (only took 20 seconds with it!). While I appreciate you adding new methods, please do not do it just for me. I am able to do what I need to do using what is currently available.

I do have one more question though. Is there a way to compress a MagickImageCollection before writing it? Currently, I am writing the collection using Magick.NET, and then using a Process to open the command line and send "convert outputfile.tiff -compress Group4 outputfile.tiff" as an argument. Just wondered if there is a way to do this in Magick.NET.

Thank you again for all your help.

Corbin

New Post: Combining two multi-page TIFF images

April 29, 2014, 6:03 am

≫ Next: New Post: Combining two multi-page TIFF images

≪ Previous: New Post: Combining two multi-page TIFF images

$

0

0

You don't need to use the convert.exe program anymore. Almost all the functionality from ImageMagick is available in Magick.NET. And if it is not please tell me so I can try to add it.

You can set the compression method like this:

using (MagickImageCollection images = new MagickImageCollection())
{
  images.Read("first.tiff");
  images.AddRange("second.tiff");
  // You only need to set this for the first image in your collection.
  images[0].CompressionMethod = CompressionMethod.Group4;
  images.Write("outputfile.tiff");
}

Adding those two new methods is not much work and you are probably not the only one that could use it. With your help Magick.NET will become a better product for everybody.

New Post: Combining two multi-page TIFF images

April 29, 2014, 6:11 am

≫ Next: New Post: Possible bug with large file streams?

≪ Previous: New Post: Combining two multi-page TIFF images

$

0

0

dlemstra,

Thank you for showing me how to set the compression method. I didn't realize you only needed to set it for the first image in the set.

I have Magick.NET currently doing everything I need from it. I really appreciate your help.

Thanks again.

Corbin

New Post: Possible bug with large file streams?

April 29, 2014, 8:15 am

≫ Next: New Post: Possible bug with large file streams?

≪ Previous: New Post: Combining two multi-page TIFF images

$

0

0

I agree that you would expect the density to be maintained. But the PDF reader currently does not support that. I found this example on how to parse it: http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=16598. I will see when I can find some time to add this for you.

New Post: Possible bug with large file streams?

April 29, 2014, 1:41 pm

≫ Next: New Post: Possible bug with large file streams?

≪ Previous: New Post: Possible bug with large file streams?

$

0

0

You're code snippet above seems to work for pdf's. But I'm having a similar problem converting to .png. They all end up being 72 DPI.

Using this image: https://www.dropbox.com/s/k7khbpvbrqqtryz/22307_009_%20JM_0055.jpg

    var destinationStream = new FileStream("test.png", FileMode.Create);

    //this is the image in dropbox
    string sourceFilePath = jpgFile;

    MagickImage magickImage1 = new MagickImage(sourceFilePath);

    magickImage1.Strip();
    magickImage1.Format = MagickFormat.Png;
    magickImage1.Density = new MagickGeometry(300, 300);

    destinationStream.SetLength(0);
    magickImage1.Write(destinationStream);

    destinationStream.Seek(0, SeekOrigin.Begin);
    MagickReadSettings settings = new MagickReadSettings();
    settings.Density = new MagickGeometry(300, 300);
    settings.Format = MagickFormat.Png;
    MagickImage magickImageDestination = new MagickImage(destinationStream, settings);

    MagickImage magickImageSource = new MagickImage(sourceFilePath);

    ColorProfile cp = magickImageSource.GetColorProfile();

    if (cp != null)
    {
        magickImageDestination.AddProfile(cp);
    }

    destinationStream.SetLength(0);

     try
    {
        magickImageDestination.Write(destinationStream);
    }
    catch (Exception e)
    {

    }

New Post: Possible bug with large file streams?

April 29, 2014, 2:47 pm

≫ Next: New Post: Possible bug with large file streams?

≪ Previous: New Post: Possible bug with large file streams?

$

0

0

The PNG reader only reads the density when the ResolutionUnits are set.

magickImage1.ResolutionUnits = Resolution.PixelsPerInch;

And there is a bug when you read magickImageDestination.ResolutionUnits. It will show PixelsPerInch because you set it to that. But the value will always be PixelsPerCentimeter for a PNG image. The next release will return the correct value.

New Post: Possible bug with large file streams?

April 29, 2014, 4:27 pm

≫ Next: New Post: Possible bug with large file streams?

≪ Previous: New Post: Possible bug with large file streams?

$

0

0

Thanks. And just to clarify. In the following code, using the same source file as above(https://www.dropbox.com/s/k7khbpvbrqqtryz/22307_009_%20JM_0055.jpg):

        MagickImage magickImage = new MagickImage(sourceFilePath);
        magickImage.Strip();

        magickImage.Format = MagickFormat.Png;
        if (magickImage.Format == MagickFormat.Png)
        {
            magickImage.ResolutionUnits = Resolution.PixelsPerInch;
        }

        //set DPI
        magickImage.Density = new MagickGeometry(300, 300);

        destinationStream.SetLength(0);
        magickImage.Write(destinationStream);

The final result still shows 72 DPI. Did your response mean that it will continue to show 72 DPI until the next release? or is the bug something different?

---

New Post: Possible bug with large file streams?

April 29, 2014, 10:03 pm

≫ Next: New Post: ImageMagick reads/converts TrueColor TIF as Grayscale?

≪ Previous: New Post: Possible bug with large file streams?

$

0

0

I ran my tests without magickImage.Strip();. If you remove that it will work. But I have no idea why that is happening. I will have to look in the PNG coder and figure that out for you.

I would advise you to remove the if and always set the ResolutionUnits to PixelsPerInch.

New Post: ImageMagick reads/converts TrueColor TIF as Grayscale?

April 30, 2014, 1:13 am

≫ Next: New Post: Possible bug with large file streams?

≪ Previous: New Post: Possible bug with large file streams?

$

0

0

“Your comments made me dig into the code and figure out what is happening”

Yeah, I didn’t want to push this topic because it would be nice from me to read the source code and give you some C++ code examples. But the fact is I’m not a real programmer and I don’t understand it.

But in theory, I think, ImageMagick should behave just the opposite way:

C:\> magick bigFatSadImage.tif -tryReduceTheNumberOfChannels smallHealthyHappyImage.tif

In other way, if the users want to create a single black pixel on the center of a big white background and store this as a 64-bit transparent HDR image (and load into ImageMagick without the need to set any property), give them the tools to do it (we have the rights to be stupid!:) ).Of course this can be used really for testing purposes. Then if they want to reduce the size of their images:

-tryReduceTheNumberOfChannels

• Check if the 64-bit image contains unnecessary channels and try to remove all of it and so on…
  

-tryPackPixelBits (maybe similar function already exists)

• Check if the 16-bit channels contain such information that can be represented as 8-bit without loss of information
• Check if the 8-bit channels can be represented as indexed
  

But this is just theory and that’s easy. The implementation is much harder.

About ColorSpace:

“If you want some more information on how ImageMagick interprets color spaces you should visit the following page:”

Yeah, I read that page before. Do I understand it? Well, that’s a different question.:)
I think the following words have many different meanings depending on where I read them and who uses them: ColorModel, ColorSpace, sRGB, linear RGB, RGB ColorSpace, RGB ColorSpaces.

I tried to translate them for myself, I only tried it :)

RGB ColorSpaces : ColorSpaces based on the RBG ColorModel
RGB ColorSpace 1: linear RGB (mostly converted but unprocessed camera raw images are in this form, I think ImageMagick uses this term too)
RGB ColorSpace 2: RGB ColorModel (often found on the wiki pages)
sRGB : ColorSpace based on the RGB ColorModel (most of the images and monitors(or at least they claim that) use this colorSpace)

If you want you can correct this.

New Post: Possible bug with large file streams?

April 30, 2014, 5:37 am

≫ Next: New Post: Possible bug with large file streams?

≪ Previous: New Post: ImageMagick reads/converts TrueColor TIF as Grayscale?

$

0

0

Thanks. Do you happen to know when the next full release will be that covers some of the recent changes?

New Post: Possible bug with large file streams?

April 30, 2014, 6:29 am

≫ Next: New Post: No such file or directory...

≪ Previous: New Post: Possible bug with large file streams?

$

0

0

I was planning to publish a release last weekend but I did not have enough time to do it. I hope I can publish the release this weekend.

New Post: No such file or directory...

May 1, 2014, 5:15 am

≫ Next: New Post: ImageMagick reads/converts TrueColor TIF as Grayscale?

≪ Previous: New Post: Possible bug with large file streams?

$

0

0

Using this file: https://www.dropbox.com/s/infnited52bkz98/NIKE_logo.ai

I get the following error:

Magick: Postscript delegate failed `c:\Nike_logo.ai': No such file or directory @ error/ps.c/ReadPSImage/840

When I make this call:

MagickImage magickImage = new MagickImage(sourceFilePath);

But the file does exist.