Freshly exported jpeg crashes ASP3 (with possible solution)

[tony_redink2000]

Often, when I export/save a raw file to jpg, opening that directory with the newly exported file, with AfterShotPro3, causes it to crash when reading that file.

When I clear/delete the exif info from that file, AfterShotPro3 can operate without crashing.
This makes me think its the way that AftershotPro3 is exporting the images that is the problem here.

On some occasions I have removed all exif info from all the jpegs files in a directory as many files seem to make it crash.

This is the truncated logs from my console session and the exiftool command to clear the exif data and subsequent running of AftershotPro3 on the same file which did not crash the app.

./AfterShot3X64
...
dding master versions
Adding master versions
Scanning file "/home/tdelov/Pictures/testexport/DSC_2765.jpg"
Importing: "/home/tdelov/Pictures/testexport/DSC_2765.jpg"
TIFF Error: /home/tdelov/Pictures/testexport/DSC_2765.jpg "Not a TIFF file, bad magic number 55551 (0xd8ff)"
defaults: "DefaultRendered.xmp"
Segmentation fault


tdelov@xcrum:~/Pictures/testexport$ exiftool -all= DSC_2765.jpg
1 image files updated


tdelov@xcrum:~/Pictures/testexport$ AfterShot3X64
Install Path: /opt/AfterShot3(64-bit)
LD_PATH: /opt/AfterShot3(64-bit)/lib:
XLIB_SKIP_ARGB_VISUALS:
I have SSE2
....
Adding master versions
Scanning file "/home/tdelov/Pictures/testexport/DSC_2765.jpg"
Importing: "/home/tdelov/Pictures/testexport/DSC_2765.jpg"
TIFF Error: /home/tdelov/Pictures/testexport/DSC_2765.jpg "Not a TIFF file, bad magic number 55551 (0xd8ff)"
Loading EXIF failed
Scanning file "/home/tdelov/Pictures/testexport/DSC_3567.jpg"

[blueridge22]

I have this problem on linux and Aftershot 2 does not have it. As a mater of fact, Aftershot 3 pro cannot import jpegs it creates which I find puzzeling

I have new information

ran the program with gdb, and this is where it fails.

Gess Lens Goodness # 8
Gess Lens Goodness # 5
Gess Lens Goodness # 6
[New Thread 0x7fff8ffff700 (LWP 5886)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffaed4d700 (LWP 5881)]
0x00000000009a8778 in JpegCompressor::finish() ()
(gdb) bt
#0 0x00000000009a8778 in JpegCompressor::finish() ()
#1 0x0000000000943b6b in JpegReader::extractJpegThumb(char**, int*) ()
#2 0x000000000096ab8b in CameraReader::extractJpegThumb(char**, int*) ()
#3 0x0000000000583d2f in OriginalThumbAsset::runInline() ()
#4 0x0000000000569a76 in FolderImportAsset::addMastersVersions() ()
#5 0x000000000056e4cf in FolderImportAsset::run() ()
#6 0x000000000083771f in ThreadMangler::runTask(TmTask&, TMMangler&, TMMangler::ThreadData&, TMResource&, TMMangler::Private&, bool) [clone .isra.46] ()
#7 0x0000000000837e5d in TMThread::run() ()
#8 0x00007ffff1d17514 in ?? ()
from /opt/AfterShot3(64-bit)/lib/libQt5Core.so.5
#9 0x00007ffff1a5f184 in start_thread (arg=0x7fffaed4d700)
at pthread_create.c:312
#10 0x00007ffff0cdd37d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) exit


Chip

[urlisse]

This is a very critical bug, as it makes AfterShot Pro 3 practically unusable--at least with some images.

I tried stripping the EXIF metadata of my JPEG file, as tony suggested, but the segmentation fault persisted.

However, I found that rewriting the JPEG file using a common editor (Gimp, in this instance) would alter the file in such a way that AfterShot would accept it. In order to minimize the changes made to the original file, I applied the same strategy using a lossless optimizer, with success:

Code: Select all

# Warning: running this command will overwrite the original file
jpegtran -copy all -optimize -outfile file.jpg file.jpg

Although this technique requires manual intervention for each file that crashes AfterShot, it may provide a temporary fix until Corel addresses the issue. Just run AfterShot Pro from the command line (`AfterShot3X64` for me), backup the last image file listed before the crash and apply the above command to the original file.

While I have little clue about the "entropy recoding" that happens while optimizing a JPEG file, I did notice a that a few alterations were made to the metadata: the ISO, Exposure Time, Shutter Speed and Light Value to have been slightly tempered with.

Under Ubuntu/Debian, the jpegtran tool can be installed using `sudo apt-get install libjpeg-progs`. Other alternatives exist (mozjpeg, jpegrescan, jpegoptim, ...) but I haven't tried any of them.

I hope this can shed some light on the underlying issue. I can provide a sample troublesome image to the dev team if required.

[hannes_hab]

Thank you for that hint!
But this only works sometimes (as with "neat image" - filtering and saving with neat image sometimes works - sometimes not).
What always worked (so far ...) for me: opening and saving with gimp.