Re: [ft] Using different loading and render modes, plus LCD example

[Collyer, Oliver, SI]

Is it possible that the pixels you don't write to, in the QImage, contain 
garbage?

I've never used Qt so I'm unsure of the state of a newly created object, but 
assuming you are trying to write black text to a white background then I can't 
see where the pixels you skip get set to white anywhere else.

Also, not sure if the code sample is just to show the theory, but a couple of 
optimisations to your code:

- instead of src[bit++] use (*src++)
- instead of bit = _p*(y+1) use src += _p - (m_face->glyph->bitmap.width) (you 
could also pre-calculate this expression outside both loops)
- then you can ditch 'bit' completely
- you should also take a similar approach, ie using a pointer, to the SetPixel 
call if Qt exposes the raw buffer.

You're welcome to contact me off list if you need any further explanation with 
the above, and apologies if you already know and you were just trying things 
out :)

Sent from my iPigeon

On 16 Jun 2011, at 20:25, "Aekold Helbrass" <address@hidden> wrote:

> Thank you, finally figured out how to use LCD bitmap with QImage.
> Small piece of source code below. But still have a problem: there is a
> lot of noise on rendering, and that noise is jumping on repainting of
> component. So it looks like I've done something wrong with color
> transformations. Basically I am filtering out white pixels, but there
> are a lot of "almost white" ones. Please see attachment.
> 
> source code (cut out error handling to show only logic part):
> 
>            error = FT_Load_Glyph( m_face, glyph_index, FT_LOAD_TARGET_LCD);
>            error = FT_Library_SetLcdFilter(m_library, FT_LCD_FILTER_DEFAULT);
>            error = FT_Render_Glyph( m_face->glyph, FT_RENDER_MODE_LCD );
> 
>            int _h = m_face->glyph->bitmap.rows;
>            int _w = m_face->glyph->bitmap.width/3;
>            int _p = m_face->glyph->bitmap.pitch;
> 
>            uchar *src = m_face->glyph->bitmap.buffer;
>            glyphImage = new QImage(_w, _h, QImage::Format_ARGB32);
> 
>            int bit = 0; // address in buffer
>            for (int y = 0; y < _h; y++) {
> 
>                for (int x = 0; x < _w; x++) {
> 
>                    uchar r = 0xff - src[bit++];
>                    uchar g = 0xff - src[bit++];
>                    uchar b = 0xff - src[bit++];
> 
>                    // filtering out any whites:
>                    if (r + g + b >= 3 * 0xff) {
>                        continue;
>                    }
> 
>                    glyphImage->setPixel(x, y, qRgb(r, g, b)); //
> pixel coordinates to color value
> 
>                }
> 
>                bit = _p * (y + 1); // go to next line, start from 0
>            }
> 
> On Wed, Jun 15, 2011 at 7:20 PM, Collyer, Oliver, SI
> <address@hidden> wrote:
>> The light hinting more or less just hints in the vertical direction, so this 
>> is compatible with LCD rendering which deals with the horizontal (assuming 
>> your LCD display is a regular one and your text is horizontal). IMO it's a 
>> pretty good combination.
>> 
>> To display an LCD-rendered source bitmap on the screen you basically use 
>> each triplet of values in the source as the respective intensity/alpha 
>> values of the RGB components of your destination pixel.
>> 
>> i.e:
>> 
>> - the first (left) value in the source triplet gives how much of the R of 
>> your text colour to use when blending (so a value of 255 means use all of 
>> the text colour R and don't mix it with any of the background bitmap R, 
>> whereas a value of 128 would mean mix them 50-50, etc)
>> - the second (middle) value in the source triplet gives how much of the G of 
>> your text colour to use when blending
>> - the third (right) value in the source triplet gives how much of the B of 
>> your text colour to use when blending
>> 
>> This assumes you have already filtered your LCD bitmap first. FreeType has 
>> functionality for doing this, and this basically reduces a problem known as 
>> 'colour fringing' by mixing together neighbouring pixels in the bitmap.
>> 
>> Here is a decent resource that describes the basics:
>> 
>> http://www.grc.com/ctwhat.htm
>> 
>> Hope this helps.
>> 
>> On 15 Jun 2011, at 18:58, Aekold Helbrass wrote:
>> 
>>> Good day All!
>>> 
>>> I've read the note to
>>> http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_LOAD_TARGET_XXX
>>> and now I have a question: what will I get in case of using LIGHT for
>>> loading and LCD for rendering? Is it considered bad practice, or it
>>> may be used to achieve some special results?
>>> 
>>> And the second question - the reason why I can't check the first one
>>> for myself. I am using that awesome Qt example (example4.cpp) to see
>>> how freetype works in general, but I can't get proper LCD modes. I see
>>> that image is 3 times wider and divide it, but it's still crippled
>>> when rendered. I suppose I should use some other color table or some
>>> smart pixel filtering methods that are used in openjdk or qt, but I am
>>> not familiar with freetype enough to figure it out myself. So, if
>>> there are some LCD rendering examples or guides - please give me some
>>> links.
>>> 
>>> Thanx!
>>> 
>>> _______________________________________________
>>> Freetype mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/freetype
>> 
>> 
> <snapshot04.png>
> _______________________________________________
> Freetype mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype