Ну вот, x77 на меня взъелся (совершенно притом несправедливо)...
Я сказал, что прозрачный пиксел определяется левым нижним пикселом картинки. На что ты ответил:
[quoute]Pegas, p0s0l, с чего это левый нижний? битмапы бывают двух разных видов, top-down и bottom-up, что соответствует порядку загрузки "строк" пикселей. по умолчанию (т.е. TransparentMode = tmAuto) прозрачность определяет первый пиксел в массиве данных, который может быть как левым нижним, так и левым верхним, в зависимости от типа битмапа.[/quote]
Отсюда ясно следует твоя мысль - что пиксел прозрачности может быть и ЛЕВЫМ ВЕРХНИМ.

Со справкой: Справки могут морально устаревать (их писали тоже люди, которые могли забыть изменить какой-нибудь абзац)... Ладно, проверим:
две одинаковых (по содержанию) картинки: одна top-down, другая bottom-up:

Код

var  bmp : TBitmap; begin  bmp := TBitmap.Create;  bmp.LoadFromFile('c:\a.bmp');  bmp.TransparentMode := tmAuto;  Label1.Caption := IntToHex(bmp.TransparentColor, 8);  Image1.Canvas.Draw(0, 0, bmp);  bmp.LoadFromFile('c:\b.bmp');  bmp.TransparentMode := tmAuto;  Label2.Caption := IntToHex(bmp.TransparentColor, 8);  Image2.Canvas.Draw(0, 0, bmp);  bmp.Free; end;

И что я вижу - Label1 и Label2 содержат разные значения, хотя сами данные картинок у них совпадают - т.е. берется в любом случае левый нижний пиксел, а не "the color of the first pixel in the bitmap image data"...
Видимо, в справке остался атавизм - может это было раньше так, но сейчас (в D7) точно не так (ниже приведу уже 100% доказательство), ведь правильнее за цвет прозрачности брать один и тот же пиксел картинки (не важно, верхний левый или нижний левый, лишь бы один и тот же). А то если я буду грузить картинку, я ж не знаю, какая она - topdown или bottomup ? Интересно будет, если я юзаю в проге кучу иконок, выдернутых из разных источников, половина одной ориентации, половина - другой...
Ладно, для пущей уверенности взглянем на один интересный метод TBitmap - установка свойства TransparentMode сводится в конце концов к вызову этого метода:

Код

function TBitmap.GetTransparentColor: TColor; begin  if FTransparentColor = clDefault then  begin    if Monochrome then      Result := clWhite    else      Result := Canvas.Pixels[0, Height - 1]; //// <<<--- Только совсем неверующий не уверует после этого...  end  else Result := ColorToRGB(FTransparentColor);  Result := Result or $02000000; end;

И отсюда ясно видно, без всяких яких, какой же именно пиксел берется за цвет прозрачности...

Цитата

что разницы нет, сказать Bmp.TransparentColor := clFuchsia, как изначально предлагал я, или ImageList.AddMasked (Bmp, clFuchsia), как предлагаешь ты.

Лучше бы проверил теорию на практике. Я всегда проверяю... Разница - есть!
Создай новый проект, засунь туда ImageList (и к примеру, ToolBar, а в нем две кнопки с ImageIndex=0 и ImageIndex=1), и попробуй код:

Код

var  bmp : TBitmap; begin  bmp := TBitmap.Create;  bmp.LoadFromFile('c:\a.bmp');  bmp.TransparentColor := clYellow;  ImageList1.Add(bmp, nil);  bmp.LoadFromFile('c:\b.bmp');  ImageList1.Add(bmp, nil);  bmp.Free; end;

Это было первое, что я попробовал. И tmAuto тоже не помогает - всё равно картинки без прозрачности. А вот это уже работает:

Код

var  bmp : TBitmap; begin  bmp := TBitmap.Create;  bmp.LoadFromFile('c:\a.bmp');  ImageList1.AddMasked(bmp, clYellow);  bmp.LoadFromFile('c:\b.bmp');  ImageList1.AddMasked(bmp, clYellow);  bmp.Free; end;

Так что разница есть...

Цитата

и в чём моё заблуждение - я пока так и не понял

Ответ:

Цитата

Так что твои суждения оказались неверными насчет первого байта данных...

Цитата

смысла твоих манипуляций с HexEdit'ом я, если честно, тоже не понял.

А ты как думал определяется ориентация картинки ? По желанию программиста что-ли ? Top-down и bottom-up ориентация определяется значением поля biHeight у структуры BITMAPINFOHEADER:

Цитата

biHeight Specifies the height of the bitmap, in pixels. If biHeight is positive, the bitmap is a bottom-up DIB and its origin is the lower-left corner. If biHeight is negative, the bitmap is a top-down DIB and its origin is the upper-left corner.

Надеюсь, не надо объяснять, откуда взялось FFFFFF80 вместо 00000080 ?

Вывод: либо ты не проверяешь ниодного из своих доводов, либо сидишь на другой дельфи (помнишь аналогичную историю с DBGrid'ом ? Мы тоже там друг друга долго не могли понять... пока не выяснилось, что дело в разных версиях Delphi)...

p0s0l, сейчас не могу предметно ответить, подыхаю. то ли отравился, то ли хрен его знает. позже отпишу.

но я ни в коем случае не взъелся если был резок - извини.

x77, главное - не подыхай! Куда мы тут без тебя ?
А спор - это фигня... В итоге оба окажемся неправы, или оба правы

Цитата

x77, главное - не подыхай! Куда мы тут без тебя ? А спор - это фигня... В итоге оба окажемся неправы, или оба правы

Ты прав в итоге вы оба не правы.

*.bmp не

Цитата

бывают двух разных видов, top-down и bottom-up, что соответствует порядку загрузки "строк"

Это взято из описания формата *.bmp

Цитата

..............ЗДЕСЬ ОПИСАНИЕ СТРУКТУРЫ ФАЙЛА........... если кому интересно могу выложить После того, как все параметры битового образа определены, в файле идут сами скан-строки битовой плоскости, причем первой скан-строкой в формате DIB считается нижняя скан-строка (т.е. начало координат находится в левом нижнем углу изображения).

Даммм.... Щас тут будут цитировать строки неизвестных авторов из неизвестных описаний... Если я найду описание bmp, где написано, что пикселы в нем располагаются по синусоидам, и процитирую это - нормально будет ? Это 100%, что bmp могут быть верхтормашками расположены, и наоборот... Против этого не попрешь - и Photoshop умеет сохрянать разными ориентациями, и в MSDN написано об ориентациях, и MS API Reference тоже... Так что, гость, тут ты сам ошибаешься...