…When Aspect is launched the Photo Stream shows some blank (black) photos. The photos are present in the file browser.
Software: aspect
Software version: 1.0.0-preview.41
Operating system: linux, MX Linux 23.4 KDE, 64bit,
Kernel: 6.1.0-17-amd64 x86_64
Hardware Information: …
CPU: 8-core 11th Gen Intel Core i7-11700K (
Mem: (Aspect using 3.2GiB - 8299.9/31889.9 MiB (26.0%)
Storage: 17.28 TiB (31.9% used)
To rule out that this is an effect of an already fixed issue, or possibly a side-effect of a previous crash, can you try to select the black images within the library and invoke Image → Renew cached data from the menu bar? Based on the fact that they do display correctly in the file browser (which uses a separate thumbnail cache) these sound like the two most likely explanations.
I followed your instructions and nothing happened. The image is still blank. I tried a few others and noticed that in Aspect the EXIF data is missing, while it is visible in the file manager. I have only found about 8 photos like this out of about 3726. But I did notice that there are about 36 mp4 files that are blank. They are also visible in the file browser and play properly. I noticed this when I sorted the photos by camera, they all show up as Unknown camera.
Cheers,
Gord
Okay, to maybe get an idea of where this goes wrong without having access to the image, can you get the following information from one of the files:
If you have Gimp installed, simply choosing Image → Image Properties from the menu should display most of these, so a screenshot of that dialog would probably be the simplest way to get them.
I have done as you asked and am attaching screenshots. I got a little carried away and decided to compare the differences in the picture properties displayed by different software. I will attach those if the forum system allows it. As you will see GIMP did something I did not expect and I explored both basic options. I hope this helps.
I was only allowed to upload 5 files at a time and will attach the rest on a separate comment.
Follow up with more screenshots. There is one showing an invalid metadata error, I do not know if this is relevant.
By the way, I find the jExifToolGUI to be very useful.
Thanks for the info! The image itself really looks like a completely standard JPEG, except maybe for the 444 sub sampling, but that shouldn’t be an issue. The only obvious possibility remaining would be some metadata that trips up our parser, but at least the EXIF fields shown don’t look suspicious. Could you send an image to bugs@bildhuus.com or to me via direct message here? I can then have a detailed look at the loading process to see where exactly it goes wrong.
here is one showing an invalid metadata error, I do not know if this is relevant.
Missed that, but definitely possible!
I have resolved the problem for the photo I sent to you. Using the jExifToolGUI software’s Repair JPG’s with corrupted metadata tool. The software updated an exif field relating to the URI of Microsoft Photos. After that the Aspect properly read the image. I processed another image and according to jExifToolGUI it only updated the file, no error was reported as fixed. Aspect also updated this image and displayed it correctly. So I now believe that the images exif data was somehow corrupted or malformed.
Thanks for your time and help,
Gord
jExifToolGUI looks like a really useful tool and I’ll definitely use it in the future, thanks for mentioning it (I’ve usually been using PhotoME for inspecting metadata, but this has a few more features that may come in handy).
So I’ve looked at the image and what I’m getting is a “bogus Huffman table definition” error from libjpeg-turbo. I’m not sure which decoder library the other applications use, but it’s certainly possible that a different library is more forgiving w.r.t. malformed entries. For what it’s worth, I have found an unresolved bug report that would fit the issue: Bogus Huffman table definition: jpeg_make_d_derived_tbl too strict · Issue #586 · libjpeg-turbo/libjpeg-turbo · GitHub
For now though, the JPEG repair option looks like the only option, since libjpeg-turbo overall still is the best choice in our case and it seems, at least in the specific case of that bug report, like they don’t intend to make their checks more relaxed.
