Status Update
Comments
as...@google.com <as...@google.com> #2
Does this reproduce in 1.3.7 or is it a regression in 1.4.0-alpha01?
gr...@gmail.com <gr...@gmail.com> #3
I saw that the 1.4.0 alpha included a fix regarding corrupted webp images and hoped that it would work. Seems a little different issue though.
So it is not a regression, it is both reproducible in the prod and alpha version.
bu...@gmail.com <bu...@gmail.com> #4
Thanks - it looks like the original image has no Exif data, so something is going wrong with the way ExifInterface
is adding Exif data. We have
sc...@gmail.com <sc...@gmail.com> #5
Dropping 001.webp
into the existing testWebpWithoutExif()
test causes it to fail, so there's definitely something different about this file.
I took a look at 001.webp
in a hex editor and noticed that its declared file length (from the RIFF
header) is 0xD4C00100
, which (because it's little endian) is 114900 in decimal. This should be the length of the file from offset 8 (i.e. file should be 8 bytes longer than this) - but the file is actually 12 bytes longer than this (114912) with 4 trailing 0x04
bytes on the end.
Removing these trailing bytes and re-running the test causes it to pass.
Inspecting 001_corrupt.webp
I can see the trailing 0x04
bytes at the end.
So what happens when we write out a WebP file is:
- We add the
RIFF
header and placeholder for the file length - We synthesise a VP8X header.
- We copy the existing VP8 chunk
- Append the new Exif chunk
- Copy the rest of the file (the 4 trailing
0x04
bytes). - Go back to the beginning and fill in the file length based on how much data we wrote in steps 2, 3, 4 & 5.
- This ends up including the trailing
0x04
bytes in the RIFF length, but they're not a valid chunk - so the file ends up being invalid.
- This ends up including the trailing
The issue comes from copying the whole of the input file, and assuming it should all be covered by the new RIFF header, instead of considering the RIFF length of the original file. I will send a change for review which only includes existing RIFF data and new Exif data in the new RIFF length, and then copies over any additional trailing data outside the RIFF structure.
jo...@gmail.com <jo...@gmail.com> #7
Project: platform/frameworks/support
Branch: androidx-main
Author: Ian Baker <
Link:
Exclude trailing non-WebP data from length when writing new file
Expand for full commit details
Exclude trailing non-WebP data from length when writing new file
Some files have trailing data outside the length defined by the RIFF
header. ExifInterface previously naively copied this data and then
calculated a new RIFF length which included it, resulting in an invalid
file.
This change only copies RIFF-defined data from the old file before
calculating the new RIFF length, and then appends any additional data
after that - in order to more closely mimic the input file's structure
without throwing away the trailing data.
Test: ExifInterfaceTest
Bug: 385766064
Change-Id: I8a955cf85d229ad4af5a1e02aa891cfca0e54d60
Files:
- M
exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
- A
exifinterface/exifinterface/src/androidTest/res/raw/webp_without_exif_trailing_data.webp
- M
exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
Hash: d21234605366120bb1af4ea1109e15b6c23d93f0
Date: Fri Jan 03 11:30:32 2025
ko...@gmail.com <ko...@gmail.com>
zi...@cloudware360.com.pe <zi...@cloudware360.com.pe> #8
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.exifinterface:exifinterface:1.4.0-beta01
he...@gmail.com <he...@gmail.com> #9
I also added a parameter to determine whether this has to be case sensitive of not: I added this paramater in calling sheet and pass it to the function via a parameter.
The first time i change the parameter everything works out fine, but when the same value (0 or 1) is used again the function isn't re-evaluated anymore. Even with different a different parameter value.
zi...@cloudware360.com.pe <zi...@cloudware360.com.pe> #10
This issue should be closed. Its also a dup of
ar...@trbls.com <ar...@trbls.com> #11
ba...@gmail.com <ba...@gmail.com> #12
[Deleted User] <[Deleted User]> #13
sc...@menta.com <sc...@menta.com> #14
br...@gmail.com <br...@gmail.com> #15
I created a function to do a complex switch statement. But Sheets cached the results of the parameters (which had errored out), and it is ignoring the updates that I've made to the function. So myFunc( 150, true) retains a cache result of an error yet any variation on that like myFunc(149, true) returns a valid result even though it follows the same code path.
The sheet is shared with another person who is actively using the file, which may be why reopening the file persists the incorrect cached values.
I've implemented the work around that Scott.Se mentioned above with the Named Ranges, which has fixed the results.
I would expect the behavior to be that when a function is saved (even if there are only cosmetic edits to spacing) that all cells that reference the function are re-evaluated.
ek...@google.com <ek...@google.com>
la...@gmail.com <la...@gmail.com> #16
bi...@gmail.com <bi...@gmail.com> #17
Any updates on this? Or at least a workaround besides the one provided by Scott. Something like using flush in the code or some thing.
Thank you.
ch...@flyweight.io <ch...@flyweight.io> #18
jr...@redhat.com <jr...@redhat.com> #19
There is any update on this? This is impacting my code... I need updated data from Spreadsheet
ma...@testijad.ee <ma...@testijad.ee> #20
jo...@orpinel.com <jo...@orpinel.com> #21
How come the GOOGLEFINANCE
function does update periodically without changing any params? That's what I want from my custom functions, just expire the cache every minute or allow me to configure that somehow.
That said, an obvious workaround is to receive a dummy param in your fn and send it a random number from some cell that your script updates periodically.
Description
1. Define a custom function that uses data passed in from the parameters, as well as data from some other source (such as global configuration data living on a different sheet).
2. Use that function somewhere.
3. Change the data from the other source.
What is the expected output? What do you see instead?
I expect to see the custom function recalculated. If I change the contents of a cell referenced by the function, it is recalculated and displays the correct results. If I change the cell *back* to its original value, the *old* calculation is used, and is not recalculated.
On which browser & OS? Firefox 7.0.1 on Linux (Ubuntu 11.10).
Please provide any additional information below.
You can find an example spreadsheet here:
There are two issues here. Ideally, there should be a way to force a recalculation, since it's not possible to automatically determine programmatically whether a recalculation is necessary. However, if that's deemed unworkable, then at the very least, a change in a cell referred to by a function should unconditionally be recalculated, even if there's already a cached return value available.