Example usage of ossimMemoryImageSource

Question

Example usage of ossimMemoryImageSource

ghansham opened this issue 5 years ago · 13 comments

Hi

I have a general raster data along with its metadata (width, height, number of bands, nullpix value and data type) as a C buffer and I want to use this data in the image chain without dumping onto the disk and going via ossimGeneralRasterTileSource route.
Seems like ossimMemoryImageSource can help in this case. Kindly guide.
Can illustrate an example of how to populate ossimMemoryImageSource from the afore-mentioned C buffer.

Ghansham and Tushar

Answer 1 · 2019-05-29T11:03:17.000Z

Hello: If you want to see a quick example, I used it in our 3-D viewer in the ossim-planet repo: ossimplanet-chip.cpp file. Here is a cut an paste of just that part of the code: ossimRefPtr<ossimImageData> imageData = new ossimImageData(0,OSSIM_UINT8, 4, image->s(), image->t()); imageData->initialize(); imageData->loadTile(image->data(), ossimIrect(0,0,image->s()-1, image->t()-1), OSSIM_BIP); imageData->validate(); ossimRefPtr<ossimMemoryImageSource> memSource = new ossimMemoryImageSource(); memSource->setImage(imageData.get()); ossimRefPtr<ossimJpegWriter> jpegWriter = new ossimJpegWriter(); jpegWriter->connectMyInputTo(0, memSource.get()); jpegWriter->setFilename(ossimFilename("/tmp/output.jpg")); jpegWriter->execute(); Take care Garrett

…

On May 28, 2019, at 6:32 AM, ghansham ***@***.***> wrote: Hi I have a general raster data along with its metadata (width, height, number of bands, nullpix value and data type) as a C buffer and I want to use this data in the image chain without dumping onto the disk and going via ossimGeneralRasterTileSource route. Seems like ossimMemoryImageSource can help in this case. Kindly guide. Can illustrate an example of how to populate ossimMemoryImageSource from the afore-mentioned C buffer. Ghansham and Tushar — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#224?email_source=notifications&email_token=ABVG7STUYF5WG2ENKZLMDM3PXUC25A5CNFSM4HQCAHCKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GWGD53Q>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVG7ST46A42LW5NZQQ2BWLPXUC25ANCNFSM4HQCAHCA>.

Answer 2 · 2019-05-29T14:48:18.000Z

Thanks a lot. I am sure it will work for me. Meanwhile I have got some success in using concept of multi threaded programming for improving the reprojection of input image data to a given output projection. I am getting a speed up of 10 times when using 16 threads. I hope that may be useful to community. It is a proof of concept. Right now output is in memory. So wanted to use memoryImageSource.

Regards
Ghansham

Answer 3 · 2019-05-29T16:53:56.000Z

Hello Ghansham: Sounds very cool! Let me know Take care Garrett

…

On May 29, 2019, at 10:48 AM, ghansham ***@***.*** ***@***.***>> wrote: Thanks a lot. I am sure it will work for me. Meanwhile I have got some success in using concept of multi threaded programming for improving the reprojection of input image data to a given output projection. I am getting a speed up of 10 times when using 16 threads. I hope that may be useful to community. It is a proof of concept. Right now output is in memory. So wanted to use memoryImageSource. Regards Ghansham — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#224?email_source=notifications&email_token=ABVG7SV27CAWJ7RAFY7A223PX2JTJA5CNFSM4HQCAHCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWPSNOQ#issuecomment-496969402>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVG7SSETXCEYRRQFF2C55DPX2JTJANCNFSM4HQCAHCA>.

Answer 4 · 2019-05-29T16:53:59.000Z

Hello Ghansham: Sounds very cool! Thank you and take care Garrett

…

On May 29, 2019, at 10:48 AM, ghansham ***@***.*** ***@***.***>> wrote: Thanks a lot. I am sure it will work for me. Meanwhile I have got some success in using concept of multi threaded programming for improving the reprojection of input image data to a given output projection. I am getting a speed up of 10 times when using 16 threads. I hope that may be useful to community. It is a proof of concept. Right now output is in memory. So wanted to use memoryImageSource. Regards Ghansham — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#224?email_source=notifications&email_token=ABVG7SV27CAWJ7RAFY7A223PX2JTJA5CNFSM4HQCAHCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWPSNOQ#issuecomment-496969402>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVG7SSETXCEYRRQFF2C55DPX2JTJANCNFSM4HQCAHCA>.

Answer 5 · 2019-05-29T18:22:16.000Z

I am not conversant with github. But can share the code making a tar ball out of it. Let me know how to share. May be by email.

Answer 6 · 2019-05-30T07:34:01.000Z

Hi there..

The ossimImageData class returns all getSize*() functions ossim_uint32. For files> 4GB, it limits the buffers allocation. Do we have a better class to handle it.

regards
Ghansham

Answer 7 · 2019-05-30T07:34:27.000Z

Right now file size I am trying is 5.7GB.

regards
Ghansham

Answer 8 · 2019-05-30T07:53:16.000Z

Solution could be to make the getSize*() functions return type as ossim_uint64. But I dont know how much repercussions it will have on the overall library. I mean how many changes it will call for. Or we can make a imageData specialized class for large files.

Answer 9 · 2019-05-31T10:22:37.000Z

Hello: Try the dev branch now . I made several calls all have ossim_uint64 and ossim_int64 where appropriate Take care Garrett

…

On May 30, 2019, at 3:53 AM, ghansham ***@***.*** ***@***.***>> wrote: Solution could be to make the getSize*() functions return type as ossim_uint64. But I dont know how much repercussions it will have on the overall library. I mean how many changes it will call for. Or we can make a imageData specialized class for large files. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#224?email_source=notifications&email_token=ABVG7SRC2JCAP7SFZPQR4U3PX6BW5A5CNFSM4HQCAHCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWRUU4I#issuecomment-497240689>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVG7STQE4L7LV2KGZG4NODPX6BW5ANCNFSM4HQCAHCA>.

Answer 10 · 2019-05-31T14:18:38.000Z

Thanks a lot Sir. Can you share your email id. I wanted to share the improved code. My id is ghanshamsangar@gmail.com

Answer 11 · 2019-05-31T14:23:34.000Z

Just out of curosity. Will the child classes of ossimImageData be effected by 64 bit offset changes?

Answer 12 · 2019-06-06T08:28:13.000Z

Thanks Sir. This is working..

Answer 13 · 2019-06-06T11:07:37.000Z

Hello: Good deal! Glad it is working

…

On Jun 6, 2019, at 4:28 AM, ghansham ***@***.***> wrote: Thanks Sir. This is working.. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#224?email_source=notifications&email_token=ABVG7SVJVOXP233B224JDK3PZDDB7A5CNFSM4HQCAHCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXCDZVQ#issuecomment-499399894>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVG7SX3X3F2ERAKSZEFNBTPZDDB7ANCNFSM4HQCAHCA>.