Hi, I am new to Lazarus/FPC and I got a first problem with using LazIntfImage under OSX:

My small program reads out ExifData and small Thumbnail-Pictures out the files from different DigitalCameras. The thumbnails usually are quite small (between 320*200 and 570*375 px) I keep this pictures within a TImage Object for later use. Since I want to analayse the distribution of the RGB-Values, I read them out with ...pixels(x,y) function. Anything works fine here, anything correct in Windows and OSX. But this function is very, very slow. Even on OSX. So I tried to use TLazIntfImage.

TLazIntfImage's access is fast, but now there is a problem: The values for RGB under OSX are not correct anymore. I know that I get a 16bit Value here, so I have to use something like FPColor.red div 256. The results are correct in Windows, but not in OSX. I already tried to SwapEndian just anything I got,- no way.

I cant see any rule in results like this here:
Pixel (0,215): 65,43,20 (Mac), 88,57,21 (Windows)
Pixel (1,215): 53,38,26 (Mac), 73,50,31 (Windows)
Pixel (2,215): 50,38,21 (Mac), 69,50,21 (Windows)
and so on.

Maybe someone can give me a hint?
Wolfram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100705/68fbf7db/attachment.html>

2010/7/5 Wolfram S?ns :

Maybe someone can give me a hint?

How about the example images?
Could you try to load images from .bmp or .png files?

thanks,
dmitry

Privet Dmitry,

a Sample File is attached. Its written out with the ...SaveToFile function from a tlazintfimage.

The Image within the TLazIntf File seems to be correct. When I Load another TImage Object with it, it looks like th original. To make it clear:
in the Base File (a raw or dng file from a digitalcamera) is a small thumbnail. it is a non compressed bitmap i 8Bit per Color. I can read it into a timage or tLazintfimage and use it. Only when I try to read the color out from it again, there is a difference. in timage windows and mac are the same, in tlazintfimage only windows shows the correct values.

Thanks for your help,
Wolfram

Wolfram S?ns wrote

a Sample File is attached.

I can't find any. Probably it has been cut off by the mailing list.

thanks,
dmitry

I'm not sure what the preferred way of appending an image to this list's postings is.

I believe I've seen something like that on Linux but I've not dug into it yet. I suspect that the colour representation varies, possibly depending on the system properties as interpreted by the TImage object.

Another thing that I've seen is that there's a massive performance hit if you have more than one tlazintfimage instance, I was able to code round that.

Mark Morgan Lloyd wrote

I'm not sure what the preferred way of appending an image to this list's postings is.

Probably a link to imageshack

http://imageshack.us/

ok, here is a small sample on my website:
www.soens.de/L1004220.bmp
its a small preview saved out of a DNG File

Wolfram

Wolfram S?ns wrote

ok, here is a small sample on my website: www.soens.de/L1004220.bmp its a small preview saved out of a DNG File

Noting your earlier "in timage windows and mac are the same, in tlazintfimage only windows shows the correct values.", I'd suggest posting both with an indication of which is which.

Hello Mark, thanks for your replies.

"I suspect that the colour representation varies, possibly depending on the system properties as interpreted by the TImage object."

I think its something in that direction.

"Noting your earlier "in timage windows and mac are the same, in tlazintfimage only windows shows the correct values.", I'd suggest posting both with an indication of which is which.

No, the Image is the same in both cases.
I'll ry to explain it again:

There are uncrompressed bitmaps or jpgs as additional thumbnail views inside of almost any file of a digital camera. I read this files and extract this pictures into a TBitmap for later use.

When I show this bitmap (for example with a TImage Component on a form) anything is fine.

Then I try to read out the RGB Values from this bitmap again, the difference is the following:
- When I read the values directly out from the Bitmap, it works (Windows and Mac)
- When I use a TLazIntfImage for performance reasons here (and after filling the LazIntfImage with TLazIntf.LoadFromBitmap... ) then only the Windows version still shows the correct RGB valuesm which I get with FPColor.red and so on.

I hope you could understand my problem.
Thanks and a good night, Wolfram

How do you access the pixel data ? Did you notice LazIntfImage.Description ?

On Mac and Windows thre is a different order of the RGB components

Marc

Hi Marc,

I access the pixel data directly via FPColor:=TLazIntfImage.Colors[x,y]

Even if there is a difference in the internal layout, with using this function it should be correct anyway. Or am I missing something here?

The DataDescription of the TLazIntfImage:

Mac:

Format=ricfRGBA
HasPalette->False
HasMask->False
Depth=24
Width=320
Height=216
BitOrder=riboReversedBits
ByteOrder=riboMSBFirst
LineOrder=riloTopToBottom
LineEnd=rileDQWordBoundary
BitsPerPixel=32
BytesPerLine->1280
RedPrec=8 RedShift=16
GreenPrec=8 GreenShift=8
BluePrec=8 BlueShift=0
AlphaPrec=0
AlphaShift=0 ~~~mask~~~
MaskBitsPerPixel=0
MaskShift=0
MaskLineEnd=rileByteBoundary
MaskBitOrder=riboReversedBits
MaskBytesPerLine->0 ~~~palette~~~
PaletteColorCount=0
PaletteBitsPerIndex=0
PaletteShift=0
PaletteLineEnd=rileTight
PaletteBitOrder=riboBitsInOrder
PaletteByteOrder=riboLSBFirst
PaletteBytesPerLine->0

Windows:

Format=ricfRGBA
HasPalette->False
HasMask->False
Depth=24
Width=320
Height=216
BitOrder=riboReversedBits
ByteOrder=riboLSBFirst
LineOrder=riloTopToBottom
LineEnd=rileDWordBoundary
BitsPerPixel=24
BytesPerLine->960
RedPrec=8
RedShift=16
GreenPrec=8
GreenShift=8
BluePrec=8
BlueShift=0
AlphaPrec=0
AlphaShift=0 ~~~mask~~~
MaskBitsPerPixel=0
MaskShift=0
MaskLineEnd=rileWordBoundary
MaskBitOrder=riboReversedBits
MaskBytesPerLine->0 ~~~palette~~~
PaletteColorCount=0
PaletteBitsPerIndex=0
PaletteShift=0
PaletteLineEnd=rileTight
PaletteBitOrder=riboBitsInOrder
PaletteByteOrder=riboLSBFirst
PaletteBytesPerLine->0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100706/40887f96/attachment-0001.html>

You're right. This should always return the correct value. (there are different ways to access the pixels, therefore I asked)

If there is a difference, please bugrep, with a simple sample program + image showing the difference

Marc

Can I check one thing here please: am I correct in my understanding that usage as above /should/ always return the correct value, but TLazIntfImage.GetDataLineStart() returns a pointer to a row of system-specific elements? Because that's what I think I'm seeing...

Yes.

but TLazIntfImage.GetDataLineStart() returns a pointer to a row of system-specific elements? Because that's what I think I'm seeing...

Yes.
TLazIntfImage is a TFPCustomImageTFPImage and can handle a wide range of different memory images.
Probably the carbon interface returned a wrong description.

Mattias

Mattias Gaertner wrote

TLazIntfImage is a TFPCustomImageTFPImage and can handle a wide range of different memory images. Probably the carbon interface returned a wrong description.

It does return wrong description, at least for Intel mac's TRawImage (when updating TBitmap).
I've tried to fix it, but didn't have enough time for this.

AFAIK, TLazIntfImage description is based on TRawImage descrption.

thanks,
dmitry

On 7/6/2010 01:35, Wolfram S?ns wrote:

comparison in Windows vs Mac format... since it is hard to create a decent chart, this will be done in two lines for each one that is different with Windows first and then Mac...

these are the 5 that are different that i find... their differences seem to me to be to be enough to give the results that wolfram is seeing... but i may also be looking in a wrong direction...

Waldo, of course you are right; I saw this descriptions, too. But when I copy a TlazIntfImage back to an TImage (on a form) it looks completely identical on windows and mac. So I just expected that the values inside (when I get them pixel by pixel) are identical, too.

I am not deep enough in Lazarus yet ( I began a few weeks ago) to understand

Wolfram S?ns wrote

Waldo, of course you are right; I saw this descriptions, too. But when I copy a TlazIntfImage back to an TImage (on a form) it looks completely identical on windows and mac. So I just expected that the values inside (when I get them pixel by pixel) are identical, too.

one of the thoughts i've had on this is that copying the same picture file to windows or mac machines won't change the actual byte ordering inside the picture file... so i was confused like you as well...

I believe I have also seen a colour disparity on two x86 Linux systems, with an identical binary, but I can't at the moment investigate. The only reason I mention this is so that nobody gets too hung up on LSB/MSB or alignment, to the exclusion of bits-per-pixel.

2010/7/5 Wolfram S?ns :

Please test 26791 Lazarus revision.

thanks,
dmitry

Privet Dmitry,

now it works! Thanks a lot.
Wolfram

Wolfram S?ns wrote

now it works! Thanks a lot.

Sie sind herzlich eingeladen!

if you find more bugs with Carbon graphics, please report them to bugs.freepascal.org, otherwise they might be forgotten. But still feel free to discuss them on the mailing list.

thanks,
dmitry