How to access the preview thumnail image of original big picture

GoranT · May 30, 2012, 2:13pm

Hi,
http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2[%40version%3Dnull+and+%40uiVersion%3Dnull]%2Fgeotagger[%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe]%2FImage
I am working with ODK Open Data Kit where i insert some big images.
Every image is about 1,5 MByte.
Accessing and displaying in the browser or any other application takes
few seconds.

There are also previews- when saved to hdd about 1,6 Kbyte: add
&previewImage=true
http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2[%40version%3Dnull+and+%40uiVersion%3Dnull]%2Fgeotagger[%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe]%2FImage&previewImage=true

But accessing that 1,6Kbyte preview takes also some seconds.

Is that preview image a real "small" image from the original picture
or is it just the big picture scaled down?
Why does it take the same time to access the small preview and the
original big picture?

Is there any way to access the preview image faster?

Mitch_S · May 30, 2012, 5:29pm

The previews are generated on the fly, and are not stored.

When viewing data on the Submissions pages, keep in mind that you are
making a heavy demand on the server because it needs to access and resize
100 images per page, by default (or more, if you have several images per
submission, or if you increased the submissions-per-page value). AppEngine
will "spin up" extra instances of your application to handle this load, and
will queue requests to those instances so that it handles only a few at a
time (it is unclear how many requests are handled simultaneously). I've
seen it take up to 30 seconds to "spin up" an extra instance, so that will
add an initial delay to the rendering of these images. However, once you
have spun up a sufficient number of instances to handle the image
rendering, the image rendering when paging to the next set of submission
results should be much faster.

Within the server, the next concern is the housekeeping the server needs to
do as it reads these 1.5MB images, resizes them, and sends the smaller
thumbnail to your browser. This housekeeping is called "garbage
collection" and that occurs whenever the server has written data on the
majority of memory under its control. The greater the memory available, the
less frequent the garbage collection. On AppEngine, there is now a setting
to pick the CPU speed and memory size of your server via the Frontend
Instance Class -- go to your dashboard via https://appengine.google.com/ ,
click on your application id, click on Application Settings, then under
Performance, you will see "Frontend Instance Class" and a drop-down list.
Experiment with changing this to a faster and bigger instance. I haven't
played around with this, and without knowledge of how many simultaneous
requests Google allows the server to handle, I can't say whether you would
see a significant change in performance. Again, though, this will only
have an impact after AppEngine has "spun up" as many instances as it deems
necessary to handle the requests triggered when advancing through the
submissions pages; the "spinning up" time will still be a major factor in
the sluggishness.

Other things to consider:

(1) client computer with more memory or faster CPU. You should compare
access times among a range of client computers (and even the browser on
your Android cell phones). It can give you an idea of how much the speed
and main memory sizes of those computers affect the rendering time of the
images. Also try different browsers.

(2) faster internet connection. If your internet connection is DSL
(256kb/sec) or satellite, or an older/slower Ethernet or WiFi connection,
this may be what is causing the slow response time for the larger images.
It can also impact the rendering of all the images on a single
100-submissions page, as that has 100 x 1.6kB = 160kB * 8b/B = 1.28Mb of
data. For DSL, this would mean 4 seconds minimum to complete the rendering
of the page.

(3) it could be a transient slow-down in the Google infrastructure, which
you can monitor here: http://code.google.com/status/appengine e.g., Java
response times are reported to be "elevated" right now.

···

---------------------

Mitch

On Wed, May 30, 2012 at 7:13 AM, GoranT geronimoooooooo@gmail.com wrote:

Hi,

http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2[%40version%3Dnull+and+%40uiVersion%3Dnull]%2Fgeotagger[%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe]%2FImage
I am working with ODK Open Data Kit where i insert some big images.
Every image is about 1,5 MByte.
Accessing and displaying in the browser or any other application takes
few seconds.

There are also previews- when saved to hdd about 1,6 Kbyte: add
&previewImage=true

http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2[%40version%3Dnull+and+%40uiVersion%3Dnull]%2Fgeotagger[%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe]%2FImage&previewImage=true

But accessing that 1,6Kbyte preview takes also some seconds.

Is that preview image a real "small" image from the original picture
or is it just the big picture scaled down?
Why does it take the same time to access the small preview and the
original big picture?

Is there any way to access the preview image faster?

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Mitch_S · May 30, 2012, 5:35pm

And I should add, after first paging forward through the data, when you
page backward, the images should be rendered from cached files on your PC
(no request is made to the server). So when you go backward through the
pages, that indicates how fast/slow your PC is to render the images using
only the local data. It generally takes a few seconds.

Mitch

···

On Wed, May 30, 2012 at 10:29 AM, Mitch S wrote:

The previews are generated on the fly, and are not stored.

When viewing data on the Submissions pages, keep in mind that you are
making a heavy demand on the server because it needs to access and resize
100 images per page, by default (or more, if you have several images per
submission, or if you increased the submissions-per-page value). AppEngine
will "spin up" extra instances of your application to handle this load, and
will queue requests to those instances so that it handles only a few at a
time (it is unclear how many requests are handled simultaneously). I've
seen it take up to 30 seconds to "spin up" an extra instance, so that will
add an initial delay to the rendering of these images. However, once you
have spun up a sufficient number of instances to handle the image
rendering, the image rendering when paging to the next set of submission
results should be much faster.

Within the server, the next concern is the housekeeping the server needs
to do as it reads these 1.5MB images, resizes them, and sends the smaller
thumbnail to your browser. This housekeeping is called "garbage
collection" and that occurs whenever the server has written data on the
majority of memory under its control. The greater the memory available, the
less frequent the garbage collection. On AppEngine, there is now a setting
to pick the CPU speed and memory size of your server via the Frontend
Instance Class -- go to your dashboard via https://appengine.google.com/, click on your application id, click on Application Settings, then under
Performance, you will see "Frontend Instance Class" and a drop-down list.
Experiment with changing this to a faster and bigger instance. I haven't
played around with this, and without knowledge of how many simultaneous
requests Google allows the server to handle, I can't say whether you would
see a significant change in performance. Again, though, this will only
have an impact after AppEngine has "spun up" as many instances as it deems
necessary to handle the requests triggered when advancing through the
submissions pages; the "spinning up" time will still be a major factor in
the sluggishness.

Other things to consider:

(1) client computer with more memory or faster CPU. You should compare
access times among a range of client computers (and even the browser on
your Android cell phones). It can give you an idea of how much the speed
and main memory sizes of those computers affect the rendering time of the
images. Also try different browsers.

(2) faster internet connection. If your internet connection is DSL
(256kb/sec) or satellite, or an older/slower Ethernet or WiFi connection,
this may be what is causing the slow response time for the larger images.
It can also impact the rendering of all the images on a single
100-submissions page, as that has 100 x 1.6kB = 160kB * 8b/B = 1.28Mb of
data. For DSL, this would mean 4 seconds minimum to complete the rendering
of the page.

(3) it could be a transient slow-down in the Google infrastructure, which
you can monitor here: http://code.google.com/status/appengine e.g., Java
response times are reported to be "elevated" right now.

Mitch

On Wed, May 30, 2012 at 7:13 AM, GoranT geronimoooooooo@gmail.com wrote:

Hi,

http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2[%40version%3Dnull+and+%40uiVersion%3Dnull]%2Fgeotagger[%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe]%2FImage
I am working with ODK Open Data Kit where i insert some big images.
Every image is about 1,5 MByte.
Accessing and displaying in the browser or any other application takes
few seconds.

There are also previews- when saved to hdd about 1,6 Kbyte: add
&previewImage=true

http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2[%40version%3Dnull+and+%40uiVersion%3Dnull]%2Fgeotagger[%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe]%2FImage&previewImage=true

But accessing that 1,6Kbyte preview takes also some seconds.

Is that preview image a real "small" image from the original picture
or is it just the big picture scaled down?
Why does it take the same time to access the small preview and the
original big picture?

Is there any way to access the preview image faster?

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Mitch_S · May 30, 2012, 5:40pm

Hmmm. Doesn't look like the images are being cached on the PC as I would
expect. Opened this ticket:
http://code.google.com/p/opendatakit/issues/detail?id=583

Mitch

···

On Wed, May 30, 2012 at 10:35 AM, Mitch S wrote:

And I should add, after first paging forward through the data, when you
page backward, the images should be rendered from cached files on your PC
(no request is made to the server). So when you go backward through the
pages, that indicates how fast/slow your PC is to render the images using
only the local data. It generally takes a few seconds.

Mitch

On Wed, May 30, 2012 at 10:29 AM, Mitch S mitchellsundt@gmail.com wrote:

The previews are generated on the fly, and are not stored.

When viewing data on the Submissions pages, keep in mind that you are
making a heavy demand on the server because it needs to access and resize
100 images per page, by default (or more, if you have several images per
submission, or if you increased the submissions-per-page value). AppEngine
will "spin up" extra instances of your application to handle this load, and
will queue requests to those instances so that it handles only a few at a
time (it is unclear how many requests are handled simultaneously). I've
seen it take up to 30 seconds to "spin up" an extra instance, so that will
add an initial delay to the rendering of these images. However, once you
have spun up a sufficient number of instances to handle the image
rendering, the image rendering when paging to the next set of submission
results should be much faster.

Within the server, the next concern is the housekeeping the server needs
to do as it reads these 1.5MB images, resizes them, and sends the smaller
thumbnail to your browser. This housekeeping is called "garbage
collection" and that occurs whenever the server has written data on the
majority of memory under its control. The greater the memory available, the
less frequent the garbage collection. On AppEngine, there is now a setting
to pick the CPU speed and memory size of your server via the Frontend
Instance Class -- go to your dashboard via https://appengine.google.com/, click on your application id, click on Application Settings, then under
Performance, you will see "Frontend Instance Class" and a drop-down list.
Experiment with changing this to a faster and bigger instance. I haven't
played around with this, and without knowledge of how many simultaneous
requests Google allows the server to handle, I can't say whether you would
see a significant change in performance. Again, though, this will only
have an impact after AppEngine has "spun up" as many instances as it deems
necessary to handle the requests triggered when advancing through the
submissions pages; the "spinning up" time will still be a major factor in
the sluggishness.

Other things to consider:

(1) client computer with more memory or faster CPU. You should compare
access times among a range of client computers (and even the browser on
your Android cell phones). It can give you an idea of how much the speed
and main memory sizes of those computers affect the rendering time of the
images. Also try different browsers.

(2) faster internet connection. If your internet connection is DSL
(256kb/sec) or satellite, or an older/slower Ethernet or WiFi connection,
this may be what is causing the slow response time for the larger images.
It can also impact the rendering of all the images on a single
100-submissions page, as that has 100 x 1.6kB = 160kB * 8b/B = 1.28Mb of
data. For DSL, this would mean 4 seconds minimum to complete the rendering
of the page.

(3) it could be a transient slow-down in the Google infrastructure, which
you can monitor here: http://code.google.com/status/appengine e.g.,
Java response times are reported to be "elevated" right now.

Mitch

On Wed, May 30, 2012 at 7:13 AM, GoranT geronimoooooooo@gmail.comwrote:

Hi,

http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2[%40version%3Dnull+and+%40uiVersion%3Dnull]%2Fgeotagger[%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe]%2FImage
I am working with ODK Open Data Kit where i insert some big images.
Every image is about 1,5 MByte.
Accessing and displaying in the browser or any other application takes
few seconds.

There are also previews- when saved to hdd about 1,6 Kbyte: add
&previewImage=true

http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2[%40version%3Dnull+and+%40uiVersion%3Dnull]%2Fgeotagger[%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe]%2FImage&previewImage=true

But accessing that 1,6Kbyte preview takes also some seconds.

Is that preview image a real "small" image from the original picture
or is it just the big picture scaled down?
Why does it take the same time to access the small preview and the
original big picture?

Is there any way to access the preview image faster?

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

W_Brunette · May 30, 2012, 5:49pm

If I recall correctly, Aggregate is scaling the picture down on the
server side but it does not store the scaled down image so it must do
the database retrieval of the full image which is slow then resize it,
then return across HTTP. This could definitely be optimized so feel
free to file an issue if this is causing you are problem.

Waylon

···

On Wed, May 30, 2012 at 10:40 AM, Mitch S wrote: > Hmmm. Doesn't look like the images are being cached on the PC as I would > expect. Opened this ticket: > http://code.google.com/p/opendatakit/issues/detail?id=583 > > Mitch > > > On Wed, May 30, 2012 at 10:35 AM, Mitch S wrote: >> >> And I should add, after first paging forward through the data, when you >> page backward, the images should be rendered from cached files on your PC >> (no request is made to the server). So when you go backward through the >> pages, that indicates how fast/slow your PC is to render the images using >> only the local data. It generally takes a few seconds. >> >> Mitch >> >> >> On Wed, May 30, 2012 at 10:29 AM, Mitch S wrote: >>> >>> The previews are generated on the fly, and are not stored. >>> >>> When viewing data on the Submissions pages, keep in mind that you are >>> making a heavy demand on the server because it needs to access and resize >>> 100 images per page, by default (or more, if you have several images per >>> submission, or if you increased the submissions-per-page value). AppEngine >>> will "spin up" extra instances of your application to handle this load, and >>> will queue requests to those instances so that it handles only a few at a >>> time (it is unclear how many requests are handled simultaneously). I've seen >>> it take up to 30 seconds to "spin up" an extra instance, so that will add an >>> initial delay to the rendering of these images. However, once you have spun >>> up a sufficient number of instances to handle the image rendering, the image >>> rendering when paging to the next set of submission results should be much >>> faster. >>> >>> Within the server, the next concern is the housekeeping the server needs >>> to do as it reads these 1.5MB images, resizes them, and sends the smaller >>> thumbnail to your browser. This housekeeping is called "garbage collection" >>> and that occurs whenever the server has written data on the majority of >>> memory under its control. The greater the memory available, the less >>> frequent the garbage collection. On AppEngine, there is now a setting to >>> pick the CPU speed and memory size of your server via the Frontend Instance >>> Class -- go to your dashboard via https://appengine.google.com/ , click on >>> your application id, click on Application Settings, then under Performance, >>> you will see "Frontend Instance Class" and a drop-down list. Experiment >>> with changing this to a faster and bigger instance. I haven't played around >>> with this, and without knowledge of how many simultaneous requests Google >>> allows the server to handle, I can't say whether you would see a significant >>> change in performance. Again, though, this will only have an impact after >>> AppEngine has "spun up" as many instances as it deems necessary to handle >>> the requests triggered when advancing through the submissions pages; the >>> "spinning up" time will still be a major factor in the sluggishness. >>> >>> Other things to consider: >>> >>> (1) client computer with more memory or faster CPU. You should compare >>> access times among a range of client computers (and even the browser on your >>> Android cell phones). It can give you an idea of how much the speed and >>> main memory sizes of those computers affect the rendering time of the >>> images. Also try different browsers. >>> >>> (2) faster internet connection. If your internet connection is DSL >>> (256kb/sec) or satellite, or an older/slower Ethernet or WiFi connection, >>> this may be what is causing the slow response time for the larger images. >>> It can also impact the rendering of all the images on a single >>> 100-submissions page, as that has 100 x 1.6kB = 160kB * 8b/B = 1.28Mb of >>> data. For DSL, this would mean 4 seconds minimum to complete the rendering >>> of the page. >>> >>> (3) it could be a transient slow-down in the Google infrastructure, which >>> you can monitor here: http://code.google.com/status/appengine e.g., Java >>> response times are reported to be "elevated" right now. >>> >>> --------------------- >>> >>> Mitch >>> >>> >>> On Wed, May 30, 2012 at 7:13 AM, GoranT wrote: >>>> >>>> Hi, >>>> >>>> http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2%5B%40version%3Dnull+and+%40uiVersion%3Dnull%5D%2Fgeotagger%5B%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe%5D%2FImage >>>> I am working with ODK Open Data Kit where i insert some big images. >>>> Every image is about 1,5 MByte. >>>> Accessing and displaying in the browser or any other application takes >>>> few seconds. >>>> >>>> There are also previews- when saved to hdd about 1,6 Kbyte: add >>>> &previewImage=true >>>> >>>> http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2%5B%40version%3Dnull+and+%40uiVersion%3Dnull%5D%2Fgeotagger%5B%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe%5D%2FImage&previewImage=true >>>> >>>> But accessing that 1,6Kbyte preview takes also some seconds. >>>> >>>> Is that preview image a real "small" image from the original picture >>>> or is it just the big picture scaled down? >>>> Why does it take the same time to access the small preview and the >>>> original big picture? >>>> >>>> Is there any way to access the preview image faster? >>>> >>>> -- >>>> Post: opendatakit@googlegroups.com >>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>> Options: http://groups.google.com/group/opendatakit?hl=en >>> >>> >>> >>> >>> -- >>> Mitch Sundt >>> Software Engineer >>> University of Washington >>> mitchellsundt@gmail.com >> >> >> >> >> -- >> Mitch Sundt >> Software Engineer >> University of Washington >> mitchellsundt@gmail.com > > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitchellsundt@gmail.com > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en

Mitch_S · September 24, 2012, 4:59pm

Have you updated to ODK Aggregate 1.2 ?

Thumbnail caching was enabled in that release.

Mitch

···

On Mon, Sep 24, 2012 at 6:07 AM, wrote:

Hi again,

Do we have any updates on this? Downloading 10 images = 10 MByte is kinda
to big

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

W_Brunette · September 24, 2012, 5:30pm

What Mitch is talking about is the fact that every time someone viewed
the submissions page the web browser used to request the preview
image. Now the preview image is accessed once and cached in your
browser so there are not repeated calls to get the preview image.

You need to add 'previewImage=true' as a parameter to the URL call to
get the smaller scaled down picture. Otherwise you will get the full
size of the picture.

Hope this helps.

Waylon

···

On Mon, Sep 24, 2012 at 10:23 AM, wrote: > Right now I can not check for the version. > > What do you exactly mean with "thumbnail caching"? > > My goal is to download ONLY the preview thumbnail which is 2Kbyte in size. I do not want to download the original image, which is e.g. 2Mbyte in size and cache those 2MByte. > > I hope those 2 images (preview thumbnail image and original image) are now 2 completly different images. > > greetings > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en

W_Brunette · September 24, 2012, 7:50pm

The code that provides all binary data is available here:

http://code.google.com/p/opendatakit/source/browse/src/main/java/org/opendatakit/aggregate/servlet/BinaryDataServlet.java?repo=aggregate

The actual code snippet that does the resize:

    if (contentType.equals(HtmlConsts.RESP_TYPE_IMAGE_JPEG)) {
      // resize
      ImageUtil imageUtil = (ImageUtil) cc.getBean(BeanDefs.IMAGE_UTIL);
      imageBlob = imageUtil.resizeImage(imageBlob, 64, 48);
    } else {
      // display not-able-to-resize image...
      imageBlob = playJPG;
    }

NOTE: If it is not JPEG it won't resize to 64x48, instead it shows the
play image in preview.

The 'imageBlob' is what is is sent out over the wire.

As a reminder we accept patches for improved functionality.

Waylon

···

On Mon, Sep 24, 2012 at 10:48 AM, wrote: > Thx for the answer. That is what i assumed. > > That means: > 1) When n-users access http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2%5B%40version%3Dnull+and+%40uiVersion%3Dnull%5D%2Fgeotagger%5B%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe%5D%2FImage&previewImage=true the original image has to be scaled n-times down on the serverside? 1 preview thumbnail request is one scaling down operation? > > 2) When accessing http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2%5B%40version%3Dnull+and+%40uiVersion%3Dnull%5D%2Fgeotagger%5B%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe%5D%2FImage&previewImage=true. The original image has 2MByte and preview has 2KByte in size. How many KBytes are now sent over the wire to the user? Because i understood, according to other posts, that the original 2MByte are sent over the wire and just when displaying the image it is scaled down to appear as a small preview thumbnail. > > greetings > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en

Mitch_S · September 24, 2012, 7:58pm

No. The scaling happens on the server (this is what the previewImage=true
parameter specifies). And it happens with each request to the server.
So...

(1) there will be n requests to the server, one from each user. Each
request is treated independently, so the server will perform the work of
retrieving and scaling down the image n times. After that, if the user's
browser is respecting the cache directives, the scaled-down images will be
cached within the browser and not re-requested for the next 60 minutes.

(2) The data sent over the wire is the size of the thumbnail image (2KB).

The cache directives were added in 1.2.0 (the version is shown on the Site
Admin / Preferences page).

Mitch

···

On Mon, Sep 24, 2012 at 10:48 AM, wrote:

Thx for the answer. That is what i assumed.

That means:

When n-users access
http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2[%40version%3Dnull+and+%40uiVersion%3Dnull]%2Fgeotagger[%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe]%2FImage&previewImage=truethe original image has to be scaled n-times down on the serverside? 1
preview thumbnail request is one scaling down operation?

When accessing
http://opendatakit.appspot.com/view/binaryData?blobKey=geo_tagger_v2[%40version%3Dnull+and+%40uiVersion%3Dnull]%2Fgeotagger[%40key%3Duuid%3Af6454ba6-2485-426f-8e1a-8981e463e6fe]%2FImage&previewImage=true.
The original image has 2MByte and preview has 2KByte in size. How many
KBytes are now sent over the wire to the user? Because i understood,
according to other posts, that the original 2MByte are sent over the wire
and just when displaying the image it is scaled down to appear as a small
preview thumbnail.

greetings

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

W_Brunette · September 25, 2012, 3:11pm

The non-image data is loaded all together when the page renders then
separate smaller requests request to load the preview images. Each
image preview request is a separate request so it takes a while to
load them all. We wanted the user to be able to see data quickly at
the expense of waiting on images to load. Also as shown in the code
the scaling happens after the image is loaded from the datastore but
before its transmitted over the wire.

If you want to try and speed this up we do accept patches.

Waylon

···

On Tue, Sep 25, 2012 at 2:08 AM, wrote: > Thank you for your answers. > > I tested yesterday with a small application the situation: > > //this one is the original image > Height:1944, Width : 2592 > size in bytes: 1067058 > millisec:94262 > > //this is preview=true > Height:47, Width : 63 > size in bytes: 1800 > millisec:102746 > > That means if you specifically request the preview thumbnail image in some app, you get also the small thumbnail. > > But i still have the problem, that when accessing the somepath/ODKAggregate/Aggregate.html#submissions/filter/// adminsite > where i have on the first page like 50 images, that it takes AGES to display the small thumbnail images. > > I see immediately all other fields and data, but the FIELD PICTURE is displaying every 3-5 seconds a new thumbnail image. 10 preview thumbnails can take more than 30 sec to be displayed. > Maybe the scaling down is taking so long? > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en

Mitch_S · October 4, 2012, 9:29pm

If you are using ODK Aggregate 1.2, your colleague should only experience
the delay on first load of the page; once the images are loaded, they
should be cached on the browser.

As you note, the difficulty is determining what the proper pre-computed
thumbnail size should be. This all adds complexity to the code, especially
if you then decide to change that image size, or want different thumbnails
for different forms, etc.

Interestingly, Amazon originally precomputed and cached thumbnails for all
of its product images (and eventually several differently-sized images...).
They eventually changed their architecture to always dynamically resize
images and rely on the browser cache in order to simplify and improve the
performance of their systems.

I suspect the access time is slow because of the "spinning up" of
additional ODK Aggregate servers to handle the influx of the 100 image
access requests on the page (these get queued and executed a few (5?) at a
time). After about 40 seconds, there should be enough additional copies of
your ODK Aggregate server running that image rendering speeds should drop
considerably.

Mitch

···

On Tue, Sep 25, 2012 at 8:40 AM, wrote:

I have not coded in java for a long time and the problem i am describing
here is just a problem of a collegue ^^.

I just wanted to point out what might be improved. Give feedback.

What do you think about the following idea:

create a field with the name "thumbnail"

when uploading data with image, take in the same process the original
image, scale it down, create a new preview_thumbnail.jpg and save that new
image in the field "thumbnail". The original image can be saved in another
field or whereever.

optinal but cool: allow the user to specify on the server the size of
the thumbnails (height and width). Maybe someone has an app where he/she
wants to display the preview_thumbnail.jpg with size 100x100.

When a user access the admin page only the saved preview_thumbnail.jpg
should be displayed. A doubleclick on that preview image should load the
original image.

I assume there are apps which want to display like ONLY all
preview_thumbnails and when the user picks one/doubleclicks it, the
original image should be displayed.

greetings

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com