R: Re: R: Re: understand ImageType, ClassType and ColorspaceType

"[email protected]" <[email protected]> Fri, 12 Apr 2013 12:03:45 +0200 (CEST)
Newsgroups gmane.comp.video.graphicsmagick.apis
Message-ID <12561573.2056271365761025334.JavaMail.defaultUser@defaultHost>
Thank you very much.
Your help was very helpful. I still have some questions:
1) There is a project for the creation of tutorials, examples and 
documentation shared (like wiki)? If so, I'd like to give my contribution.
2) I made ​​a test on a 32-bit bitmap where the alpha channel is equal to 255 
(FF hex), but the matte() method returns 0. How can I distinguish bitmap where 
the alpha channel is not ignored?

Best regards,
Paolo Pazziani

>----Messaggio originale----
>Da: [email protected]
>Data: 11/04/2013 18.32
>A: "[email protected]"<[email protected]>
>Cc: <[email protected]>
>Ogg: Re: R: Re: [GM-apis] understand  ImageType, ClassType and ColorspaceType
>
>On Thu, 11 Apr 2013, [email protected] wrote:
>
>> Hi,
>> Thank you very much for your reply.
>> Could you help me understand if my reasoning is correct?
>> Can I have two possibilities:
>> 1) If I have a PseudoClass image then I will have a single channel defining
>> the index to the colormap. In this case the depth-per-sample is identical 
to
>> the depth-per-pixel
>
>Yes.  In the case of Q8 and Q16, the colormap indexes are the same 
>size as the pixel color sample (8 or 16 bits).  For the case of Q32, 
>the indexes are constrained to 16-bit but the colors in the colormap 
>support 32-bit sample sizes.
>
>> 2) If I have a DirectClass the depth-per-sample will be equal to a quantum
>> size and the number of channels is 4 by default, even if the alpha channel 
can
>> be ignored.
>
>This is true.  However, there is also support for CMYKA images.  In 
>that case the 'indexes' are used to store the opacity channel.  CMYKA 
>is rarely used (and perhaps not perfectly supported).
>
>Opacity is stored inverted (i.e. MaxRGB - Alpha) from normal alpha 
>values.
>
>Bob
>
>> Thanks again.
>> Paolo Pazziani
>>
>>
>>
>>> ----Messaggio originale----
>>> Da: [email protected]
>>> Data: 11/04/2013 16.03
>>> A: "[email protected]"<[email protected]>
>>> Cc: <[email protected]>
>>> Ogg: Re: [GM-apis] understand  ImageType, ClassType and ColorspaceType
>>>
>>> On Thu, 11 Apr 2013, [email protected] wrote:
>>>
>>>>
>>>> Hi, I would like to know what's the meaning of enumerators ImageType,
>> ClassType and ColorspaceType.
>>>>
>>>> In this regard, I read the documentation of the page http://www.
>> graphicsmagick.org/api/types.html
>>>>
>>>> What combinations of these three enumerators can be found? In particular 
in
>> some tests I have noticed that
>>>> different types of images (Grayscale, black and white, RGB, BGRA) 
provides
>> always the same ColorSpaceType that is
>>>> sRGBColorspace.
>>>>
>>>> Furthermore after reading images with 32 bit per pixel when the number of
>> colors is low ImageType=PaletteType,
>>>> while in the case of high number of color ImaType=TrueColorType
>>>>
>>>> There is a deterministic way to know the original and the current type?
>> There is a more comprehensive
>>>> documentation?
>>>
>>> The confusing thing about these properties is that they report
>>> GraphicsMagick's opinion about the image as it is loaded into memory
>>> and does not really have anything to do with the input file format.
>>> It has more to do with the subformat automatically selected when the
>>> image is saved than the input file subformat.
>>>
>>> For example, the input file might be in a 'RGB' storage format, but
>>> the pixels are actually only gray levels.  In this case, the ImageType
>>> would be reported as GrayscaleType.
>>>
>>> If the image is represented in PseudoClass (color-mapped) format, then
>>> it will be reported as PaletteType or PaletteMatteType.  However, a
>>> simple enumerated field (Image 'storage_class') can be changed so that
>>> such images may be instantaneously switched to TrueColorType or
>>> TrueColorMatteType.  GraphicsMagick is able to support both
>>> color-mapped and direct representation of pixels at once, but only one
>>> representation will be used at once.  If any image processing has been
>>> done on an image which was originally color-mapped, it is likely to be
>>> converted to DirectClass representation since it is most appropriate
>>> for image processing.
>>>
>>> ColorSpaceType is most likely to be reported as RGBColorspace rather
>>> than sRGBColorspace since the sRGBColorspace is peculiar to Kodak
>>> PhotoCD format.  If the input format has only one sample per pixel
>>> then it may be reported as GRAYColorspace.
>>>
>>> GraphicsMagick supports a huge number of input formats.  When a file
>>> is read, the data is normalized into the internal representation.
>>> Almost all knowledge of the input format is then lost.
>>>
>>> Bob
>>> --
>>> Bob Friesenhahn
>>> [email protected], http://www.simplesystems.org/users/bfriesen/
>>> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>>
>>
>>
>
>-- 
>Bob Friesenhahn
>[email protected], http://www.simplesystems.org/users/bfriesen/
>GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Graphicsmagick-apis mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-apis