FAQ
Hi all,

I've been working on my new OpenImageIO
<https://github.com/OpenImageIO>bindings for Go (
OpenImageIGo <https://github.com/justinfx/openimageigo>) and finally wrote
enough of the cgo bindings to be able to try some benchmarks. I'm getting
results that are less than what I had expected, and I am really hoping I am
just overlooking something big in my approach.

I'm comparing a resize operation between OpenImageIGo, a direct call to the
oiiotool binary included with the install of OpenImageIO itself, and the Go
bindings for ImageMagick <https://github.com/gographics/imagick> (which I
have previously been using)

End results: https://gist.github.com/justinfx/33931727822fbebc4aa5

$ time ./convert_oiio
real 0m0.549s
user 0m3.835s
sys 0m0.042s

$ time ./convert_imagick
real 0m0.102s
user 0m0.066s
sys 0m0.015s

$ time oiiotool /tmp/source.png -resize 320x240 -o /tmp/image_test3.png
real 0m0.123s
user 0m0.475s
sys 0m0.023s

Using:
https://github.com/justinfx/openimageigo
https://github.com/gographics/imagick

I know there is some overhead involved in cgo calls, but there are
very few calls involved in this process. I figured it couldn't
possibly be as fast as directly calling oiiotool, but I thought I
could get closer than what I am getting. The oiiotool call is
basically the equivalent of what I am doing in code (using the same
default filter settings and global thread count).

Would someone mind taking a glance at my implementation and possibly
point out any glaring issues or offer any tips related to the resize
operation I am testing?

Really appreciate any guidance on this.

-- justin

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Justin Israel at May 9, 2014 at 11:13 pm
    ::Bump:: If no one does reply, I promise not to bump again.

    Was just hoping someone with a spare 5 minutes could glance over my work,
    and offer any insight as to where I might have gone wrong in exposing the
    Resize operation as listed in the gist example (read, resize, write).

    I got a little bit discouraged when I finally got enough exposed and did
    some comparisons, and saw such big different in the processing times. Was
    hoping to switch out my Imagemagick bindings in my server for OpenImageIO.
    Maybe I did some really inefficient patterns with CGO. Maybe I am just
    missing something.



    On Fri, May 2, 2014 at 11:54 PM, Justin Israel wrote:

    Hi all,

    I've been working on my new OpenImageIO <https://github.com/OpenImageIO>bindings for Go (
    OpenImageIGo <https://github.com/justinfx/openimageigo>) and finally
    wrote enough of the cgo bindings to be able to try some benchmarks. I'm
    getting results that are less than what I had expected, and I am really
    hoping I am just overlooking something big in my approach.

    I'm comparing a resize operation between OpenImageIGo, a direct call to
    the oiiotool binary included with the install of OpenImageIO itself, and
    the Go bindings for ImageMagick <https://github.com/gographics/imagick>(which I have previously been using)

    End results: https://gist.github.com/justinfx/33931727822fbebc4aa5

    $ time ./convert_oiio

    real 0m0.549s
    user 0m3.835s

    sys 0m0.042s


    $ time ./convert_imagick
    real 0m0.102s
    user 0m0.066s

    sys 0m0.015s


    $ time oiiotool /tmp/source.png -resize 320x240 -o /tmp/image_test3.png

    real 0m0.123s
    user 0m0.475s

    sys 0m0.023s

    Using:
    https://github.com/justinfx/openimageigo
    https://github.com/gographics/imagick

    I know there is some overhead involved in cgo calls, but there are very few calls involved in this process. I figured it couldn't possibly be as fast as directly calling oiiotool, but I thought I could get closer than what I am getting. The oiiotool call is basically the equivalent of what I am doing in code (using the same default filter settings and global thread count).

    Would someone mind taking a glance at my implementation and possibly point out any glaring issues or offer any tips related to the resize operation I am testing?

    Really appreciate any guidance on this.

    -- justin
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matt Harden at May 10, 2014 at 1:51 am
    I'm just wondering, why do you use oiio.NewImageSpecSize(WIDTH, HEIGHT, 3,
    oiio.TypeFloat)? I suspect using floating point pixel data is slower than
    uint8 (oiio.TypeUint8), and it looks like it will write the output image
    with 16 bit channels (48 bits per pixel) to avoid losing precision from the
    internal floating point pixels. To do the same thing that oiiotool does,
    you need to copy the datatype selection from the source image.

    On Fri, May 9, 2014 at 6:13 PM, Justin Israel wrote:

    ::Bump:: If no one does reply, I promise not to bump again.

    Was just hoping someone with a spare 5 minutes could glance over my work,
    and offer any insight as to where I might have gone wrong in exposing the
    Resize operation as listed in the gist example (read, resize, write).

    I got a little bit discouraged when I finally got enough exposed and did
    some comparisons, and saw such big different in the processing times. Was
    hoping to switch out my Imagemagick bindings in my server for OpenImageIO.
    Maybe I did some really inefficient patterns with CGO. Maybe I am just
    missing something.



    On Fri, May 2, 2014 at 11:54 PM, Justin Israel wrote:

    Hi all,

    I've been working on my new OpenImageIO <https://github.com/OpenImageIO>bindings for Go (
    OpenImageIGo <https://github.com/justinfx/openimageigo>) and finally
    wrote enough of the cgo bindings to be able to try some benchmarks. I'm
    getting results that are less than what I had expected, and I am really
    hoping I am just overlooking something big in my approach.

    I'm comparing a resize operation between OpenImageIGo, a direct call to
    the oiiotool binary included with the install of OpenImageIO itself, and
    the Go bindings for ImageMagick <https://github.com/gographics/imagick>(which I have previously been using)

    End results: https://gist.github.com/justinfx/33931727822fbebc4aa5

    $ time ./convert_oiio



    real 0m0.549s
    user 0m3.835s



    sys 0m0.042s




    $ time ./convert_imagick
    real 0m0.102s
    user 0m0.066s



    sys 0m0.015s




    $ time oiiotool /tmp/source.png -resize 320x240 -o /tmp/image_test3.png



    real 0m0.123s
    user 0m0.475s



    sys 0m0.023s

    Using:
    https://github.com/justinfx/openimageigo


    https://github.com/gographics/imagick



    I know there is some overhead involved in cgo calls, but there are very few calls involved in this process. I figured it couldn't possibly be as fast as directly calling oiiotool, but I thought I could get closer than what I am getting. The oiiotool call is basically the equivalent of what I am doing in code (using the same default filter settings and global thread count).



    Would someone mind taking a glance at my implementation and possibly point out any glaring issues or offer any tips related to the resize operation I am testing?



    Really appreciate any guidance on this.


    -- justin
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Justin Israel at May 10, 2014 at 6:05 am
    Hey Matt,

    Totally appreciate you looking into it! What you said completely made sense
    and I went to give it a try using the same spec as the source, with just a
    modified width/height, and it apparently made no difference in the
    performance. Not sure where to go with it now :-/


    On Sat, May 10, 2014 at 1:51 PM, Matt Harden wrote:

    I'm just wondering, why do you use oiio.NewImageSpecSize(WIDTH, HEIGHT,
    3, oiio.TypeFloat)? I suspect using floating point pixel data is slower
    than uint8 (oiio.TypeUint8), and it looks like it will write the output
    image with 16 bit channels (48 bits per pixel) to avoid losing precision
    from the internal floating point pixels. To do the same thing that oiiotool
    does, you need to copy the datatype selection from the source image.

    On Fri, May 9, 2014 at 6:13 PM, Justin Israel wrote:

    ::Bump:: If no one does reply, I promise not to bump again.

    Was just hoping someone with a spare 5 minutes could glance over my work,
    and offer any insight as to where I might have gone wrong in exposing the
    Resize operation as listed in the gist example (read, resize, write).

    I got a little bit discouraged when I finally got enough exposed and did
    some comparisons, and saw such big different in the processing times. Was
    hoping to switch out my Imagemagick bindings in my server for OpenImageIO.
    Maybe I did some really inefficient patterns with CGO. Maybe I am just
    missing something.



    On Fri, May 2, 2014 at 11:54 PM, Justin Israel wrote:

    Hi all,

    I've been working on my new OpenImageIO <https://github.com/OpenImageIO>bindings for Go (
    OpenImageIGo <https://github.com/justinfx/openimageigo>) and finally
    wrote enough of the cgo bindings to be able to try some benchmarks. I'm
    getting results that are less than what I had expected, and I am really
    hoping I am just overlooking something big in my approach.

    I'm comparing a resize operation between OpenImageIGo, a direct call to
    the oiiotool binary included with the install of OpenImageIO itself, and
    the Go bindings for ImageMagick <https://github.com/gographics/imagick>(which I have previously been using)

    End results: https://gist.github.com/justinfx/33931727822fbebc4aa5

    $ time ./convert_oiio




    real 0m0.549s
    user 0m3.835s




    sys 0m0.042s





    $ time ./convert_imagick
    real 0m0.102s
    user 0m0.066s




    sys 0m0.015s





    $ time oiiotool /tmp/source.png -resize 320x240 -o /tmp/image_test3.png




    real 0m0.123s
    user 0m0.475s




    sys 0m0.023s

    Using:
    https://github.com/justinfx/openimageigo



    https://github.com/gographics/imagick




    I know there is some overhead involved in cgo calls, but there are very few calls involved in this process. I figured it couldn't possibly be as fast as directly calling oiiotool, but I thought I could get closer than what I am getting. The oiiotool call is basically the equivalent of what I am doing in code (using the same default filter settings and global thread count).




    Would someone mind taking a glance at my implementation and possibly point out any glaring issues or offer any tips related to the resize operation I am testing?




    Really appreciate any guidance on this.



    -- justin
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matt Harden at May 10, 2014 at 4:49 pm
    Profile.

    On Sat, May 10, 2014 at 1:05 AM, Justin Israel wrote:

    Hey Matt,

    Totally appreciate you looking into it! What you said completely made
    sense and I went to give it a try using the same spec as the source, with
    just a modified width/height, and it apparently made no difference in the
    performance. Not sure where to go with it now :-/


    On Sat, May 10, 2014 at 1:51 PM, Matt Harden wrote:

    I'm just wondering, why do you use oiio.NewImageSpecSize(WIDTH, HEIGHT,
    3, oiio.TypeFloat)? I suspect using floating point pixel data is slower
    than uint8 (oiio.TypeUint8), and it looks like it will write the output
    image with 16 bit channels (48 bits per pixel) to avoid losing precision
    from the internal floating point pixels. To do the same thing that oiiotool
    does, you need to copy the datatype selection from the source image.

    On Fri, May 9, 2014 at 6:13 PM, Justin Israel wrote:

    ::Bump:: If no one does reply, I promise not to bump again.

    Was just hoping someone with a spare 5 minutes could glance over my
    work, and offer any insight as to where I might have gone wrong in exposing
    the Resize operation as listed in the gist example (read, resize, write).

    I got a little bit discouraged when I finally got enough exposed and did
    some comparisons, and saw such big different in the processing times. Was
    hoping to switch out my Imagemagick bindings in my server for OpenImageIO.
    Maybe I did some really inefficient patterns with CGO. Maybe I am just
    missing something.



    On Fri, May 2, 2014 at 11:54 PM, Justin Israel wrote:

    Hi all,

    I've been working on my new OpenImageIO<https://github.com/OpenImageIO>bindings for Go (
    OpenImageIGo <https://github.com/justinfx/openimageigo>) and finally
    wrote enough of the cgo bindings to be able to try some benchmarks. I'm
    getting results that are less than what I had expected, and I am really
    hoping I am just overlooking something big in my approach.

    I'm comparing a resize operation between OpenImageIGo, a direct call to
    the oiiotool binary included with the install of OpenImageIO itself, and
    the Go bindings for ImageMagick <https://github.com/gographics/imagick>(which I have previously been using)

    End results: https://gist.github.com/justinfx/33931727822fbebc4aa5


    $ time ./convert_oiio






    real 0m0.549s
    user 0m3.835s






    sys 0m0.042s







    $ time ./convert_imagick
    real 0m0.102s
    user 0m0.066s






    sys 0m0.015s







    $ time oiiotool /tmp/source.png -resize 320x240 -o /tmp/image_test3.png






    real 0m0.123s
    user 0m0.475s






    sys 0m0.023s

    Using:
    https://github.com/justinfx/openimageigo





    https://github.com/gographics/imagick






    I know there is some overhead involved in cgo calls, but there are very few calls involved in this process. I figured it couldn't possibly be as fast as directly calling oiiotool, but I thought I could get closer than what I am getting. The oiiotool call is basically the equivalent of what I am doing in code (using the same default filter settings and global thread count).






    Would someone mind taking a glance at my implementation and possibly point out any glaring issues or offer any tips related to the resize operation I am testing?






    Really appreciate any guidance on this.





    -- justin
    --
    You received this message because you are subscribed to the Google
    Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Justin Israel at May 11, 2014 at 8:45 am
    Yea. I though it was just a "thing" that when profiling a CGO app you would
    see "etext" for the places where it is in C. So I thought profiling wasn't
    going to tell me much. Then I found that it is a limitation/bug on OSX and
    found the kernel patch I can try. Will have to check this out. But I am
    pretty sure it just comes down to some combination of values that is being
    passed differently, since all of the lag is happening in the C Resize().

    On Sun, May 11, 2014 at 4:48 AM, Matt Harden wrote:

    Profile.

    On Sat, May 10, 2014 at 1:05 AM, Justin Israel wrote:

    Hey Matt,

    Totally appreciate you looking into it! What you said completely made
    sense and I went to give it a try using the same spec as the source, with
    just a modified width/height, and it apparently made no difference in the
    performance. Not sure where to go with it now :-/


    On Sat, May 10, 2014 at 1:51 PM, Matt Harden wrote:

    I'm just wondering, why do you use oiio.NewImageSpecSize(WIDTH, HEIGHT,
    3, oiio.TypeFloat)? I suspect using floating point pixel data is slower
    than uint8 (oiio.TypeUint8), and it looks like it will write the output
    image with 16 bit channels (48 bits per pixel) to avoid losing precision
    from the internal floating point pixels. To do the same thing that oiiotool
    does, you need to copy the datatype selection from the source image.

    On Fri, May 9, 2014 at 6:13 PM, Justin Israel wrote:

    ::Bump:: If no one does reply, I promise not to bump again.

    Was just hoping someone with a spare 5 minutes could glance over my
    work, and offer any insight as to where I might have gone wrong in exposing
    the Resize operation as listed in the gist example (read, resize, write).

    I got a little bit discouraged when I finally got enough exposed and
    did some comparisons, and saw such big different in the processing times.
    Was hoping to switch out my Imagemagick bindings in my server for
    OpenImageIO. Maybe I did some really inefficient patterns with CGO. Maybe I
    am just missing something.



    On Fri, May 2, 2014 at 11:54 PM, Justin Israel wrote:

    Hi all,

    I've been working on my new OpenImageIO<https://github.com/OpenImageIO>bindings for Go (
    OpenImageIGo <https://github.com/justinfx/openimageigo>) and finally
    wrote enough of the cgo bindings to be able to try some benchmarks. I'm
    getting results that are less than what I had expected, and I am really
    hoping I am just overlooking something big in my approach.

    I'm comparing a resize operation between OpenImageIGo, a direct call
    to the oiiotool binary included with the install of OpenImageIO itself, and
    the Go bindings for ImageMagick<https://github.com/gographics/imagick>(which I have previously been using)

    End results: https://gist.github.com/justinfx/33931727822fbebc4aa5


    $ time ./convert_oiio







    real 0m0.549s
    user 0m3.835s







    sys 0m0.042s








    $ time ./convert_imagick
    real 0m0.102s
    user 0m0.066s







    sys 0m0.015s








    $ time oiiotool /tmp/source.png -resize 320x240 -o /tmp/image_test3.png







    real 0m0.123s
    user 0m0.475s







    sys 0m0.023s

    Using:
    https://github.com/justinfx/openimageigo






    https://github.com/gographics/imagick







    I know there is some overhead involved in cgo calls, but there are very few calls involved in this process. I figured it couldn't possibly be as fast as directly calling oiiotool, but I thought I could get closer than what I am getting. The oiiotool call is basically the equivalent of what I am doing in code (using the same default filter settings and global thread count).







    Would someone mind taking a glance at my implementation and possibly point out any glaring issues or offer any tips related to the resize operation I am testing?







    Really appreciate any guidance on this.






    -- justin
    --
    You received this message because you are subscribed to the Google
    Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Justin Israel at May 11, 2014 at 10:11 pm
    Took the conversation over to the oiio-dev mailing list and found that it
    is completely related to some idiosyncrasies in the resize behavior and
    source image settings. So it would seem from the cgo side of things that I
    am all well and good.
    Thanks again for the help!
      On May 2, 2014 11:54 PM, "Justin Israel" wrote:

    Hi all,

    I've been working on my new OpenImageIO <https://github.com/OpenImageIO>bindings for Go (
    OpenImageIGo <https://github.com/justinfx/openimageigo>) and finally
    wrote enough of the cgo bindings to be able to try some benchmarks. I'm
    getting results that are less than what I had expected, and I am really
    hoping I am just overlooking something big in my approach.

    I'm comparing a resize operation between OpenImageIGo, a direct call to
    the oiiotool binary included with the install of OpenImageIO itself, and
    the Go bindings for ImageMagick <https://github.com/gographics/imagick>(which I have previously been using)

    End results: https://gist.github.com/justinfx/33931727822fbebc4aa5

    $ time ./convert_oiio

    real 0m0.549s
    user 0m3.835s

    sys 0m0.042s


    $ time ./convert_imagick
    real 0m0.102s
    user 0m0.066s

    sys 0m0.015s


    $ time oiiotool /tmp/source.png -resize 320x240 -o /tmp/image_test3.png

    real 0m0.123s
    user 0m0.475s

    sys 0m0.023s

    Using:
    https://github.com/justinfx/openimageigo
    https://github.com/gographics/imagick

    I know there is some overhead involved in cgo calls, but there are very few calls involved in this process. I figured it couldn't possibly be as fast as directly calling oiiotool, but I thought I could get closer than what I am getting. The oiiotool call is basically the equivalent of what I am doing in code (using the same default filter settings and global thread count).

    Would someone mind taking a glance at my implementation and possibly point out any glaring issues or offer any tips related to the resize operation I am testing?

    Really appreciate any guidance on this.

    -- justin
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 2, '14 at 11:54a
activeMay 11, '14 at 10:11p
posts7
users2
websitegolang.org

2 users in discussion

Justin Israel: 5 posts Matt Harden: 2 posts

People

Translate

site design / logo © 2022 Grokbase