Bug 30006

Summary:	Implement PEF *-ist DS decompression
Product:	libopenraw	Reporter:	Christian Krause <chkr>
Component:	General	Assignee:	Hubert Figuiere <hub>
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Christian Krause 2010-09-03 15:53:38 UTC

There are a couple of bug reports in Fedora about crashes of gthumb when opening raw images. They all share a backtrace pointing to libopenraw (see below). I can reproduce these problems by just using "libopenraw-0.0.8/demo/pixbufload".

An image which causes this problem is attached to the following bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=606898

Here is the most interesting part of the backtrace:

Thread 1 (Thread 4435):
#0  __copy_m<uint16_t*, float*> (src=<value optimized out>, 
    src_x=<value optimized out>, src_y=<value optimized out>, 
    pattern=<value optimized out>, dst=<value optimized out>)
    at /usr/include/c++/4.4.2/bits/stl_algobase.h:343
        __n = 1237763
#1  __copy_move_a<false, uint16_t*, float*> (src=<value optimized out>, 
    src_x=<value optimized out>, src_y=<value optimized out>, 
    pattern=<value optimized out>, dst=<value optimized out>)
    at /usr/include/c++/4.4.2/bits/stl_algobase.h:397
No locals.
#2  __copy_move_a2<false, uint16_t*, float*> (src=<value optimized out>, 
    src_x=<value optimized out>, src_y=<value optimized out>, 
    pattern=<value optimized out>, dst=<value optimized out>)
    at /usr/include/c++/4.4.2/bits/stl_algobase.h:436
No locals.
#3  copy<uint16_t*, float*> (src=<value optimized out>, 
    src_x=<value optimized out>, src_y=<value optimized out>, 
    pattern=<value optimized out>, dst=<value optimized out>)
    at /usr/include/c++/4.4.2/bits/stl_algobase.h:468
No locals.
#4  bimedian_demosaic (src=<value optimized out>, 
    src_x=<value optimized out>, src_y=<value optimized out>, 
    pattern=<value optimized out>, dst=<value optimized out>)
    at bimedian_demosaic.cpp:113
        y = <value optimized out>
        doffset = <value optimized out>
        dst_buf = <value optimized out>
        npattern = <value optimized out>
        x = <value optimized out>
        offset = <value optimized out>
#5  0x00f28332 in OpenRaw::RawFile::getRenderedImage (
    this=<value optimized out>, bitmapdata=<value optimized out>, 
    options=<value optimized out>) at rawfile.cpp:403
        y = <value optimized out>
        dst = 0xae197008 ""
        x = <value optimized out>
        pattern = <value optimized out>
        src = <value optimized out>
        rawdata = {<OpenRaw::BitmapData> = {_vptr.BitmapData = 0xf748f0, d = 
    0xb1604170}, d = 0xb1626688}
        ret = OR_ERROR_NONE
#6  0x00f52ad5 in or_rawfile_get_rendered_image (
    rawfile=<value optimized out>, bitmapdata=<value optimized out>, 
    options=<value optimized out>) at rawfile.cpp:104
        prawfile = <value optimized out>
#7  0x0062ee69 in openraw_get_pixbuf_from_file (file_data=
    0xb16332b0 [GthFileData], requested_size=-1, error=0xb23831bc)
    at main.c:160
        bitmapdata = 0xb1632378
        err = <value optimized out>
        pixbuf = 0x0
        filename = 0xb163bb18 "/media/6262-3062/DCIM/100PENTX/IMGP3018.PEF"
        raw_file = <value optimized out>
#8  openraw_pixbuf_animation_new_from_file (file_data=
    0xb16332b0 [GthFileData], requested_size=-1, error=0xb23831bc)
    at main.c:196
        animation = <value optimized out>
        pixbuf = <value optimized out>
#9  0x080a4f86 in load_image_thread (thread_data=0x8c82f28)
    at gth-image-loader.c:234
        loader = <value optimized out>
        file = 0xb16332b0 [GthFileData]
        exit_thread = <value optimized out>
        animation = 0x0
        error = 0x0

Comment 1 Hubert Figuiere 2010-09-03 17:47:47 UTC

This is a dupe of bug 26618 that has already been fixed in git master.

*** This bug has been marked as a duplicate of bug 26618 ***

Comment 2 Christian Krause 2010-09-04 01:54:26 UTC

(In reply to comment #1)
> This is a dupe of bug 26618 that has already been fixed in git master.

Ok great!

Please can you point me to the specific commit which fixed this issue? 

When do you plan to create a new release of libopenraw?

Comment 3 Christian Krause 2010-09-04 05:23:21 UTC

I have tested git HEAD of today (2010-09-04) and the problem is not fully fixed with the mentioned picture:

https://bugzilla.redhat.com/attachment.cgi?id=442984

- gthumb does not crash anymore, but the picture isn't displayed anyway
- a test with libopenraw's pixbufload fails with the error:
"wrong data type error" (details see below)

(Please note that I had to revert the commit 252cd9b20d7857091c0529955998b86d7a90e6c5 since it broke the compatibility with gtk2 2.20.* or 2.18.* - I'll open another bug report for this.)

./ccfa /tmp/imgp1451.pef 
data size = 9229440
data type = 6

./cfa /tmp/imgp1451.pef 
factory size 9
getRawData()
_locateDirs()
push offset =0x8
numEntries =19 shifting 230bytes
push offset =0x65536
numEntries =6 shifting 74bytes
push offset =0x9303168
numEntries =6 shifting 74bytes
# dir found = 3
IFDDir::load() m_offset =8
counting tiles
RAW Compression is 32773
_getCfaPattern
IFDDir::load() m_offset =8
Exif IFD offset (uncorrected) = 342
Exif IFD offset = 342
IFDDir::load() m_offset =342
_getCfaPattern
patter is = 0, 1, 1, 2
allocate s=9229440 data =0
 data =0xb6ee5008
data size = 9229440
data type = 6

./thumbc /tmp/imgp1451.pef 
registering type 1
registering type 3
registering type 5
registering type 7
registering type 6
registering type 8
registering type 2
registering type 9
registering type 4
factory size 9
requested size 160
_enumThumbnailSizes init
_enumThumbnailSizes()
_locateDirs()
push offset =0x8
numEntries =19 shifting 230bytes
push offset =0x65536
numEntries =6 shifting 74bytes
push offset =0x9303168
numEntries =6 shifting 74bytes
# dir found = 3
num of dirs 3
IFDDir::load() m_offset =8
_locateThumbnail
subtype 0
IFDDir::load() m_offset =8
IFDDir::load() m_offset =65536
_locateThumbnail
subtype 0
assume photometric int is RGB
looking for JPEG at 65630
JPEG dimensions x=160 y=120
Found 160 pixels
IFDDir::load() m_offset =9303168
_locateThumbnail
subtype 0
assume photometric int is RGB
looking for JPEG at 9303262
JPEG dimensions x=3008 y=2000
Found 3008 pixels
_enumThumbnailSizes failed
current iter is 160
size 160 found
allocate s=5974 data =0
 data =0x9504338
Thumbnail in JPEG format, thumb size is 160, 120
short write
output 5974 bytes in 'thumb.jpg'

./pixbufload /tmp/imgp1451.pef 
registering type 1
registering type 3
registering type 5
registering type 7
registering type 6
registering type 8
registering type 2
registering type 9
registering type 4
factory size 9
options are 0
getRawData()
_locateDirs()
push offset =0x8
numEntries =19 shifting 230bytes
push offset =0x65536
numEntries =6 shifting 74bytes
push offset =0x9303168
numEntries =6 shifting 74bytes
# dir found = 3
IFDDir::load() m_offset =8
counting tiles
RAW Compression is 32773
_getCfaPattern
IFDDir::load() m_offset =8
Exif IFD offset (uncorrected) = 342
Exif IFD offset = 342
IFDDir::load() m_offset =342
_getCfaPattern
patter is = 0, 1, 1, 2
allocate s=9229440 data =0
 data =0xb6e1b008
wrong data type
error

Comment 4 Hubert Figuiere 2010-09-04 19:47:56 UTC

These files are not supported yet.

Comment 5 GitLab Migration User 2018-08-20 21:24:08 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/libopenraw/libopenraw/issues/2.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.