In memory JPEG encoding

[wilbert]

I would like in memory jpeg encoding.
On the internet I found a bit of code that makes this possible using jpeglib.
The code expects a buffer of raw rgb data as input.
So I have a few questions.

- Is it reliable to refer to libpbjpeg.a distributed with PB in the .desc file of my user library (in other words, does it most likely stay at the same place in future PB versions) ?
- Is there a OSX equivalent of the Windows GetDIBits function to get the rgb data of a PB image ?

[Fred]

Yes, it's reliable to use the libjpeg which ships with PB.

[wilbert]

Thanks Fred, good to know.

Can you also tell me what kind of structure the pointer returned by ImageID refers to on OSX ?
Is it a pixmap ?

[Fred]

Nothing you can use .

[wilbert]

Oh no, nothing I can use

Well, I would like an easy way to access the pixel data (if possible).
If I use the DrawingBuffer() method, it looks like the type is always #PB_PixelFormat_32Bits_RGB regardless of how an image was created.
Is this true for OSX or do I need to check all possible types listed in the PB docs ?

[wilbert]

I decided to use DrawingBuffer() to get to the pixel data and that works fine.
The only thing left are the different pixel formats. The 24 and 32 bit formats are no problem but I can't seem to find information on the bit order of the 15 and 16 bit formats.
If those don't occur on Windows or OSX it's easy, I will just skip them but if they do occur, can someone please tell me what bits are for red, green and blue.

[Fred]

They don't occurs. BTW, using Plot()/Point() on images should be really fast as well with v4.40.

[wilbert]

Thanks Fred, I got it working now.

Funny to see the speed results when I compared the in memory encoding with saving to disk and loading the encoded data back using PB functions on both OSX and Windows.
I expected in memory to be faster and most of the times it was a little faster. There was one exception. 24 bit images on Windows were faster encoded by writing them to disk and reading them back using the built in PB functions compared to the in memory function I used.

[jamirokwai]

Thanks Fred, I got it working now.

Funny to see the speed results when I compared the in memory encoding with saving to disk and loading the encoded data back using PB functions on both OSX and Windows.
I expected in memory to be faster and most of the times it was a little faster. There was one exception. 24 bit images on Windows were faster encoded by writing them to disk and reading them back using the built in PB functions compared to the in memory function I used.

Hi Wilbert,

would you mind sharing your experience???
Would be great to know more about the Mac OS X-Version of PureBasic!

[wilbert]

Hi JamiroKwai,

I'm using a intel based iMac with both OSX and Windows installed on it.
What has my interest at the moment is mainly how to do cross platform coding with those two operating systems.
I know it's possible to write custom code in PureBasic and compile parts of the code depending on what OS the source is compiled on but for some things I need sometimes it seemed logical to me to try to create a cross platform userlib.
To do so I have used NASM and for the in memory encoding GCC since it was a C++ source I had to modify (quite a challenge since I never used C++ before). Both NASM and GCC are available on OSX and Windows. One of the things that I find complicated is to find the right information on the operating system functions for OSX. As long as you use PB functions, you deal with the same logic on all platforms. Both the solutions Microsoft has chosen and the solutions Apple has chosen often make sense but sometimes in a different way.

The end result for my cross platform solution to encode a jpeg in memory looks like this

Code: Select all

dest = AllocateMemory(1024 * 1024)
destLen = MemorySize(dest)

CreateImage(0,800,800,24)
StartDrawing(ImageOutput(0))

  Box(1,1,798,798,RGB(64,64,64))
  Circle(400, 400, 350, RGB(255,0,0))  
  Circle(400, 400, 250, RGB(0,255,0))  
  Circle(400, 400, 150, RGB(0,0,255))  

  wxl_EncodePixelFormat(DrawingBufferPixelFormat())
  len = wxl_JPEGEncode(DrawingBuffer(), ImageWidth(0), ImageHeight(0), 80, dest, destLen, DrawingBufferPitch())

StopDrawing()

CreateFile(0, "test.jpg")
  WriteData(0, dest, len)
CloseFile(0)

Of course it does not make sense to write the data as a real jpeg to disk. You wouldn't need this functionality in this case but it's just to check if things are working.
UserLib : http://www.w73.nl/pb/wxl_Lib.zip (I still have to do the docs).

[jamirokwai]

The end result for my cross platform solution to encode a jpeg in memory looks like this

So you move the cross-plattform-parts into the user library for the correct OS? Nice idea.
At the moment, I put code in CompilerSelects according to the OS, as I didn't need API calls before.
I think, I have to read more about UserLibs
Thanks for the information.

[wilbert]

Yes, if possible I put the cross platform parts in a userlibrary.
If it is code that I know I only use once, that makes of course little sense. In that case CompilerSelect is a better solution.
The other big advantage of a userlib to me is that it keeps my main code cleaner.