Legacy ImageMagick Discussions Archive

snibgo wrote: ↑2017-07-06T14:16:53-07:00 I don't understand what problem you are trying to solve. You have linked to two files. Exiftool says they are both palette files. So what?

You have shown two screnshots. From what software? Relating to what files? They say one file is "Bit depth 32" whatever that means, the other is "Bit depth 8". So what is the problem?

They are not both pallet files, only the converted image is a palette file.

The software you're asking about is Windows property viewer but you can look in almost any image application to see what the issue is, IM is converting a 32 bit image (I'm guessing it's optimizing because it only has one color) to a indexed image. So the problem is; it's converting a 32 bit image to a 8 bit indexed image when using the flag 'PNG00' Every other bit depth works perfectly. I can't have it optimize like that because I need to convert a 32 bit to a 32 bit, not an 8 bit.

Thanks guys, let me know if this is actually an issue or if I'm just being stupid and missing a flag.

With IM v6.9.5-3:

Code: Select all

convert test_layer.png png00:t.png

Windows Explorer Properties then reports that t.png has the same bit depth as test_layer.png, 32.

You get different results depending upon what tool you use to measure the color depth and color properties. ImageMagick and universally used EXIFTOOL both say your input and output images are palette. So we do not know what to tell you. On my Mac using GraphicConverter, it tells me both images are truecolor 32-bits per pixel. Perhaps the tool you are using is telling you differently per the PNG tags.

Your input image shows (from identify -verbose):

Code: Select all

   png:IHDR.bit-depth-orig: 8
    png:IHDR.bit_depth: 8
    png:IHDR.color-type-orig: 6
    png:IHDR.color_type: 6 (RGBA)
    png:IHDR.interlace_method: 0 (Not interlaced)
    png:IHDR.width,height: 200, 200
    png:sRGB: intent=0 (Perceptual Intent)
    png:text: 1 tEXt/zTXt/iTXt chunks were found

and your output image shows (from identify -verbose):

Code: Select all

   png:bKGD: chunk was found (see Background color, above)
    png:cHRM: chunk was found (see Chromaticity, above)
    png:gAMA: gamma=0.45454544 (See Gamma, above)
    png:IHDR.bit-depth-orig: 8
    png:IHDR.bit_depth: 8
    png:IHDR.color-type-orig: 6
    png:IHDR.color_type: 6 (RGBA)
    png:IHDR.interlace_method: 0 (Not interlaced)
    png:IHDR.width,height: 128, 128
    png:sRGB: intent=0 (Perceptual Intent)
    png:text: 3 tEXt/zTXt/iTXt chunks were found
    png:tIME: 2017-07-06T10:36:38Z

However, I do not see any special information here that says it is not tricolor (color-type: 6, which means RGB-Matte).

I think different software will look at the data and report differently depending upon how they want to interpret the color depth.

Why does it matter that your Windows tool is saying they are different? Does it affect your further processing in any way?

"Why does it matter that your Windows tool is saying they are different? Does it affect your further processing in any way?"

Yes, because I am trying to import the resized image back into a service (A bitmap service that we wrote) that will not allow me to import a 8 bit indexed image back into the service.

Code: Select all

System.Windows.Media.PixelFormats.Bgr32

To explain about the images I uploaded, one set was from Windows properties and the other is from Gimp to show you that there is an actual conversion happening. Unfortunately, Regardless if any "Software" says it's {xyz} bit means nothing to me, (I am just showing you that you can see that the image is clearly being effected on convert) because in my code I need to pull this 32 bit image and strip it's alpha channel, and when I try and import it back into my DB it's not because it's not a 32 bit image.

I understand you're using -Verbose and using that as the specs from the image but it's clearly wrong when dealing with 32 bit images. My input image is not indexed, its a 32 bit image without a color map.

Does this make sense? I actually can't have this conversion (Optimizing) happen because it's logic is dependent on my code. Is there a flag that I can use, or is this an bug or am I just being stupid here? It seems to work on any image perfectly except when I try and use it on a 32 bit.

Thanks again guys,

I have sent a note to the PNG developer (glennrp) to ask for his analysis and comments.

Thank you so much guys, hopefully we can figure out whats going on.

EDIT:
I'm also seeing it's converting 1 bit to 8 bit now:

1-bit to 8-bit is understandable. When you resize, it interpolates pixel values to get new grayscale values. Thus you go from 1-bit to 8-bits to cover the greater number of grayscale pixels in the image.

Darn, I was really hoping I could get away with not passing more arguments, but It's looking like I have to pass in '-Depth 1' for my mask and 'PNG32' for my 32 bit image instead of relying on 'PNG00'.

On your mask reprocessing you could just add -threshold 50% after the resize. That will make it 1-bit, but it will be aliased. You could also replace -resize with -sample. That will keep your 1-bit image, but again it will be aliased.

On your red colored image, you could try adding -type truecolor after the resize and before PNG00: and see if that helps preserve your 32-bit color processing or just use PNG32:.

IM doesn't tell you how data is stored in the file. Instead, IM tells you how data is stored in memory, after reading the data, and this may be different to how it is stored in the file.

As I said, if we use Windows Explorer Properties as the judge, "convert test_layer.png png00:t.png" makes the output "32 bits". Doesn't that work for you?

fmw42 wrote: ↑2017-07-06T19:23:52-07:00 On your mask reprocessing you could just add -threshold 50% after the resize. That will make it 1-bit, but it will be aliased. You could also replace -resize with -sample. That will keep your 1-bit image, but again it will be aliased.

On your red colored image, you could try adding -type truecolor after the resize and before PNG00: and see if that helps preserve your 32-bit color processing or just use PNG32:.

Yeah, I'm not really looking for adding anything to my service method, thanks for all the suggestions! Really sucks, I'm going to have to drop this for this feature

snibgo wrote: ↑2017-07-07T04:10:34-07:00 IM doesn't tell you how data is stored in the file. Instead, IM tells you how data is stored in memory, after reading the data, and this may be different to how it is stored in the file.

As I said, if we use Windows Explorer Properties as the judge, "convert test_layer.png png00:t.png" makes the output "32 bits". Doesn't that work for you?

Sorry, I don't quite follow. The output (With one color) Optimizes it down to 8 bit with a color map. I need it to be 32 bit without the optimization of the map. I'm traversing the pixel data and it's not 32 bit :/
I don't know why IM, Windows, Photoshop, Gimp, are all saying different things, the actual pixel data of the converted file is 8 bit.

IM is telling you something different, because it isn't saying how data is stored in the file.

Ah, okay I understand. My issue was never really with IM telling me different data (Just because my method was not accepting 8 bit), I think it was the others telling me that it was 32 bit because IM way saying it was.

I really appreciate all your help! Thanks again!

If you need 32-bits, then why not just add PNG32:output.png?

fmw42 wrote: ↑2017-07-07T12:06:04-07:00 If you need 32-bits, then why not just add PNG32:output.png?

I hate to sound condescending I'm not trying to, but the original reason I opened this thread is because I need the converted image to keep the same bit depth as the input (originally I was using 32 but opened this question to find a way to keep the exact bit depth, upon talking to you guys it doesn't seem possible with IM), I'm working with 1, 8, 24, and 32 bit images that are passed into my function. It was the first post I made, again In text form this sounds super rude, but I'm not trying to be.

Code: Select all

    public static void SetImageSize(string layerName, int resize)
    {
      try
      {
        ImageMagick($"{layer} -resize {resize} -unsharp 1.5x1.2+1.0+0.10 PNG00:{ layerName.Replace(".png", "_" + resize.ToString() + ".png"}").Wait();
      }

I'm not looking to extend my code to handle multiple flags for the bit depth, It's going to bloat my code with checks to see bit depth.

Legacy ImageMagick Discussions Archive

When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?