<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-9F9CE6B6-1B3D-50A6-8A94-BD391732EF2D" xml:lang="en"><title>Luminosity

Pixel Formats</title><shortdesc>This topic provides detailed information about the supported luminosity

pixel formats. These formats are used to represent grayscale images.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<section id="GUID-320B39DE-E3E7-4222-9CC9-5B4471F88710"><title>EUidPixelFormatL_1</title> <p>This format has

1 bit per pixel. It is implicit in the code that pixel addresses within a

byte increase from low bit to high bit. A little-endian architecture is also

implicit, because conversions are made from pointers to byte and from pointers

to (unsigned) int and there is an implication that pixel addresses within

a 32-bit word also increase from low to high-order bit. </p> <fig id="GUID-7E3D8B96-2CC0-58C8-856D-21847782878E">

<title>              Pixel address layout in memory for the EUidPixelFormatL_2

format            </title>

</fig> <p>The equivalent UID value is {0x102858EF}. </p> </section>

<section id="GUID-A8A6123A-5766-4993-AEDB-D069831D9064"><title>EUidPixelFormatL_2</title> <p>This format has 2 bits per pixel.

It is implicit in the code that pixel addresses within a byte increase from

low bit to high bit. A little-endian architecture is also implicit, because

conversions are made from pointers to byte and from pointers to (unsigned)

int and there is an implication that pixel addresses within a 32-bit word

also increase from low to high-order bit. </p> <fig id="GUID-5D4C0942-42F8-5094-B376-DC4252816437">

<title>              Pixel address layout in memory for the EUidPixelFormatL_2

format            </title>

</fig> <p>The equivalent UID value is {0x102858EE}. </p> </section>

<section id="GUID-71CFCD00-7223-40CA-8A26-205792E3E7C7"><title>EUidPixelFormatL_4</title> <p>This format has 4 bit per pixel.

It is implicit in the code that pixel addresses within a byte increase from

low bit to high bit. A little-endian architecture is also implicit, because

conversions are made from pointers to byte and from pointers to (unsigned)

int and there is an implication that pixel addresses within a 32-bit word

also increase from low to high-order bit. </p> <fig id="GUID-6021C416-EAF0-5FAA-9181-13A0FB14D518">

<title>              Pixel address layout in memory for the EUidPixelFormatL_4

format            </title>

</fig> <p>The equivalent UID value is {0x102858ED}. </p> </section>

<section id="GUID-719B6262-9AC5-4372-A082-36E559FE7922"><title> EUidPixelFormatL_8</title> <p>This format has 8 bit per pixel.

A little-endian architecture is implicit in the code, because conversions

are made from pointers to byte and pointers to (unsigned) integer and there

is an implication that the lower-order byte of an unsigned integer has the

physically lower address. </p> <p>8-bit per pixel color bitmaps use indexed

look up tables and monochrome bitmaps represent the 256 levels of gray directly. </p> <fig id="GUID-7047A561-981B-56B9-BCFD-5F2E4C757B79">

<title>              Pixel address layout in memory for the EUidPixelFormatL_8

format            </title>

</fig> <p>The equivalent UID value is {0x102858EC}. </p> </section>

</conbody><related-links>

<link href="GUID-7E6DDDBB-FDE2-59ED-A932-AFD4D0BAC3E3.dita"><linktext>RGB     

           Pixel Format</linktext></link>

<link href="GUID-D429672C-448D-5E91-ABA0-81680869D69E.dita"><linktext>YUV Pixel

Format</linktext></link>

</related-links></concept>