what kind of raws are you trying to load?
have it ever worked?

1. Panasonic FZ50
2. Yes. Even the photos that worked are not displayed

please provide an image

For example http://www.rawsamples.ch/raws/panasonic/fz50/RAW_PANASONIC_FZ50_SRGB.RAW - which used to work.

% f-spot -v ~/Desktop/Downloads/RAW_PANASONIC_FZ50_SRGB.RAW
[Info  14:15:48.255] Initializing DBus
[Info  14:15:48.934] Initializing Mono.Addins
[Info  14:15:50.208] Starting new FSpot server
uri = file:///home/uzytkownik/Desktop/Downloads/RAW_PANASONIC_FZ50_SRGB.RAW
Found Unknown Tiff Marker 55

(f-spot:21266): Gtk-WARNING **: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
zsh: segmentation fault  f-spot -v ~/Desktop/Downloads/RAW_PANASONIC_FZ50_SRGB.RAW

Segfault was after clicking on 'close' button (the 'x' added by WM)

I'll try with 0.4.2.

(In reply to comment #4)
> I'll try with 0.4.2.

try svn instead, i have no problems in viewing that file!

Well. May be it is a problem with library. Do you have an idea which one it may be and/or how to check it.

Still present in 0.5.0.2. From the code it seems that the Gdk tries to load the RAW, which do not know how to handle.

What's your output of:
#include <gdk-pixbuf/gdk-pixbuf.h>
#include <glib.h>

int main(int argc, char **argv) {
	GSList *formats;

	gdk_init(&argc, &argv);

	formats = gdk_pixbuf_get_formats ();

	while (formats) {
		printf("%s\n", gdk_pixbuf_format_get_name(formats->data));
		formats = formats->next;
	}
}

Mine is:
wbmp
ras
bmp
xbm
ani
svg
jpeg
tga
xpm
icns
png
gif
tiff
pcx
pnm
jpeg2000
ico

I can confirm that f-spot works fine with .raw images. And f-spot only fallback to pixbuf loader if it fails at processing the raw file itself.

what's the result of this:
dcraw -i ~/Desktop/Downloads/RAW_PANASONIC_FZ50_SRGB.RAW

% dcraw -i ~/Desktop/Downloads/RAW_PANASONIC_FZ50_SRGB.RAW
/home/uzytkownik/Desktop/Downloads/RAW_PANASONIC_FZ50_SRGB.RAW is a Panasonic DMC-FZ50 image.

please run

f-spot --debug -v ~/Desktop/Downloads/RAW_PANASONIC_FZ50_SRGB.RAW

and report a complete stacktrace. 

% f-spot --debug -v ~/Desktop/Downloads/RAW_PANASONIC_FZ50_SRGB.RAW
** Running f-spot in Debug Mode **
** Running Mono with --debug   **
[Info  20:14:31.550] Initializing DBus
[Debug 20:14:32.541] DBusInitialization took 0.838319s
[Info  20:14:32.542] Initializing Mono.Addins
[Debug 20:14:34.496] Mono.Addins Initialization took 1.951682s
[Info  20:14:34.630] Starting new FSpot server
uri = file:///home/uzytkownik/Desktop/Downloads/RAW_PANASONIC_FZ50_SRGB.RAW

(f-spot:16442): Gtk-WARNING **: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
[Info  20:14:40.149] Hack for gnome-settings-daemon engaged
[Debug 20:14:44.170] Db Initialization took 3.818741s
[Info  20:14:55.646] Exiting
[Debug 20:14:55.845] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.846] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.846] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.847] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.863] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.863] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.864] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.928] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.929] Finalizer called on FSpot.Tag. Should be Disposed
[Debug 20:14:55.929] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.929] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.930] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.930] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.933] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.934] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.934] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.934] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.934] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.935] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.935] Finalizer called on FSpot.Category. Should be Disposed
[Debug 20:14:55.936] Finalizer called on FSpot.Category. Should be Disposed
zsh: segmentation fault  f-spot --debug -v ~/Desktop/Downloads/RAW_PANASONIC_FZ50_SRGB.RAW

as I can see in the previous message, f-spot is displaying your image nicely. or at least it does not fails PixbufLoader as you reported

could you provide a real stack of a real crash ?

(In reply to comment #12)
> as I can see in the previous message, f-spot is displaying your image nicely.
> or at least it does not fails PixbufLoader as you reported
> 

Well. If the image is the red cross then yes - it is displaying nicely.

> could you provide a real stack of a real crash ?
> 

In a moment. I currently tring to solve problems with mono (upgrading 1.9->2.0)

Only what I get is exceptions:
GLib.GException: Unrecognised image file format
  at Gdk.PixbufLoader.Write (System.Byte[] buf, UInt64 count) [0x00000] 
  at PixbufUtils+AspectLoader.Load (System.IO.Stream stream, PixbufOrientation orientation) [0x00000] 
  at FSpot.ImageFile.Load (Int32 max_width, Int32 max_height) [0x00000] 
  at PixbufLoader.ProcessRequest (.RequestItem request) [0x00000] 
GLib.GException: Unrecognised image file format

I have mono-debugger so if you say where produce stacktraces I can provide them.

Could at lease someone point the place in code when the different backend are tried? All I found is loading via GDK.

Created attachment 123912 [details] [review]
Patch making f-spot producing tiff files instead of ppm

I found out what the problem is.

DCRaw with options given produces a 'Netpbm PPM "rawbits" image data' which is not recognised by my gdk.

% dcraw -h -w -c -t 0 /tmp/RAW_PANASONIC_FZ50_SRGB.RAW > /tmp/test.img
% file /tmp/test.img
/tmp/test.img: Netpbm PPM "rawbits" image data
% python
Python 2.6 (r26:66714, Nov 18 2008, 01:24:15) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk.gdk
>>> pixbuf = gtk.gdk.pixbuf_new_from_file("/tmp/test.img")
Traceback (most recent call last):

+ Trace 210461

>>> 

However if the Tiff image is produced all is OK.
% dcraw -h -w -c -t 0 -T /tmp/RAW_PANASONIC_FZ50_SRGB.RAW > /tmp/test.img
% file /tmp/test.img
/tmp/test.img: TIFF image data, little-endian
% python  
Python 2.6 (r26:66714, Nov 18 2008, 01:24:15) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk.gdk
>>> pixbuf = gtk.gdk.pixbuf_new_from_file("/tmp/test.img")
>>> 

Since many people claim that the ppm is working for them I will invastigate it. Possibly a gdk bug.

I attach quick'n'dirty patch solving this issue.

you should have a file called gdk_pixbuf.laoders somewhere. can you paste it here ?

could you also compile this code snippet and paste the result:

using Gdk;

public class Test {
static void Main () {
    foreach (PixbufFormat format in Pixbuf.Formats)
        Console.WriteLine (format.Name);
}
}

compile it with gmcs -pkg:gtk-sharp-2.0

those 2 results will help me figure if it's possible to, at runtime, detect the supported ppm format and fallback to something else.

The results are the same (line in line) as in Comment #7.

I have no such file.
# locate gdk_pixbuf
/usr/lib/libgdk_pixbuf-2.0.la
/usr/lib/xine/plugins/1.24/xineplug_decode_gdk_pixbuf.so
/usr/lib/libgdk_pixbuf_xlib-2.0.so.0.1400.5
/usr/lib/libgdk_pixbuf_xlib-2.0.so
/usr/lib/libgdk_pixbuf-2.0.so.0.1400.5
/usr/lib/libgdk_pixbuf-2.0.so
/usr/lib/libgdk_pixbuf_xlib-2.0.la
/usr/lib/libgdk_pixbuf-2.0.so.0
/usr/lib/libgdk_pixbuf_xlib-2.0.so.0
/usr/lib/debug/usr/lib/xine/plugins/1.24/xineplug_decode_gdk_pixbuf.so.debug
/usr/lib/debug/usr/lib/libgdk_pixbuf_xlib-2.0.so.0.1400.5.debug
/usr/lib/debug/usr/lib/libgdk_pixbuf-2.0.so.0.1400.5.debug

here's mine:

Pixbuf.Formats.Select (x => x.Name);
{ "ani", "svg", "pnm", "ico", "png", "ras", "wbmp", "tga", "tiff", "jpeg2000", "gif", "wmf", "xpm", "xbm", "bmp", "pcx", "icns", "jpeg" }

I've experienced exactly the same issue, and found the explanation in bug #569671.  In short, gdk_pixbuf no more uses its own signature thing for guessing file types, but relies on GIO.  And GIO relies on shared-mime-info, which doesn't think the PNM files signature ("P[0-6]" at the beginning of files) is long enough to be reliable ( http://bugs.freedesktop.org/show_bug.cgi?id=19811 ).  So the "fix" that was adopted for bug #569671 is a fallback on guessing from the filename.  But, sure, in the case we have here it won't help.

As a workaround, i have recompiled my GTK+ so that gdk_pixbuf loaders works the old way (undef GDK_PIXBUF_USE_GIO_MIME), and f-spot now works fine again with raw files.  But i don't know what the right fix would be:
  - Make freedesktop people change their mind about PNM signatures?  On the other hand, i understand their point about 2 chars not being enough...
  - Make GTK+ people find a better workaround?  Maybe a fallback on their own old signatures thing?
  - Change dcraw options in f-spot, as proposed by Macieij?  I confirm that TIFF detection happens to work both with or without GDK_PIXBUF_USE_GIO_MIME, so it should be safe.  Only drawback i can think of is that TIFF support in GTK+/gdk_pixbuf is optionnal, with a dependency on an other lib, whereas PNM was builtin.  Might have an impact for f-spot packagers.

Well other solutions would be:
 - Save the output to temporary file.But IMHO it's terrible sollution
 - if tiff_supported
   then use_tiff
   else try use_pnm
        catch display_error

This should be fixed by my branch (bug 590150).

Greate - but why change back the description? If it is coused by method of reading PNM by GDK previous  description was better (greater chances of avoiding duplicates and it was not panasonic-specific).

Sorry, fixed that

Comment on attachment 123912 [details] [review]
Patch making f-spot producing tiff files instead of ppm

Maintenance update: In the past we've been less than stellar in reviewing patches. As such we have a pile of patches in bugzilla which are outdated and don't apply anymore. Am currently marking all of these as "needs-work". My apologies for this.

Since I've become a maintainer of the project, I've set the personal rule of quickly reviewing all patches, to avoid that this happens again. If you (or anyone) wants to go through the trouble of updating this patch, please talk to us to figure out if it fits in the F-Spot long term roadmap.

Should you, in the future, notice a patch lingering around for too long, please notify us immediately and we'll look into it, to avoid situations like these from happening again.

You can filter these mails by searching for ###F-OLDPATCHCLEANUP###

f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010.
Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.