From benjamin.kopic@panContext.com Mon Nov 10 09:24:09 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mta05.btfusion.com (mta05.btfusion.com [62.172.195.14]) by mail.gnome.org (Postfix) with ESMTP id C48A8181AB for ; Mon, 10 Nov 2003 09:24:08 -0500 (EST) Received: from [213.123.217.51] (helo=smee.pancontext.com) by mta05.btfusion.com with esmtp (Exim 4.24) id 1AJCxa-0003qa-RD for eog-list@gnome.org; Mon, 10 Nov 2003 14:24:07 +0000 Subject: "Unrecognized image file format" error when loading JPG file From: Benjamin Kopic To: eog-list@gnome.org Content-Type: multipart/alternative; boundary="=-59Cxtk8HcDNZEifFUZAC" Organization: panContext Message-Id: <1068473871.12408.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 14:17:52 +0000 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: --=-59Cxtk8HcDNZEifFUZAC Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, I am using Gnome 2.4 and keep getting the following error when trying to load any JPG file: Loading failed Loading of image BigBrother.jpg failed. Reason: Unrecognized image file format. However, I am able to load it using 'xloadimage' or analyse the files using 'jpeginfo' utility: benko@smee benko $ jpeginfo download/BigBrother.jpg download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) and then open it without any problem in 'eog'. The problem is only with JPG (JPEG) files, and I have not noticed any issues with other file types. I tried running 'eog' in a verbose/debug mode but could not found an option for it. Annoyingly, this used to work (in my Gnome 2.2), which stopped working when I updated one of my applications (not sure which one). I suspect it has something to do with MIME types or something, but I cannot find out what. As a result the problem is in all Gnome applications that display JPG files (except mozilla and epiphany). Any help is really appreciated. BTW, I am a Linux novice, so please bare that in mind when responding. Best regards, -- benjamin kopic m: +44 (0)780 154 7643 t: +44 (0)20 7794 3090 e: benjamin.kopic@panContext.com w: http://www.panContext.com/ --=-59Cxtk8HcDNZEifFUZAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I am using Gnome 2.4 and keep getting the following error when trying to load any JPG file:

Loading failed
Loading of image BigBrother.jpg failed.
Reason: Unrecognized image file format.

However, I am able to load it using 'xloadimage' or analyse the files using 'jpeginfo' utility:

benko@smee benko $ jpeginfo download/BigBrother.jpg
download/BigBrother.jpg  600 x 554  24bit JFIF  N   97033

Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) and then open it without any problem in 'eog'.

The problem is only with JPG (JPEG) files, and I have not noticed any issues with other file types. I tried running 'eog' in a verbose/debug mode but could not found an option for it.

Annoyingly, this used to work (in my Gnome 2.2), which stopped working when I updated one of my applications (not sure which one). I suspect it has something to do with MIME types or something, but I cannot find out what. As a result the problem is in all Gnome applications that display JPG files (except mozilla and epiphany).

Any help is really appreciated. BTW, I am a Linux novice, so please bare that in mind when responding.

Best regards,
-- 
benjamin kopic
m: +44 (0)780 154 7643
t: +44 (0)20 7794 3090
e: benjamin.kopic@panContext.com
w: http://www.panContext.com/
--=-59Cxtk8HcDNZEifFUZAC-- From jens@triq.net Mon Nov 10 13:21:56 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mail1.ewetel.de (mail1-106.ewetel.de [212.6.122.106]) by mail.gnome.org (Postfix) with ESMTP id 08CD918CB4 for ; Mon, 10 Nov 2003 13:21:56 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-67-160.ewetel.net [80.228.67.160]) by mail1.ewetel.de (8.12.1/8.12.9) with ESMTP id hAAILOIx005632; Mon, 10 Nov 2003 19:21:24 +0100 (MET) Date: Mon, 10 Nov 2003 19:26:54 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: Bryan W Clark Cc: eog-list@gnome.org Subject: Eog collection suggestions [was Re: [PATCH] EOG Collection] In-Reply-To: <1067569190.22999.71.camel@localhost> Message-ID: References: <1067376656.4775.162.camel@localhost> <3F9FB5D3.2010003@triq.net> <1067569190.22999.71.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hi Bryan, sorry for the delay in my reply (have been busy and then forgot about your mail :/) On Thu, 30 Oct 2003, Bryan W Clark wrote: > IMHO the idea of the collection viewer is to provide a filmstrip / > slideshow for the user. I think that in order to design for the > filmstrip model we can't providing a quick overview of all images at the > same time; the two design paradigms are mutually exclusive in our > current view. Actually I don't see a big problem here. Maybe we can change the behavior for the collection view to filmstrip mode, if it is used as nautilus view. > [...] > > > - With each saving of a jpeg the quality is reduced (lossy format). This > > can be avoided if libjpeg is used for lossless transformation of local > > jpeg files (which is planned). > > Ok, I wasn't aware of that. I'm sure you're almost all the way through > it, you've been making great progress so far. Once libjpeg is > incorporated I think an auto-save would _then_ be a good feature to > add. Hopefully we can work together on a good way to implement it. I don't have a clue how to integrate the libjpeg functionality into eog nicely yet. There is libeog/eog-image-jpeg.[ch] already, which provides the jpeg saveing functions only at the moment. This is probably the best place to add more jpeg specific image functions. > > - A nice thing in EoG is that you can rotate a large bunch of images in > > one run, while only the thumbnail representations are rotated. This is > > extremly fast and you get a quick overview if your transformation was > > right (eg. I always get horizontal/vertical flipping wrong). If an image is > - You can undo transformations, without touching the files again. > > I think this is a cool feature, but I wasn't aware of it until I dove > into the code. Yes, the documentation has definitely a lot room for improvements. Although there were some updates recently, haven't look at them yet. > jbut for this feature the usage group of people probably represent a > significantly small percent of the population of all our users. But I am in this 'small' group, so the feature will stay :). Maybe there is a way to make it more user visible, beside a better documentation. > Download new photos off their digital camera into directory "my trip" > Open up nautilus and navigate to "my trip" directory Now switch to > collection view so that they can show off the pictures from their trip > to everyone else, narrating each shot as it is in the preview window. > If they come across an image that is shot at a different rotation than > the others they would like to rotate it during their "mini-slideshow" > and not have to rotate it again when they leave the directory and open > it up again to show their pictures to someone else. Your use-case description makes sense. Though the argument of 'don't overwrite user-data silently' is a strong one. And eog shouldn't ask the user for each image seperately. Therefore I prefer the 'ask user to save modified images on exit' method. BTW: Eog remembers the transformation state during a session. If you load an image, rotate it, load another one and than later the first one again, eog will rotate it for you automatically. > To throw out an idea to solve the "rotated it the wrong way" situation, > we could try to implement a high feedback rotation system, similar to > what the new GIMP does does for image rotation. Yes, but than you don't have a stateless user interface anymore, which sucks IMO for a 'simple' image viewer. > I agree this is a problem, I'm on the GUP team and am working out a spec > to try to solve this right now. Do you have a link for more infos? Never heard of GUP team. > > - Eog can save only 'png' and 'jpeg' files. If you rotate eg. a gif file > > the automatic save will fail. > > I think this is a problem with the EOG save in general and not so much > with the auto-save idea, I'm sure we can fix this one as well with a > little hacking. Than, go ahead and add saving functionality for all kind of image types to gdk-pixbuf (where it belongs). Eog whill pickup these automatically. > > My idea for a better usability on this for 2.6 is: > > - Visually indicate that an image was modified > > - Select all modified images with one menu function > > - Ask the user on close if he want's to save the modifications if there > > are any. > > Take a look at the "rotate mode" idea or maybe you can elaborate a > little more on how this will work visually, as I can't see it. IMO this is pretty clear, what don't you understand here? > On close EOG asks the users "You've changed 'pict1454.jpg', do you want > to save?" And then again for every image other image that was rotated. > I couldn't identify any of the names my camera gives my images and I > don't rename them since I have too many to do that. I _can_ remember > which one I want to rotate when I'm looking at it and see that it's > wrong. Well, we can do it better. We have the thumbnails for all the images we are showing. So we can show the user the files which changed. Regards, Jens From jens@triq.net Mon Nov 10 13:38:53 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mail1.ewetel.de (mail1-106.ewetel.de [212.6.122.106]) by mail.gnome.org (Postfix) with ESMTP id AA01318184 for ; Mon, 10 Nov 2003 13:38:52 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-67-160.ewetel.net [80.228.67.160]) by mail1.ewetel.de (8.12.1/8.12.9) with ESMTP id hAAIcoIx013298; Mon, 10 Nov 2003 19:38:51 +0100 (MET) Date: Mon, 10 Nov 2003 19:44:20 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: Benjamin Kopic Cc: eog-list@gnome.org Subject: Re: "Unrecognized image file format" error when loading JPG file In-Reply-To: <1068473871.12408.24.camel@localhost> Message-ID: References: <1068473871.12408.24.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hi Benjamin, On Mon, 10 Nov 2003, Benjamin Kopic wrote: > I am using Gnome 2.4 and keep getting the following error when trying to > load any JPG file: > > Loading failed > Loading of image BigBrother.jpg failed. > Reason: Unrecognized image file format. > > However, I am able to load it using 'xloadimage' or analyse the files > using 'jpeginfo' utility: > > benko@smee benko $ jpeginfo download/BigBrother.jpg > download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 > > Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) > and then open it without any problem in 'eog'. > > The problem is only with JPG (JPEG) files, and I have not noticed any > issues with other file types. I tried running 'eog' in a verbose/debug > mode but could not found an option for it. > > Annoyingly, this used to work (in my Gnome 2.2), which stopped working > when I updated one of my applications (not sure which one). I suspect it > has something to do with MIME types or something, but I cannot find out > what. As a result the problem is in all Gnome applications that display > JPG files (except mozilla and epiphany). All Gnome programs use gdk-pixbuf as a graphic library for loading and saving image files. Since this happens in all Gnome programs for you (epiphany and mozilla both use other code for displaying images), it is very likely a bug in this basic library (which comes with GTK). Does it happen with all kind of jpeg files? This is a 24bit jpeg file, which may be the source of the problem. Anyway, could you attach a test file where it doesn't work to a bug in our bug tracking system at bugzilla.gnome.org? This would be very helpful. Thanks. Jens From clarkbw@clarkson.edu Mon Nov 10 17:34:26 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from bryan.clarkson.edu (bryan.sclab.clarkson.edu [128.153.144.201]) by mail.gnome.org (Postfix) with ESMTP id A3E9718F46 for ; Mon, 10 Nov 2003 17:34:26 -0500 (EST) Received: by bryan.clarkson.edu (Postfix, from userid 1000) id 2EEE538657F; Mon, 10 Nov 2003 17:34:24 -0500 (EST) Subject: Re: Eog collection suggestions [was Re: [PATCH] EOG Collection] From: Bryan W Clark To: eog-list@gnome.org In-Reply-To: References: <1067376656.4775.162.camel@localhost> <3F9FB5D3.2010003@triq.net> <1067569190.22999.71.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Clarkson Open Source Institute Message-Id: <1068503663.4368.190.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 17:34:24 -0500 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hey Jens ~ On Mon, 2003-11-10 at 13:26, Jens Finke wrote: > sorry for the delay in my reply (have been busy and then forgot about your > mail :/) no problem at all, thanks for taking the time to reply back to me. > On Thu, 30 Oct 2003, Bryan W Clark wrote: > > IMHO the idea of the collection viewer is to provide a filmstrip / > > slideshow for the user. I think that in order to design for the > > filmstrip model we can't providing a quick overview of all images at the > > same time; the two design paradigms are mutually exclusive in our > > current view. > > Actually I don't see a big problem here. Maybe we can change the > behavior for the collection view to filmstrip mode, if it is used as > nautilus view. Woah! I think you just turned everything I know upside down. All of my collection suggestions have been directed solely at the Nautilus view; I had no idea that you could open up directories in EOG by itself until a minute ago. That is really neat, but not the part I was after. :-) Consider everything I've suggested before and from here on to be only towards the Nautilus component _only_. I can see lots of value in keeping EOG feature rich and I would love to continue to help if you'd like; but my main concern was and is the Nautilus View component. > I don't have a clue how to integrate the libjpeg functionality into eog > nicely yet. There is libeog/eog-image-jpeg.[ch] already, which provides the > jpeg saveing functions only at the moment. This is probably the best place > to add more jpeg specific image functions. Hm, I don't know anything about this either. The best I can offer you is that I'll look and ask around for anyone with experience with this stuff so we could get it done right. > Yes, the documentation has definitely a lot room for improvements. > Although there were some updates recently, haven't look at them yet. It seems you have some great ideas towards making this piece easy to use without providing more docs for people to read. > But I am in this 'small' group, so the feature will stay :). Maybe there > is a way to make it more user visible, beside a better documentation. Totally agreed that this should stay. The user group who would take advantage of this are not to be trifle with :) Again, I think my only concern was for the Nautilus view; and if we make this the _only_ way to change images I can't figure a way to convey it to the user in an intuitive enough way that many people will take advantage of how cool this part really is. I'm at a brick wall of ideas to make this work so that people would just know what it's doing and how. My problem is that I'm stuck in this mental model for users [1] and maybe you can steer me to another one. The mental model that I see the user having is of a physical "photo album" or slide projector system. This is why I was thinking of the I change the rotation of the picture in the album/slides and it stays the way you last rotated it automatically (physical pictures tend to follow this property of Newtonian physics :). Without asking if you're sure afterwords. The one at a time viewing with knowing which picture is next comes from expanding the album idea as well. I'm interested in making the Nautilus View as simple as possible even if that means losing extra functionality (not that we rip the functions out, just that they aren't easy to get to from within nautilus). So if I'm way off on this, or you have a different user mental model I can stop crying about this. :) [...] > BTW: Eog remembers the transformation > state during a session. If you load an image, rotate it, load another one > and than later the first one again, eog will rotate it for you > automatically. Oh, cool stuff. I think I experienced the reset session after shutdown and open up again of EOG and so this didn't occur to me. > > To throw out an idea to solve the "rotated it the wrong way" situation, > > we could try to implement a high feedback rotation system, similar to > > what the new GIMP does does for image rotation. > > Yes, but than you don't have a stateless user interface anymore, which > sucks IMO for a 'simple' image viewer. Totally right, the idea is really overblown for the problem, just trying to throw out something new. > Do you have a link for more infos? Never heard of GUP team. Oh, GUP, I should have said the GNOME Usability Project, http://developer.gnome.org/projects/gup/ [....] > IMO this is pretty clear, what don't you understand here? I guess it just relates to the user mental model that I've constructed for this component. In the Nautilus view I think we're going to the least experienced people vs. the EOG view mode. In EOG what you are working towards feels like a file/photo manage type model which I don't think relates to people using the Nautilus view, but again this might not be the model you're working with and we're just missing something in the communication of these things. > Well, we can do it better. We have the thumbnails for all the images we > are showing. So we can show the user the files which changed. Definitely! Thanks for all your time, ~ Bryan [1] User Mental Models - Simply put is how users view what is actually being done vs. what is really going on behind the scenes. (example being, everyone knows how a T.V. works right? You turn it on and see shows, but no one wants to think about how the CRT actually draws on the screen, although things like the wonderfully outdated VHhold button had us scarily close to understanding the phase shifting that was going on. But T.V. designers have since dropped the VHHold button and other things because over time they knew that people just want to surf channels, not mess with the inner workings. ) -- Bryan W Clark Graduate Student Math && Computer Science Dept. Human Computer Interaction Group Clarkson University Potsdam, NY USA http://www.clarkson.edu/~clarkbw/ From benjamin.kopic@panContext.com Mon Nov 10 19:06:43 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mta03.btfusion.com (mta03.btfusion.com [62.172.195.12]) by mail.gnome.org (Postfix) with ESMTP id 0B20C18103 for ; Mon, 10 Nov 2003 19:06:43 -0500 (EST) Received: from [213.123.217.51] (helo=smee.pancontext.com) by mta03.btfusion.com with esmtp (Exim 4.24) id 1AJM3N-0004sE-EQ for eog-list@gnome.org; Tue, 11 Nov 2003 00:06:41 +0000 Subject: Re: "Unrecognized image file format" error when loading JPG file From: Benjamin Kopic To: eog-list@gnome.org In-Reply-To: References: <1068473871.12408.24.camel@localhost> Content-Type: multipart/alternative; boundary="=-F+jv7/Vb+ANyLJCgCgkr" Organization: panContext Message-Id: <1068509200.4702.28.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 11 Nov 2003 00:06:41 +0000 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: --=-F+jv7/Vb+ANyLJCgCgkr Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Jens I just noticed something when I opened "Open file..." dialogue. In "Determine File Type:" combo list I do not have JPG file format (my default option is "By Extension"). Could this have anything to do with this? Also, I tried finding any 16 bit JPG files on the net to try and see if I can open them, but I could not find any (if you have one, could you please e-mail it to me). In addition, I have submitted this to bugzilla.gnome.org: BUG#126672 http://bugzilla.gnome.org/show_bug.cgi?id=126672 Best regards Ben On Mon, 2003-11-10 at 18:44, Jens Finke wrote: > Hi Benjamin, > > On Mon, 10 Nov 2003, Benjamin Kopic wrote: > > I am using Gnome 2.4 and keep getting the following error when trying to > > load any JPG file: > > > > Loading failed > > Loading of image BigBrother.jpg failed. > > Reason: Unrecognized image file format. > > > > However, I am able to load it using 'xloadimage' or analyse the files > > using 'jpeginfo' utility: > > > > benko@smee benko $ jpeginfo download/BigBrother.jpg > > download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 > > > > Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) > > and then open it without any problem in 'eog'. > > > > The problem is only with JPG (JPEG) files, and I have not noticed any > > issues with other file types. I tried running 'eog' in a verbose/debug > > mode but could not found an option for it. > > > > Annoyingly, this used to work (in my Gnome 2.2), which stopped working > > when I updated one of my applications (not sure which one). I suspect it > > has something to do with MIME types or something, but I cannot find out > > what. As a result the problem is in all Gnome applications that display > > JPG files (except mozilla and epiphany). > > All Gnome programs use gdk-pixbuf as a graphic library for loading and > saving image files. Since this happens in all Gnome programs for you > (epiphany and mozilla both use other code for displaying images), it is > very likely a bug in this basic library (which comes with GTK). > > Does it happen with all kind of jpeg files? This is a 24bit jpeg file, > which may be the source of the problem. Anyway, could you attach a test > file where it doesn't work to a bug in our bug tracking system at > bugzilla.gnome.org? This would be very helpful. Thanks. > > > Jens -- benjamin kopic m: +44 (0)780 154 7643 t: +44 (0)20 7794 3090 e: benjamin.kopic@panContext.com w: http://www.panContext.com/ --=-F+jv7/Vb+ANyLJCgCgkr Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Jens

I just noticed something when I opened "Open file..." dialogue. In "Determine File Type:" combo list I do not have JPG file format (my default option is "By Extension"). Could this have anything to do with this?

Also, I tried finding any 16 bit JPG files on the net to try and see if I can open them, but I could not find any (if you have one, could you please e-mail it to me).

In addition, I have submitted this to bugzilla.gnome.org: BUG#126672
http://bugzilla.gnome.org/show_bug.cgi?id=126672

Best regards

Ben

On Mon, 2003-11-10 at 18:44, Jens Finke wrote: 
Hi Benjamin,

On Mon, 10 Nov 2003, Benjamin Kopic wrote:
> I am using Gnome 2.4 and keep getting the following error when trying to
> load any JPG file:
> 
> Loading failed
> Loading of image BigBrother.jpg failed.
> Reason: Unrecognized image file format.
> 
> However, I am able to load it using 'xloadimage' or analyse the files
> using 'jpeginfo' utility:
> 
> benko@smee benko $ jpeginfo download/BigBrother.jpg 
> download/BigBrother.jpg  600 x 554  24bit JFIF  N   97033 
> 
> Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility)
> and then open it without any problem in 'eog'.
> 
> The problem is only with JPG (JPEG) files, and I have not noticed any
> issues with other file types. I tried running 'eog' in a verbose/debug
> mode but could not found an option for it.
> 
> Annoyingly, this used to work (in my Gnome 2.2), which stopped working
> when I updated one of my applications (not sure which one). I suspect it
> has something to do with MIME types or something, but I cannot find out
> what. As a result the problem is in all Gnome applications that display
> JPG files (except mozilla and epiphany).

All Gnome programs use gdk-pixbuf as a graphic library for loading and
saving image files. Since this happens in all Gnome programs for you
(epiphany and mozilla both use other code for displaying images), it is
very likely a bug in this basic library (which comes with GTK).

Does it happen with all kind of jpeg files? This is a 24bit jpeg file, 
which may be the source of the problem. Anyway, could you attach a test 
file where it doesn't work to a bug in our bug tracking system at 
bugzilla.gnome.org? This would be very helpful. Thanks.


   Jens





-- 
benjamin kopic
m: +44 (0)780 154 7643
t: +44 (0)20 7794 3090
e: benjamin.kopic@panContext.com
w: http://www.panContext.com/
--=-F+jv7/Vb+ANyLJCgCgkr-- From benjamin.kopic@panContext.com Mon Nov 10 09:24:09 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mta05.btfusion.com (mta05.btfusion.com [62.172.195.14]) by mail.gnome.org (Postfix) with ESMTP id C48A8181AB for ; Mon, 10 Nov 2003 09:24:08 -0500 (EST) Received: from [213.123.217.51] (helo=smee.pancontext.com) by mta05.btfusion.com with esmtp (Exim 4.24) id 1AJCxa-0003qa-RD for eog-list@gnome.org; Mon, 10 Nov 2003 14:24:07 +0000 Subject: "Unrecognized image file format" error when loading JPG file From: Benjamin Kopic To: eog-list@gnome.org Content-Type: multipart/alternative; boundary="=-59Cxtk8HcDNZEifFUZAC" Organization: panContext Message-Id: <1068473871.12408.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 14:17:52 +0000 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: --=-59Cxtk8HcDNZEifFUZAC Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, I am using Gnome 2.4 and keep getting the following error when trying to load any JPG file: Loading failed Loading of image BigBrother.jpg failed. Reason: Unrecognized image file format. However, I am able to load it using 'xloadimage' or analyse the files using 'jpeginfo' utility: benko@smee benko $ jpeginfo download/BigBrother.jpg download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) and then open it without any problem in 'eog'. The problem is only with JPG (JPEG) files, and I have not noticed any issues with other file types. I tried running 'eog' in a verbose/debug mode but could not found an option for it. Annoyingly, this used to work (in my Gnome 2.2), which stopped working when I updated one of my applications (not sure which one). I suspect it has something to do with MIME types or something, but I cannot find out what. As a result the problem is in all Gnome applications that display JPG files (except mozilla and epiphany). Any help is really appreciated. BTW, I am a Linux novice, so please bare that in mind when responding. Best regards, -- benjamin kopic m: +44 (0)780 154 7643 t: +44 (0)20 7794 3090 e: benjamin.kopic@panContext.com w: http://www.panContext.com/ --=-59Cxtk8HcDNZEifFUZAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I am using Gnome 2.4 and keep getting the following error when trying to load any JPG file:

Loading failed
Loading of image BigBrother.jpg failed.
Reason: Unrecognized image file format.

However, I am able to load it using 'xloadimage' or analyse the files using 'jpeginfo' utility:

benko@smee benko $ jpeginfo download/BigBrother.jpg
download/BigBrother.jpg  600 x 554  24bit JFIF  N   97033

Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) and then open it without any problem in 'eog'.

The problem is only with JPG (JPEG) files, and I have not noticed any issues with other file types. I tried running 'eog' in a verbose/debug mode but could not found an option for it.

Annoyingly, this used to work (in my Gnome 2.2), which stopped working when I updated one of my applications (not sure which one). I suspect it has something to do with MIME types or something, but I cannot find out what. As a result the problem is in all Gnome applications that display JPG files (except mozilla and epiphany).

Any help is really appreciated. BTW, I am a Linux novice, so please bare that in mind when responding.

Best regards,
-- 
benjamin kopic
m: +44 (0)780 154 7643
t: +44 (0)20 7794 3090
e: benjamin.kopic@panContext.com
w: http://www.panContext.com/
--=-59Cxtk8HcDNZEifFUZAC-- From jens@triq.net Mon Nov 10 13:21:56 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mail1.ewetel.de (mail1-106.ewetel.de [212.6.122.106]) by mail.gnome.org (Postfix) with ESMTP id 08CD918CB4 for ; Mon, 10 Nov 2003 13:21:56 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-67-160.ewetel.net [80.228.67.160]) by mail1.ewetel.de (8.12.1/8.12.9) with ESMTP id hAAILOIx005632; Mon, 10 Nov 2003 19:21:24 +0100 (MET) Date: Mon, 10 Nov 2003 19:26:54 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: Bryan W Clark Cc: eog-list@gnome.org Subject: Eog collection suggestions [was Re: [PATCH] EOG Collection] In-Reply-To: <1067569190.22999.71.camel@localhost> Message-ID: References: <1067376656.4775.162.camel@localhost> <3F9FB5D3.2010003@triq.net> <1067569190.22999.71.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hi Bryan, sorry for the delay in my reply (have been busy and then forgot about your mail :/) On Thu, 30 Oct 2003, Bryan W Clark wrote: > IMHO the idea of the collection viewer is to provide a filmstrip / > slideshow for the user. I think that in order to design for the > filmstrip model we can't providing a quick overview of all images at the > same time; the two design paradigms are mutually exclusive in our > current view. Actually I don't see a big problem here. Maybe we can change the behavior for the collection view to filmstrip mode, if it is used as nautilus view. > [...] > > > - With each saving of a jpeg the quality is reduced (lossy format). This > > can be avoided if libjpeg is used for lossless transformation of local > > jpeg files (which is planned). > > Ok, I wasn't aware of that. I'm sure you're almost all the way through > it, you've been making great progress so far. Once libjpeg is > incorporated I think an auto-save would _then_ be a good feature to > add. Hopefully we can work together on a good way to implement it. I don't have a clue how to integrate the libjpeg functionality into eog nicely yet. There is libeog/eog-image-jpeg.[ch] already, which provides the jpeg saveing functions only at the moment. This is probably the best place to add more jpeg specific image functions. > > - A nice thing in EoG is that you can rotate a large bunch of images in > > one run, while only the thumbnail representations are rotated. This is > > extremly fast and you get a quick overview if your transformation was > > right (eg. I always get horizontal/vertical flipping wrong). If an image is > - You can undo transformations, without touching the files again. > > I think this is a cool feature, but I wasn't aware of it until I dove > into the code. Yes, the documentation has definitely a lot room for improvements. Although there were some updates recently, haven't look at them yet. > jbut for this feature the usage group of people probably represent a > significantly small percent of the population of all our users. But I am in this 'small' group, so the feature will stay :). Maybe there is a way to make it more user visible, beside a better documentation. > Download new photos off their digital camera into directory "my trip" > Open up nautilus and navigate to "my trip" directory Now switch to > collection view so that they can show off the pictures from their trip > to everyone else, narrating each shot as it is in the preview window. > If they come across an image that is shot at a different rotation than > the others they would like to rotate it during their "mini-slideshow" > and not have to rotate it again when they leave the directory and open > it up again to show their pictures to someone else. Your use-case description makes sense. Though the argument of 'don't overwrite user-data silently' is a strong one. And eog shouldn't ask the user for each image seperately. Therefore I prefer the 'ask user to save modified images on exit' method. BTW: Eog remembers the transformation state during a session. If you load an image, rotate it, load another one and than later the first one again, eog will rotate it for you automatically. > To throw out an idea to solve the "rotated it the wrong way" situation, > we could try to implement a high feedback rotation system, similar to > what the new GIMP does does for image rotation. Yes, but than you don't have a stateless user interface anymore, which sucks IMO for a 'simple' image viewer. > I agree this is a problem, I'm on the GUP team and am working out a spec > to try to solve this right now. Do you have a link for more infos? Never heard of GUP team. > > - Eog can save only 'png' and 'jpeg' files. If you rotate eg. a gif file > > the automatic save will fail. > > I think this is a problem with the EOG save in general and not so much > with the auto-save idea, I'm sure we can fix this one as well with a > little hacking. Than, go ahead and add saving functionality for all kind of image types to gdk-pixbuf (where it belongs). Eog whill pickup these automatically. > > My idea for a better usability on this for 2.6 is: > > - Visually indicate that an image was modified > > - Select all modified images with one menu function > > - Ask the user on close if he want's to save the modifications if there > > are any. > > Take a look at the "rotate mode" idea or maybe you can elaborate a > little more on how this will work visually, as I can't see it. IMO this is pretty clear, what don't you understand here? > On close EOG asks the users "You've changed 'pict1454.jpg', do you want > to save?" And then again for every image other image that was rotated. > I couldn't identify any of the names my camera gives my images and I > don't rename them since I have too many to do that. I _can_ remember > which one I want to rotate when I'm looking at it and see that it's > wrong. Well, we can do it better. We have the thumbnails for all the images we are showing. So we can show the user the files which changed. Regards, Jens From jens@triq.net Mon Nov 10 13:38:53 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mail1.ewetel.de (mail1-106.ewetel.de [212.6.122.106]) by mail.gnome.org (Postfix) with ESMTP id AA01318184 for ; Mon, 10 Nov 2003 13:38:52 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-67-160.ewetel.net [80.228.67.160]) by mail1.ewetel.de (8.12.1/8.12.9) with ESMTP id hAAIcoIx013298; Mon, 10 Nov 2003 19:38:51 +0100 (MET) Date: Mon, 10 Nov 2003 19:44:20 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: Benjamin Kopic Cc: eog-list@gnome.org Subject: Re: "Unrecognized image file format" error when loading JPG file In-Reply-To: <1068473871.12408.24.camel@localhost> Message-ID: References: <1068473871.12408.24.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hi Benjamin, On Mon, 10 Nov 2003, Benjamin Kopic wrote: > I am using Gnome 2.4 and keep getting the following error when trying to > load any JPG file: > > Loading failed > Loading of image BigBrother.jpg failed. > Reason: Unrecognized image file format. > > However, I am able to load it using 'xloadimage' or analyse the files > using 'jpeginfo' utility: > > benko@smee benko $ jpeginfo download/BigBrother.jpg > download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 > > Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) > and then open it without any problem in 'eog'. > > The problem is only with JPG (JPEG) files, and I have not noticed any > issues with other file types. I tried running 'eog' in a verbose/debug > mode but could not found an option for it. > > Annoyingly, this used to work (in my Gnome 2.2), which stopped working > when I updated one of my applications (not sure which one). I suspect it > has something to do with MIME types or something, but I cannot find out > what. As a result the problem is in all Gnome applications that display > JPG files (except mozilla and epiphany). All Gnome programs use gdk-pixbuf as a graphic library for loading and saving image files. Since this happens in all Gnome programs for you (epiphany and mozilla both use other code for displaying images), it is very likely a bug in this basic library (which comes with GTK). Does it happen with all kind of jpeg files? This is a 24bit jpeg file, which may be the source of the problem. Anyway, could you attach a test file where it doesn't work to a bug in our bug tracking system at bugzilla.gnome.org? This would be very helpful. Thanks. Jens From clarkbw@clarkson.edu Mon Nov 10 17:34:26 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from bryan.clarkson.edu (bryan.sclab.clarkson.edu [128.153.144.201]) by mail.gnome.org (Postfix) with ESMTP id A3E9718F46 for ; Mon, 10 Nov 2003 17:34:26 -0500 (EST) Received: by bryan.clarkson.edu (Postfix, from userid 1000) id 2EEE538657F; Mon, 10 Nov 2003 17:34:24 -0500 (EST) Subject: Re: Eog collection suggestions [was Re: [PATCH] EOG Collection] From: Bryan W Clark To: eog-list@gnome.org In-Reply-To: References: <1067376656.4775.162.camel@localhost> <3F9FB5D3.2010003@triq.net> <1067569190.22999.71.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Clarkson Open Source Institute Message-Id: <1068503663.4368.190.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 17:34:24 -0500 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hey Jens ~ On Mon, 2003-11-10 at 13:26, Jens Finke wrote: > sorry for the delay in my reply (have been busy and then forgot about your > mail :/) no problem at all, thanks for taking the time to reply back to me. > On Thu, 30 Oct 2003, Bryan W Clark wrote: > > IMHO the idea of the collection viewer is to provide a filmstrip / > > slideshow for the user. I think that in order to design for the > > filmstrip model we can't providing a quick overview of all images at the > > same time; the two design paradigms are mutually exclusive in our > > current view. > > Actually I don't see a big problem here. Maybe we can change the > behavior for the collection view to filmstrip mode, if it is used as > nautilus view. Woah! I think you just turned everything I know upside down. All of my collection suggestions have been directed solely at the Nautilus view; I had no idea that you could open up directories in EOG by itself until a minute ago. That is really neat, but not the part I was after. :-) Consider everything I've suggested before and from here on to be only towards the Nautilus component _only_. I can see lots of value in keeping EOG feature rich and I would love to continue to help if you'd like; but my main concern was and is the Nautilus View component. > I don't have a clue how to integrate the libjpeg functionality into eog > nicely yet. There is libeog/eog-image-jpeg.[ch] already, which provides the > jpeg saveing functions only at the moment. This is probably the best place > to add more jpeg specific image functions. Hm, I don't know anything about this either. The best I can offer you is that I'll look and ask around for anyone with experience with this stuff so we could get it done right. > Yes, the documentation has definitely a lot room for improvements. > Although there were some updates recently, haven't look at them yet. It seems you have some great ideas towards making this piece easy to use without providing more docs for people to read. > But I am in this 'small' group, so the feature will stay :). Maybe there > is a way to make it more user visible, beside a better documentation. Totally agreed that this should stay. The user group who would take advantage of this are not to be trifle with :) Again, I think my only concern was for the Nautilus view; and if we make this the _only_ way to change images I can't figure a way to convey it to the user in an intuitive enough way that many people will take advantage of how cool this part really is. I'm at a brick wall of ideas to make this work so that people would just know what it's doing and how. My problem is that I'm stuck in this mental model for users [1] and maybe you can steer me to another one. The mental model that I see the user having is of a physical "photo album" or slide projector system. This is why I was thinking of the I change the rotation of the picture in the album/slides and it stays the way you last rotated it automatically (physical pictures tend to follow this property of Newtonian physics :). Without asking if you're sure afterwords. The one at a time viewing with knowing which picture is next comes from expanding the album idea as well. I'm interested in making the Nautilus View as simple as possible even if that means losing extra functionality (not that we rip the functions out, just that they aren't easy to get to from within nautilus). So if I'm way off on this, or you have a different user mental model I can stop crying about this. :) [...] > BTW: Eog remembers the transformation > state during a session. If you load an image, rotate it, load another one > and than later the first one again, eog will rotate it for you > automatically. Oh, cool stuff. I think I experienced the reset session after shutdown and open up again of EOG and so this didn't occur to me. > > To throw out an idea to solve the "rotated it the wrong way" situation, > > we could try to implement a high feedback rotation system, similar to > > what the new GIMP does does for image rotation. > > Yes, but than you don't have a stateless user interface anymore, which > sucks IMO for a 'simple' image viewer. Totally right, the idea is really overblown for the problem, just trying to throw out something new. > Do you have a link for more infos? Never heard of GUP team. Oh, GUP, I should have said the GNOME Usability Project, http://developer.gnome.org/projects/gup/ [....] > IMO this is pretty clear, what don't you understand here? I guess it just relates to the user mental model that I've constructed for this component. In the Nautilus view I think we're going to the least experienced people vs. the EOG view mode. In EOG what you are working towards feels like a file/photo manage type model which I don't think relates to people using the Nautilus view, but again this might not be the model you're working with and we're just missing something in the communication of these things. > Well, we can do it better. We have the thumbnails for all the images we > are showing. So we can show the user the files which changed. Definitely! Thanks for all your time, ~ Bryan [1] User Mental Models - Simply put is how users view what is actually being done vs. what is really going on behind the scenes. (example being, everyone knows how a T.V. works right? You turn it on and see shows, but no one wants to think about how the CRT actually draws on the screen, although things like the wonderfully outdated VHhold button had us scarily close to understanding the phase shifting that was going on. But T.V. designers have since dropped the VHHold button and other things because over time they knew that people just want to surf channels, not mess with the inner workings. ) -- Bryan W Clark Graduate Student Math && Computer Science Dept. Human Computer Interaction Group Clarkson University Potsdam, NY USA http://www.clarkson.edu/~clarkbw/ From benjamin.kopic@panContext.com Mon Nov 10 19:06:43 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mta03.btfusion.com (mta03.btfusion.com [62.172.195.12]) by mail.gnome.org (Postfix) with ESMTP id 0B20C18103 for ; Mon, 10 Nov 2003 19:06:43 -0500 (EST) Received: from [213.123.217.51] (helo=smee.pancontext.com) by mta03.btfusion.com with esmtp (Exim 4.24) id 1AJM3N-0004sE-EQ for eog-list@gnome.org; Tue, 11 Nov 2003 00:06:41 +0000 Subject: Re: "Unrecognized image file format" error when loading JPG file From: Benjamin Kopic To: eog-list@gnome.org In-Reply-To: References: <1068473871.12408.24.camel@localhost> Content-Type: multipart/alternative; boundary="=-F+jv7/Vb+ANyLJCgCgkr" Organization: panContext Message-Id: <1068509200.4702.28.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 11 Nov 2003 00:06:41 +0000 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: --=-F+jv7/Vb+ANyLJCgCgkr Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Jens I just noticed something when I opened "Open file..." dialogue. In "Determine File Type:" combo list I do not have JPG file format (my default option is "By Extension"). Could this have anything to do with this? Also, I tried finding any 16 bit JPG files on the net to try and see if I can open them, but I could not find any (if you have one, could you please e-mail it to me). In addition, I have submitted this to bugzilla.gnome.org: BUG#126672 http://bugzilla.gnome.org/show_bug.cgi?id=126672 Best regards Ben On Mon, 2003-11-10 at 18:44, Jens Finke wrote: > Hi Benjamin, > > On Mon, 10 Nov 2003, Benjamin Kopic wrote: > > I am using Gnome 2.4 and keep getting the following error when trying to > > load any JPG file: > > > > Loading failed > > Loading of image BigBrother.jpg failed. > > Reason: Unrecognized image file format. > > > > However, I am able to load it using 'xloadimage' or analyse the files > > using 'jpeginfo' utility: > > > > benko@smee benko $ jpeginfo download/BigBrother.jpg > > download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 > > > > Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) > > and then open it without any problem in 'eog'. > > > > The problem is only with JPG (JPEG) files, and I have not noticed any > > issues with other file types. I tried running 'eog' in a verbose/debug > > mode but could not found an option for it. > > > > Annoyingly, this used to work (in my Gnome 2.2), which stopped working > > when I updated one of my applications (not sure which one). I suspect it > > has something to do with MIME types or something, but I cannot find out > > what. As a result the problem is in all Gnome applications that display > > JPG files (except mozilla and epiphany). > > All Gnome programs use gdk-pixbuf as a graphic library for loading and > saving image files. Since this happens in all Gnome programs for you > (epiphany and mozilla both use other code for displaying images), it is > very likely a bug in this basic library (which comes with GTK). > > Does it happen with all kind of jpeg files? This is a 24bit jpeg file, > which may be the source of the problem. Anyway, could you attach a test > file where it doesn't work to a bug in our bug tracking system at > bugzilla.gnome.org? This would be very helpful. Thanks. > > > Jens -- benjamin kopic m: +44 (0)780 154 7643 t: +44 (0)20 7794 3090 e: benjamin.kopic@panContext.com w: http://www.panContext.com/ --=-F+jv7/Vb+ANyLJCgCgkr Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Jens

I just noticed something when I opened "Open file..." dialogue. In "Determine File Type:" combo list I do not have JPG file format (my default option is "By Extension"). Could this have anything to do with this?

Also, I tried finding any 16 bit JPG files on the net to try and see if I can open them, but I could not find any (if you have one, could you please e-mail it to me).

In addition, I have submitted this to bugzilla.gnome.org: BUG#126672
http://bugzilla.gnome.org/show_bug.cgi?id=126672

Best regards

Ben

On Mon, 2003-11-10 at 18:44, Jens Finke wrote: 
Hi Benjamin,

On Mon, 10 Nov 2003, Benjamin Kopic wrote:
> I am using Gnome 2.4 and keep getting the following error when trying to
> load any JPG file:
> 
> Loading failed
> Loading of image BigBrother.jpg failed.
> Reason: Unrecognized image file format.
> 
> However, I am able to load it using 'xloadimage' or analyse the files
> using 'jpeginfo' utility:
> 
> benko@smee benko $ jpeginfo download/BigBrother.jpg 
> download/BigBrother.jpg  600 x 554  24bit JFIF  N   97033 
> 
> Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility)
> and then open it without any problem in 'eog'.
> 
> The problem is only with JPG (JPEG) files, and I have not noticed any
> issues with other file types. I tried running 'eog' in a verbose/debug
> mode but could not found an option for it.
> 
> Annoyingly, this used to work (in my Gnome 2.2), which stopped working
> when I updated one of my applications (not sure which one). I suspect it
> has something to do with MIME types or something, but I cannot find out
> what. As a result the problem is in all Gnome applications that display
> JPG files (except mozilla and epiphany).

All Gnome programs use gdk-pixbuf as a graphic library for loading and
saving image files. Since this happens in all Gnome programs for you
(epiphany and mozilla both use other code for displaying images), it is
very likely a bug in this basic library (which comes with GTK).

Does it happen with all kind of jpeg files? This is a 24bit jpeg file, 
which may be the source of the problem. Anyway, could you attach a test 
file where it doesn't work to a bug in our bug tracking system at 
bugzilla.gnome.org? This would be very helpful. Thanks.


   Jens





-- 
benjamin kopic
m: +44 (0)780 154 7643
t: +44 (0)20 7794 3090
e: benjamin.kopic@panContext.com
w: http://www.panContext.com/
--=-F+jv7/Vb+ANyLJCgCgkr-- From benjamin.kopic@panContext.com Mon Nov 10 09:24:09 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mta05.btfusion.com (mta05.btfusion.com [62.172.195.14]) by mail.gnome.org (Postfix) with ESMTP id C48A8181AB for ; Mon, 10 Nov 2003 09:24:08 -0500 (EST) Received: from [213.123.217.51] (helo=smee.pancontext.com) by mta05.btfusion.com with esmtp (Exim 4.24) id 1AJCxa-0003qa-RD for eog-list@gnome.org; Mon, 10 Nov 2003 14:24:07 +0000 Subject: "Unrecognized image file format" error when loading JPG file From: Benjamin Kopic To: eog-list@gnome.org Content-Type: multipart/alternative; boundary="=-59Cxtk8HcDNZEifFUZAC" Organization: panContext Message-Id: <1068473871.12408.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 14:17:52 +0000 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: --=-59Cxtk8HcDNZEifFUZAC Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, I am using Gnome 2.4 and keep getting the following error when trying to load any JPG file: Loading failed Loading of image BigBrother.jpg failed. Reason: Unrecognized image file format. However, I am able to load it using 'xloadimage' or analyse the files using 'jpeginfo' utility: benko@smee benko $ jpeginfo download/BigBrother.jpg download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) and then open it without any problem in 'eog'. The problem is only with JPG (JPEG) files, and I have not noticed any issues with other file types. I tried running 'eog' in a verbose/debug mode but could not found an option for it. Annoyingly, this used to work (in my Gnome 2.2), which stopped working when I updated one of my applications (not sure which one). I suspect it has something to do with MIME types or something, but I cannot find out what. As a result the problem is in all Gnome applications that display JPG files (except mozilla and epiphany). Any help is really appreciated. BTW, I am a Linux novice, so please bare that in mind when responding. Best regards, -- benjamin kopic m: +44 (0)780 154 7643 t: +44 (0)20 7794 3090 e: benjamin.kopic@panContext.com w: http://www.panContext.com/ --=-59Cxtk8HcDNZEifFUZAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I am using Gnome 2.4 and keep getting the following error when trying to load any JPG file:

Loading failed
Loading of image BigBrother.jpg failed.
Reason: Unrecognized image file format.

However, I am able to load it using 'xloadimage' or analyse the files using 'jpeginfo' utility:

benko@smee benko $ jpeginfo download/BigBrother.jpg
download/BigBrother.jpg  600 x 554  24bit JFIF  N   97033

Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) and then open it without any problem in 'eog'.

The problem is only with JPG (JPEG) files, and I have not noticed any issues with other file types. I tried running 'eog' in a verbose/debug mode but could not found an option for it.

Annoyingly, this used to work (in my Gnome 2.2), which stopped working when I updated one of my applications (not sure which one). I suspect it has something to do with MIME types or something, but I cannot find out what. As a result the problem is in all Gnome applications that display JPG files (except mozilla and epiphany).

Any help is really appreciated. BTW, I am a Linux novice, so please bare that in mind when responding.

Best regards,
-- 
benjamin kopic
m: +44 (0)780 154 7643
t: +44 (0)20 7794 3090
e: benjamin.kopic@panContext.com
w: http://www.panContext.com/
--=-59Cxtk8HcDNZEifFUZAC-- From jens@triq.net Mon Nov 10 13:21:56 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mail1.ewetel.de (mail1-106.ewetel.de [212.6.122.106]) by mail.gnome.org (Postfix) with ESMTP id 08CD918CB4 for ; Mon, 10 Nov 2003 13:21:56 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-67-160.ewetel.net [80.228.67.160]) by mail1.ewetel.de (8.12.1/8.12.9) with ESMTP id hAAILOIx005632; Mon, 10 Nov 2003 19:21:24 +0100 (MET) Date: Mon, 10 Nov 2003 19:26:54 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: Bryan W Clark Cc: eog-list@gnome.org Subject: Eog collection suggestions [was Re: [PATCH] EOG Collection] In-Reply-To: <1067569190.22999.71.camel@localhost> Message-ID: References: <1067376656.4775.162.camel@localhost> <3F9FB5D3.2010003@triq.net> <1067569190.22999.71.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hi Bryan, sorry for the delay in my reply (have been busy and then forgot about your mail :/) On Thu, 30 Oct 2003, Bryan W Clark wrote: > IMHO the idea of the collection viewer is to provide a filmstrip / > slideshow for the user. I think that in order to design for the > filmstrip model we can't providing a quick overview of all images at the > same time; the two design paradigms are mutually exclusive in our > current view. Actually I don't see a big problem here. Maybe we can change the behavior for the collection view to filmstrip mode, if it is used as nautilus view. > [...] > > > - With each saving of a jpeg the quality is reduced (lossy format). This > > can be avoided if libjpeg is used for lossless transformation of local > > jpeg files (which is planned). > > Ok, I wasn't aware of that. I'm sure you're almost all the way through > it, you've been making great progress so far. Once libjpeg is > incorporated I think an auto-save would _then_ be a good feature to > add. Hopefully we can work together on a good way to implement it. I don't have a clue how to integrate the libjpeg functionality into eog nicely yet. There is libeog/eog-image-jpeg.[ch] already, which provides the jpeg saveing functions only at the moment. This is probably the best place to add more jpeg specific image functions. > > - A nice thing in EoG is that you can rotate a large bunch of images in > > one run, while only the thumbnail representations are rotated. This is > > extremly fast and you get a quick overview if your transformation was > > right (eg. I always get horizontal/vertical flipping wrong). If an image is > - You can undo transformations, without touching the files again. > > I think this is a cool feature, but I wasn't aware of it until I dove > into the code. Yes, the documentation has definitely a lot room for improvements. Although there were some updates recently, haven't look at them yet. > jbut for this feature the usage group of people probably represent a > significantly small percent of the population of all our users. But I am in this 'small' group, so the feature will stay :). Maybe there is a way to make it more user visible, beside a better documentation. > Download new photos off their digital camera into directory "my trip" > Open up nautilus and navigate to "my trip" directory Now switch to > collection view so that they can show off the pictures from their trip > to everyone else, narrating each shot as it is in the preview window. > If they come across an image that is shot at a different rotation than > the others they would like to rotate it during their "mini-slideshow" > and not have to rotate it again when they leave the directory and open > it up again to show their pictures to someone else. Your use-case description makes sense. Though the argument of 'don't overwrite user-data silently' is a strong one. And eog shouldn't ask the user for each image seperately. Therefore I prefer the 'ask user to save modified images on exit' method. BTW: Eog remembers the transformation state during a session. If you load an image, rotate it, load another one and than later the first one again, eog will rotate it for you automatically. > To throw out an idea to solve the "rotated it the wrong way" situation, > we could try to implement a high feedback rotation system, similar to > what the new GIMP does does for image rotation. Yes, but than you don't have a stateless user interface anymore, which sucks IMO for a 'simple' image viewer. > I agree this is a problem, I'm on the GUP team and am working out a spec > to try to solve this right now. Do you have a link for more infos? Never heard of GUP team. > > - Eog can save only 'png' and 'jpeg' files. If you rotate eg. a gif file > > the automatic save will fail. > > I think this is a problem with the EOG save in general and not so much > with the auto-save idea, I'm sure we can fix this one as well with a > little hacking. Than, go ahead and add saving functionality for all kind of image types to gdk-pixbuf (where it belongs). Eog whill pickup these automatically. > > My idea for a better usability on this for 2.6 is: > > - Visually indicate that an image was modified > > - Select all modified images with one menu function > > - Ask the user on close if he want's to save the modifications if there > > are any. > > Take a look at the "rotate mode" idea or maybe you can elaborate a > little more on how this will work visually, as I can't see it. IMO this is pretty clear, what don't you understand here? > On close EOG asks the users "You've changed 'pict1454.jpg', do you want > to save?" And then again for every image other image that was rotated. > I couldn't identify any of the names my camera gives my images and I > don't rename them since I have too many to do that. I _can_ remember > which one I want to rotate when I'm looking at it and see that it's > wrong. Well, we can do it better. We have the thumbnails for all the images we are showing. So we can show the user the files which changed. Regards, Jens From jens@triq.net Mon Nov 10 13:38:53 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mail1.ewetel.de (mail1-106.ewetel.de [212.6.122.106]) by mail.gnome.org (Postfix) with ESMTP id AA01318184 for ; Mon, 10 Nov 2003 13:38:52 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-67-160.ewetel.net [80.228.67.160]) by mail1.ewetel.de (8.12.1/8.12.9) with ESMTP id hAAIcoIx013298; Mon, 10 Nov 2003 19:38:51 +0100 (MET) Date: Mon, 10 Nov 2003 19:44:20 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: Benjamin Kopic Cc: eog-list@gnome.org Subject: Re: "Unrecognized image file format" error when loading JPG file In-Reply-To: <1068473871.12408.24.camel@localhost> Message-ID: References: <1068473871.12408.24.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hi Benjamin, On Mon, 10 Nov 2003, Benjamin Kopic wrote: > I am using Gnome 2.4 and keep getting the following error when trying to > load any JPG file: > > Loading failed > Loading of image BigBrother.jpg failed. > Reason: Unrecognized image file format. > > However, I am able to load it using 'xloadimage' or analyse the files > using 'jpeginfo' utility: > > benko@smee benko $ jpeginfo download/BigBrother.jpg > download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 > > Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) > and then open it without any problem in 'eog'. > > The problem is only with JPG (JPEG) files, and I have not noticed any > issues with other file types. I tried running 'eog' in a verbose/debug > mode but could not found an option for it. > > Annoyingly, this used to work (in my Gnome 2.2), which stopped working > when I updated one of my applications (not sure which one). I suspect it > has something to do with MIME types or something, but I cannot find out > what. As a result the problem is in all Gnome applications that display > JPG files (except mozilla and epiphany). All Gnome programs use gdk-pixbuf as a graphic library for loading and saving image files. Since this happens in all Gnome programs for you (epiphany and mozilla both use other code for displaying images), it is very likely a bug in this basic library (which comes with GTK). Does it happen with all kind of jpeg files? This is a 24bit jpeg file, which may be the source of the problem. Anyway, could you attach a test file where it doesn't work to a bug in our bug tracking system at bugzilla.gnome.org? This would be very helpful. Thanks. Jens From clarkbw@clarkson.edu Mon Nov 10 17:34:26 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from bryan.clarkson.edu (bryan.sclab.clarkson.edu [128.153.144.201]) by mail.gnome.org (Postfix) with ESMTP id A3E9718F46 for ; Mon, 10 Nov 2003 17:34:26 -0500 (EST) Received: by bryan.clarkson.edu (Postfix, from userid 1000) id 2EEE538657F; Mon, 10 Nov 2003 17:34:24 -0500 (EST) Subject: Re: Eog collection suggestions [was Re: [PATCH] EOG Collection] From: Bryan W Clark To: eog-list@gnome.org In-Reply-To: References: <1067376656.4775.162.camel@localhost> <3F9FB5D3.2010003@triq.net> <1067569190.22999.71.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Clarkson Open Source Institute Message-Id: <1068503663.4368.190.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 17:34:24 -0500 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hey Jens ~ On Mon, 2003-11-10 at 13:26, Jens Finke wrote: > sorry for the delay in my reply (have been busy and then forgot about your > mail :/) no problem at all, thanks for taking the time to reply back to me. > On Thu, 30 Oct 2003, Bryan W Clark wrote: > > IMHO the idea of the collection viewer is to provide a filmstrip / > > slideshow for the user. I think that in order to design for the > > filmstrip model we can't providing a quick overview of all images at the > > same time; the two design paradigms are mutually exclusive in our > > current view. > > Actually I don't see a big problem here. Maybe we can change the > behavior for the collection view to filmstrip mode, if it is used as > nautilus view. Woah! I think you just turned everything I know upside down. All of my collection suggestions have been directed solely at the Nautilus view; I had no idea that you could open up directories in EOG by itself until a minute ago. That is really neat, but not the part I was after. :-) Consider everything I've suggested before and from here on to be only towards the Nautilus component _only_. I can see lots of value in keeping EOG feature rich and I would love to continue to help if you'd like; but my main concern was and is the Nautilus View component. > I don't have a clue how to integrate the libjpeg functionality into eog > nicely yet. There is libeog/eog-image-jpeg.[ch] already, which provides the > jpeg saveing functions only at the moment. This is probably the best place > to add more jpeg specific image functions. Hm, I don't know anything about this either. The best I can offer you is that I'll look and ask around for anyone with experience with this stuff so we could get it done right. > Yes, the documentation has definitely a lot room for improvements. > Although there were some updates recently, haven't look at them yet. It seems you have some great ideas towards making this piece easy to use without providing more docs for people to read. > But I am in this 'small' group, so the feature will stay :). Maybe there > is a way to make it more user visible, beside a better documentation. Totally agreed that this should stay. The user group who would take advantage of this are not to be trifle with :) Again, I think my only concern was for the Nautilus view; and if we make this the _only_ way to change images I can't figure a way to convey it to the user in an intuitive enough way that many people will take advantage of how cool this part really is. I'm at a brick wall of ideas to make this work so that people would just know what it's doing and how. My problem is that I'm stuck in this mental model for users [1] and maybe you can steer me to another one. The mental model that I see the user having is of a physical "photo album" or slide projector system. This is why I was thinking of the I change the rotation of the picture in the album/slides and it stays the way you last rotated it automatically (physical pictures tend to follow this property of Newtonian physics :). Without asking if you're sure afterwords. The one at a time viewing with knowing which picture is next comes from expanding the album idea as well. I'm interested in making the Nautilus View as simple as possible even if that means losing extra functionality (not that we rip the functions out, just that they aren't easy to get to from within nautilus). So if I'm way off on this, or you have a different user mental model I can stop crying about this. :) [...] > BTW: Eog remembers the transformation > state during a session. If you load an image, rotate it, load another one > and than later the first one again, eog will rotate it for you > automatically. Oh, cool stuff. I think I experienced the reset session after shutdown and open up again of EOG and so this didn't occur to me. > > To throw out an idea to solve the "rotated it the wrong way" situation, > > we could try to implement a high feedback rotation system, similar to > > what the new GIMP does does for image rotation. > > Yes, but than you don't have a stateless user interface anymore, which > sucks IMO for a 'simple' image viewer. Totally right, the idea is really overblown for the problem, just trying to throw out something new. > Do you have a link for more infos? Never heard of GUP team. Oh, GUP, I should have said the GNOME Usability Project, http://developer.gnome.org/projects/gup/ [....] > IMO this is pretty clear, what don't you understand here? I guess it just relates to the user mental model that I've constructed for this component. In the Nautilus view I think we're going to the least experienced people vs. the EOG view mode. In EOG what you are working towards feels like a file/photo manage type model which I don't think relates to people using the Nautilus view, but again this might not be the model you're working with and we're just missing something in the communication of these things. > Well, we can do it better. We have the thumbnails for all the images we > are showing. So we can show the user the files which changed. Definitely! Thanks for all your time, ~ Bryan [1] User Mental Models - Simply put is how users view what is actually being done vs. what is really going on behind the scenes. (example being, everyone knows how a T.V. works right? You turn it on and see shows, but no one wants to think about how the CRT actually draws on the screen, although things like the wonderfully outdated VHhold button had us scarily close to understanding the phase shifting that was going on. But T.V. designers have since dropped the VHHold button and other things because over time they knew that people just want to surf channels, not mess with the inner workings. ) -- Bryan W Clark Graduate Student Math && Computer Science Dept. Human Computer Interaction Group Clarkson University Potsdam, NY USA http://www.clarkson.edu/~clarkbw/ From benjamin.kopic@panContext.com Mon Nov 10 19:06:43 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mta03.btfusion.com (mta03.btfusion.com [62.172.195.12]) by mail.gnome.org (Postfix) with ESMTP id 0B20C18103 for ; Mon, 10 Nov 2003 19:06:43 -0500 (EST) Received: from [213.123.217.51] (helo=smee.pancontext.com) by mta03.btfusion.com with esmtp (Exim 4.24) id 1AJM3N-0004sE-EQ for eog-list@gnome.org; Tue, 11 Nov 2003 00:06:41 +0000 Subject: Re: "Unrecognized image file format" error when loading JPG file From: Benjamin Kopic To: eog-list@gnome.org In-Reply-To: References: <1068473871.12408.24.camel@localhost> Content-Type: multipart/alternative; boundary="=-F+jv7/Vb+ANyLJCgCgkr" Organization: panContext Message-Id: <1068509200.4702.28.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 11 Nov 2003 00:06:41 +0000 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: --=-F+jv7/Vb+ANyLJCgCgkr Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Jens I just noticed something when I opened "Open file..." dialogue. In "Determine File Type:" combo list I do not have JPG file format (my default option is "By Extension"). Could this have anything to do with this? Also, I tried finding any 16 bit JPG files on the net to try and see if I can open them, but I could not find any (if you have one, could you please e-mail it to me). In addition, I have submitted this to bugzilla.gnome.org: BUG#126672 http://bugzilla.gnome.org/show_bug.cgi?id=126672 Best regards Ben On Mon, 2003-11-10 at 18:44, Jens Finke wrote: > Hi Benjamin, > > On Mon, 10 Nov 2003, Benjamin Kopic wrote: > > I am using Gnome 2.4 and keep getting the following error when trying to > > load any JPG file: > > > > Loading failed > > Loading of image BigBrother.jpg failed. > > Reason: Unrecognized image file format. > > > > However, I am able to load it using 'xloadimage' or analyse the files > > using 'jpeginfo' utility: > > > > benko@smee benko $ jpeginfo download/BigBrother.jpg > > download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 > > > > Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) > > and then open it without any problem in 'eog'. > > > > The problem is only with JPG (JPEG) files, and I have not noticed any > > issues with other file types. I tried running 'eog' in a verbose/debug > > mode but could not found an option for it. > > > > Annoyingly, this used to work (in my Gnome 2.2), which stopped working > > when I updated one of my applications (not sure which one). I suspect it > > has something to do with MIME types or something, but I cannot find out > > what. As a result the problem is in all Gnome applications that display > > JPG files (except mozilla and epiphany). > > All Gnome programs use gdk-pixbuf as a graphic library for loading and > saving image files. Since this happens in all Gnome programs for you > (epiphany and mozilla both use other code for displaying images), it is > very likely a bug in this basic library (which comes with GTK). > > Does it happen with all kind of jpeg files? This is a 24bit jpeg file, > which may be the source of the problem. Anyway, could you attach a test > file where it doesn't work to a bug in our bug tracking system at > bugzilla.gnome.org? This would be very helpful. Thanks. > > > Jens -- benjamin kopic m: +44 (0)780 154 7643 t: +44 (0)20 7794 3090 e: benjamin.kopic@panContext.com w: http://www.panContext.com/ --=-F+jv7/Vb+ANyLJCgCgkr Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Jens

I just noticed something when I opened "Open file..." dialogue. In "Determine File Type:" combo list I do not have JPG file format (my default option is "By Extension"). Could this have anything to do with this?

Also, I tried finding any 16 bit JPG files on the net to try and see if I can open them, but I could not find any (if you have one, could you please e-mail it to me).

In addition, I have submitted this to bugzilla.gnome.org: BUG#126672
http://bugzilla.gnome.org/show_bug.cgi?id=126672

Best regards

Ben

On Mon, 2003-11-10 at 18:44, Jens Finke wrote: 
Hi Benjamin,

On Mon, 10 Nov 2003, Benjamin Kopic wrote:
> I am using Gnome 2.4 and keep getting the following error when trying to
> load any JPG file:
> 
> Loading failed
> Loading of image BigBrother.jpg failed.
> Reason: Unrecognized image file format.
> 
> However, I am able to load it using 'xloadimage' or analyse the files
> using 'jpeginfo' utility:
> 
> benko@smee benko $ jpeginfo download/BigBrother.jpg 
> download/BigBrother.jpg  600 x 554  24bit JFIF  N   97033 
> 
> Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility)
> and then open it without any problem in 'eog'.
> 
> The problem is only with JPG (JPEG) files, and I have not noticed any
> issues with other file types. I tried running 'eog' in a verbose/debug
> mode but could not found an option for it.
> 
> Annoyingly, this used to work (in my Gnome 2.2), which stopped working
> when I updated one of my applications (not sure which one). I suspect it
> has something to do with MIME types or something, but I cannot find out
> what. As a result the problem is in all Gnome applications that display
> JPG files (except mozilla and epiphany).

All Gnome programs use gdk-pixbuf as a graphic library for loading and
saving image files. Since this happens in all Gnome programs for you
(epiphany and mozilla both use other code for displaying images), it is
very likely a bug in this basic library (which comes with GTK).

Does it happen with all kind of jpeg files? This is a 24bit jpeg file, 
which may be the source of the problem. Anyway, could you attach a test 
file where it doesn't work to a bug in our bug tracking system at 
bugzilla.gnome.org? This would be very helpful. Thanks.


   Jens





-- 
benjamin kopic
m: +44 (0)780 154 7643
t: +44 (0)20 7794 3090
e: benjamin.kopic@panContext.com
w: http://www.panContext.com/
--=-F+jv7/Vb+ANyLJCgCgkr-- From benjamin.kopic@panContext.com Mon Nov 10 09:24:09 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mta05.btfusion.com (mta05.btfusion.com [62.172.195.14]) by mail.gnome.org (Postfix) with ESMTP id C48A8181AB for ; Mon, 10 Nov 2003 09:24:08 -0500 (EST) Received: from [213.123.217.51] (helo=smee.pancontext.com) by mta05.btfusion.com with esmtp (Exim 4.24) id 1AJCxa-0003qa-RD for eog-list@gnome.org; Mon, 10 Nov 2003 14:24:07 +0000 Subject: "Unrecognized image file format" error when loading JPG file From: Benjamin Kopic To: eog-list@gnome.org Content-Type: multipart/alternative; boundary="=-59Cxtk8HcDNZEifFUZAC" Organization: panContext Message-Id: <1068473871.12408.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 14:17:52 +0000 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: --=-59Cxtk8HcDNZEifFUZAC Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, I am using Gnome 2.4 and keep getting the following error when trying to load any JPG file: Loading failed Loading of image BigBrother.jpg failed. Reason: Unrecognized image file format. However, I am able to load it using 'xloadimage' or analyse the files using 'jpeginfo' utility: benko@smee benko $ jpeginfo download/BigBrother.jpg download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) and then open it without any problem in 'eog'. The problem is only with JPG (JPEG) files, and I have not noticed any issues with other file types. I tried running 'eog' in a verbose/debug mode but could not found an option for it. Annoyingly, this used to work (in my Gnome 2.2), which stopped working when I updated one of my applications (not sure which one). I suspect it has something to do with MIME types or something, but I cannot find out what. As a result the problem is in all Gnome applications that display JPG files (except mozilla and epiphany). Any help is really appreciated. BTW, I am a Linux novice, so please bare that in mind when responding. Best regards, -- benjamin kopic m: +44 (0)780 154 7643 t: +44 (0)20 7794 3090 e: benjamin.kopic@panContext.com w: http://www.panContext.com/ --=-59Cxtk8HcDNZEifFUZAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I am using Gnome 2.4 and keep getting the following error when trying to load any JPG file:

Loading failed
Loading of image BigBrother.jpg failed.
Reason: Unrecognized image file format.

However, I am able to load it using 'xloadimage' or analyse the files using 'jpeginfo' utility:

benko@smee benko $ jpeginfo download/BigBrother.jpg
download/BigBrother.jpg  600 x 554  24bit JFIF  N   97033

Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) and then open it without any problem in 'eog'.

The problem is only with JPG (JPEG) files, and I have not noticed any issues with other file types. I tried running 'eog' in a verbose/debug mode but could not found an option for it.

Annoyingly, this used to work (in my Gnome 2.2), which stopped working when I updated one of my applications (not sure which one). I suspect it has something to do with MIME types or something, but I cannot find out what. As a result the problem is in all Gnome applications that display JPG files (except mozilla and epiphany).

Any help is really appreciated. BTW, I am a Linux novice, so please bare that in mind when responding.

Best regards,
-- 
benjamin kopic
m: +44 (0)780 154 7643
t: +44 (0)20 7794 3090
e: benjamin.kopic@panContext.com
w: http://www.panContext.com/
--=-59Cxtk8HcDNZEifFUZAC-- From jens@triq.net Mon Nov 10 13:21:56 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mail1.ewetel.de (mail1-106.ewetel.de [212.6.122.106]) by mail.gnome.org (Postfix) with ESMTP id 08CD918CB4 for ; Mon, 10 Nov 2003 13:21:56 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-67-160.ewetel.net [80.228.67.160]) by mail1.ewetel.de (8.12.1/8.12.9) with ESMTP id hAAILOIx005632; Mon, 10 Nov 2003 19:21:24 +0100 (MET) Date: Mon, 10 Nov 2003 19:26:54 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: Bryan W Clark Cc: eog-list@gnome.org Subject: Eog collection suggestions [was Re: [PATCH] EOG Collection] In-Reply-To: <1067569190.22999.71.camel@localhost> Message-ID: References: <1067376656.4775.162.camel@localhost> <3F9FB5D3.2010003@triq.net> <1067569190.22999.71.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hi Bryan, sorry for the delay in my reply (have been busy and then forgot about your mail :/) On Thu, 30 Oct 2003, Bryan W Clark wrote: > IMHO the idea of the collection viewer is to provide a filmstrip / > slideshow for the user. I think that in order to design for the > filmstrip model we can't providing a quick overview of all images at the > same time; the two design paradigms are mutually exclusive in our > current view. Actually I don't see a big problem here. Maybe we can change the behavior for the collection view to filmstrip mode, if it is used as nautilus view. > [...] > > > - With each saving of a jpeg the quality is reduced (lossy format). This > > can be avoided if libjpeg is used for lossless transformation of local > > jpeg files (which is planned). > > Ok, I wasn't aware of that. I'm sure you're almost all the way through > it, you've been making great progress so far. Once libjpeg is > incorporated I think an auto-save would _then_ be a good feature to > add. Hopefully we can work together on a good way to implement it. I don't have a clue how to integrate the libjpeg functionality into eog nicely yet. There is libeog/eog-image-jpeg.[ch] already, which provides the jpeg saveing functions only at the moment. This is probably the best place to add more jpeg specific image functions. > > - A nice thing in EoG is that you can rotate a large bunch of images in > > one run, while only the thumbnail representations are rotated. This is > > extremly fast and you get a quick overview if your transformation was > > right (eg. I always get horizontal/vertical flipping wrong). If an image is > - You can undo transformations, without touching the files again. > > I think this is a cool feature, but I wasn't aware of it until I dove > into the code. Yes, the documentation has definitely a lot room for improvements. Although there were some updates recently, haven't look at them yet. > jbut for this feature the usage group of people probably represent a > significantly small percent of the population of all our users. But I am in this 'small' group, so the feature will stay :). Maybe there is a way to make it more user visible, beside a better documentation. > Download new photos off their digital camera into directory "my trip" > Open up nautilus and navigate to "my trip" directory Now switch to > collection view so that they can show off the pictures from their trip > to everyone else, narrating each shot as it is in the preview window. > If they come across an image that is shot at a different rotation than > the others they would like to rotate it during their "mini-slideshow" > and not have to rotate it again when they leave the directory and open > it up again to show their pictures to someone else. Your use-case description makes sense. Though the argument of 'don't overwrite user-data silently' is a strong one. And eog shouldn't ask the user for each image seperately. Therefore I prefer the 'ask user to save modified images on exit' method. BTW: Eog remembers the transformation state during a session. If you load an image, rotate it, load another one and than later the first one again, eog will rotate it for you automatically. > To throw out an idea to solve the "rotated it the wrong way" situation, > we could try to implement a high feedback rotation system, similar to > what the new GIMP does does for image rotation. Yes, but than you don't have a stateless user interface anymore, which sucks IMO for a 'simple' image viewer. > I agree this is a problem, I'm on the GUP team and am working out a spec > to try to solve this right now. Do you have a link for more infos? Never heard of GUP team. > > - Eog can save only 'png' and 'jpeg' files. If you rotate eg. a gif file > > the automatic save will fail. > > I think this is a problem with the EOG save in general and not so much > with the auto-save idea, I'm sure we can fix this one as well with a > little hacking. Than, go ahead and add saving functionality for all kind of image types to gdk-pixbuf (where it belongs). Eog whill pickup these automatically. > > My idea for a better usability on this for 2.6 is: > > - Visually indicate that an image was modified > > - Select all modified images with one menu function > > - Ask the user on close if he want's to save the modifications if there > > are any. > > Take a look at the "rotate mode" idea or maybe you can elaborate a > little more on how this will work visually, as I can't see it. IMO this is pretty clear, what don't you understand here? > On close EOG asks the users "You've changed 'pict1454.jpg', do you want > to save?" And then again for every image other image that was rotated. > I couldn't identify any of the names my camera gives my images and I > don't rename them since I have too many to do that. I _can_ remember > which one I want to rotate when I'm looking at it and see that it's > wrong. Well, we can do it better. We have the thumbnails for all the images we are showing. So we can show the user the files which changed. Regards, Jens From jens@triq.net Mon Nov 10 13:38:53 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mail1.ewetel.de (mail1-106.ewetel.de [212.6.122.106]) by mail.gnome.org (Postfix) with ESMTP id AA01318184 for ; Mon, 10 Nov 2003 13:38:52 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-67-160.ewetel.net [80.228.67.160]) by mail1.ewetel.de (8.12.1/8.12.9) with ESMTP id hAAIcoIx013298; Mon, 10 Nov 2003 19:38:51 +0100 (MET) Date: Mon, 10 Nov 2003 19:44:20 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: Benjamin Kopic Cc: eog-list@gnome.org Subject: Re: "Unrecognized image file format" error when loading JPG file In-Reply-To: <1068473871.12408.24.camel@localhost> Message-ID: References: <1068473871.12408.24.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hi Benjamin, On Mon, 10 Nov 2003, Benjamin Kopic wrote: > I am using Gnome 2.4 and keep getting the following error when trying to > load any JPG file: > > Loading failed > Loading of image BigBrother.jpg failed. > Reason: Unrecognized image file format. > > However, I am able to load it using 'xloadimage' or analyse the files > using 'jpeginfo' utility: > > benko@smee benko $ jpeginfo download/BigBrother.jpg > download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 > > Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) > and then open it without any problem in 'eog'. > > The problem is only with JPG (JPEG) files, and I have not noticed any > issues with other file types. I tried running 'eog' in a verbose/debug > mode but could not found an option for it. > > Annoyingly, this used to work (in my Gnome 2.2), which stopped working > when I updated one of my applications (not sure which one). I suspect it > has something to do with MIME types or something, but I cannot find out > what. As a result the problem is in all Gnome applications that display > JPG files (except mozilla and epiphany). All Gnome programs use gdk-pixbuf as a graphic library for loading and saving image files. Since this happens in all Gnome programs for you (epiphany and mozilla both use other code for displaying images), it is very likely a bug in this basic library (which comes with GTK). Does it happen with all kind of jpeg files? This is a 24bit jpeg file, which may be the source of the problem. Anyway, could you attach a test file where it doesn't work to a bug in our bug tracking system at bugzilla.gnome.org? This would be very helpful. Thanks. Jens From clarkbw@clarkson.edu Mon Nov 10 17:34:26 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from bryan.clarkson.edu (bryan.sclab.clarkson.edu [128.153.144.201]) by mail.gnome.org (Postfix) with ESMTP id A3E9718F46 for ; Mon, 10 Nov 2003 17:34:26 -0500 (EST) Received: by bryan.clarkson.edu (Postfix, from userid 1000) id 2EEE538657F; Mon, 10 Nov 2003 17:34:24 -0500 (EST) Subject: Re: Eog collection suggestions [was Re: [PATCH] EOG Collection] From: Bryan W Clark To: eog-list@gnome.org In-Reply-To: References: <1067376656.4775.162.camel@localhost> <3F9FB5D3.2010003@triq.net> <1067569190.22999.71.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Clarkson Open Source Institute Message-Id: <1068503663.4368.190.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 17:34:24 -0500 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: Hey Jens ~ On Mon, 2003-11-10 at 13:26, Jens Finke wrote: > sorry for the delay in my reply (have been busy and then forgot about your > mail :/) no problem at all, thanks for taking the time to reply back to me. > On Thu, 30 Oct 2003, Bryan W Clark wrote: > > IMHO the idea of the collection viewer is to provide a filmstrip / > > slideshow for the user. I think that in order to design for the > > filmstrip model we can't providing a quick overview of all images at the > > same time; the two design paradigms are mutually exclusive in our > > current view. > > Actually I don't see a big problem here. Maybe we can change the > behavior for the collection view to filmstrip mode, if it is used as > nautilus view. Woah! I think you just turned everything I know upside down. All of my collection suggestions have been directed solely at the Nautilus view; I had no idea that you could open up directories in EOG by itself until a minute ago. That is really neat, but not the part I was after. :-) Consider everything I've suggested before and from here on to be only towards the Nautilus component _only_. I can see lots of value in keeping EOG feature rich and I would love to continue to help if you'd like; but my main concern was and is the Nautilus View component. > I don't have a clue how to integrate the libjpeg functionality into eog > nicely yet. There is libeog/eog-image-jpeg.[ch] already, which provides the > jpeg saveing functions only at the moment. This is probably the best place > to add more jpeg specific image functions. Hm, I don't know anything about this either. The best I can offer you is that I'll look and ask around for anyone with experience with this stuff so we could get it done right. > Yes, the documentation has definitely a lot room for improvements. > Although there were some updates recently, haven't look at them yet. It seems you have some great ideas towards making this piece easy to use without providing more docs for people to read. > But I am in this 'small' group, so the feature will stay :). Maybe there > is a way to make it more user visible, beside a better documentation. Totally agreed that this should stay. The user group who would take advantage of this are not to be trifle with :) Again, I think my only concern was for the Nautilus view; and if we make this the _only_ way to change images I can't figure a way to convey it to the user in an intuitive enough way that many people will take advantage of how cool this part really is. I'm at a brick wall of ideas to make this work so that people would just know what it's doing and how. My problem is that I'm stuck in this mental model for users [1] and maybe you can steer me to another one. The mental model that I see the user having is of a physical "photo album" or slide projector system. This is why I was thinking of the I change the rotation of the picture in the album/slides and it stays the way you last rotated it automatically (physical pictures tend to follow this property of Newtonian physics :). Without asking if you're sure afterwords. The one at a time viewing with knowing which picture is next comes from expanding the album idea as well. I'm interested in making the Nautilus View as simple as possible even if that means losing extra functionality (not that we rip the functions out, just that they aren't easy to get to from within nautilus). So if I'm way off on this, or you have a different user mental model I can stop crying about this. :) [...] > BTW: Eog remembers the transformation > state during a session. If you load an image, rotate it, load another one > and than later the first one again, eog will rotate it for you > automatically. Oh, cool stuff. I think I experienced the reset session after shutdown and open up again of EOG and so this didn't occur to me. > > To throw out an idea to solve the "rotated it the wrong way" situation, > > we could try to implement a high feedback rotation system, similar to > > what the new GIMP does does for image rotation. > > Yes, but than you don't have a stateless user interface anymore, which > sucks IMO for a 'simple' image viewer. Totally right, the idea is really overblown for the problem, just trying to throw out something new. > Do you have a link for more infos? Never heard of GUP team. Oh, GUP, I should have said the GNOME Usability Project, http://developer.gnome.org/projects/gup/ [....] > IMO this is pretty clear, what don't you understand here? I guess it just relates to the user mental model that I've constructed for this component. In the Nautilus view I think we're going to the least experienced people vs. the EOG view mode. In EOG what you are working towards feels like a file/photo manage type model which I don't think relates to people using the Nautilus view, but again this might not be the model you're working with and we're just missing something in the communication of these things. > Well, we can do it better. We have the thumbnails for all the images we > are showing. So we can show the user the files which changed. Definitely! Thanks for all your time, ~ Bryan [1] User Mental Models - Simply put is how users view what is actually being done vs. what is really going on behind the scenes. (example being, everyone knows how a T.V. works right? You turn it on and see shows, but no one wants to think about how the CRT actually draws on the screen, although things like the wonderfully outdated VHhold button had us scarily close to understanding the phase shifting that was going on. But T.V. designers have since dropped the VHHold button and other things because over time they knew that people just want to surf channels, not mess with the inner workings. ) -- Bryan W Clark Graduate Student Math && Computer Science Dept. Human Computer Interaction Group Clarkson University Potsdam, NY USA http://www.clarkson.edu/~clarkbw/ From benjamin.kopic@panContext.com Mon Nov 10 19:06:43 2003 Return-Path: Delivered-To: eog-list@gnome.org Received: from mta03.btfusion.com (mta03.btfusion.com [62.172.195.12]) by mail.gnome.org (Postfix) with ESMTP id 0B20C18103 for ; Mon, 10 Nov 2003 19:06:43 -0500 (EST) Received: from [213.123.217.51] (helo=smee.pancontext.com) by mta03.btfusion.com with esmtp (Exim 4.24) id 1AJM3N-0004sE-EQ for eog-list@gnome.org; Tue, 11 Nov 2003 00:06:41 +0000 Subject: Re: "Unrecognized image file format" error when loading JPG file From: Benjamin Kopic To: eog-list@gnome.org In-Reply-To: References: <1068473871.12408.24.camel@localhost> Content-Type: multipart/alternative; boundary="=-F+jv7/Vb+ANyLJCgCgkr" Organization: panContext Message-Id: <1068509200.4702.28.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 11 Nov 2003 00:06:41 +0000 Sender: eog-list-admin@gnome.org Errors-To: eog-list-admin@gnome.org X-BeenThere: eog-list@gnome.org X-Loop: eog-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Development of the Eye of Gnome application List-Unsubscribe: , List-Archive: --=-F+jv7/Vb+ANyLJCgCgkr Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Jens I just noticed something when I opened "Open file..." dialogue. In "Determine File Type:" combo list I do not have JPG file format (my default option is "By Extension"). Could this have anything to do with this? Also, I tried finding any 16 bit JPG files on the net to try and see if I can open them, but I could not find any (if you have one, could you please e-mail it to me). In addition, I have submitted this to bugzilla.gnome.org: BUG#126672 http://bugzilla.gnome.org/show_bug.cgi?id=126672 Best regards Ben On Mon, 2003-11-10 at 18:44, Jens Finke wrote: > Hi Benjamin, > > On Mon, 10 Nov 2003, Benjamin Kopic wrote: > > I am using Gnome 2.4 and keep getting the following error when trying to > > load any JPG file: > > > > Loading failed > > Loading of image BigBrother.jpg failed. > > Reason: Unrecognized image file format. > > > > However, I am able to load it using 'xloadimage' or analyse the files > > using 'jpeginfo' utility: > > > > benko@smee benko $ jpeginfo download/BigBrother.jpg > > download/BigBrother.jpg 600 x 554 24bit JFIF N 97033 > > > > Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility) > > and then open it without any problem in 'eog'. > > > > The problem is only with JPG (JPEG) files, and I have not noticed any > > issues with other file types. I tried running 'eog' in a verbose/debug > > mode but could not found an option for it. > > > > Annoyingly, this used to work (in my Gnome 2.2), which stopped working > > when I updated one of my applications (not sure which one). I suspect it > > has something to do with MIME types or something, but I cannot find out > > what. As a result the problem is in all Gnome applications that display > > JPG files (except mozilla and epiphany). > > All Gnome programs use gdk-pixbuf as a graphic library for loading and > saving image files. Since this happens in all Gnome programs for you > (epiphany and mozilla both use other code for displaying images), it is > very likely a bug in this basic library (which comes with GTK). > > Does it happen with all kind of jpeg files? This is a 24bit jpeg file, > which may be the source of the problem. Anyway, could you attach a test > file where it doesn't work to a bug in our bug tracking system at > bugzilla.gnome.org? This would be very helpful. Thanks. > > > Jens -- benjamin kopic m: +44 (0)780 154 7643 t: +44 (0)20 7794 3090 e: benjamin.kopic@panContext.com w: http://www.panContext.com/ --=-F+jv7/Vb+ANyLJCgCgkr Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Jens

I just noticed something when I opened "Open file..." dialogue. In "Determine File Type:" combo list I do not have JPG file format (my default option is "By Extension"). Could this have anything to do with this?

Also, I tried finding any 16 bit JPG files on the net to try and see if I can open them, but I could not find any (if you have one, could you please e-mail it to me).

In addition, I have submitted this to bugzilla.gnome.org: BUG#126672
http://bugzilla.gnome.org/show_bug.cgi?id=126672

Best regards

Ben

On Mon, 2003-11-10 at 18:44, Jens Finke wrote: 
Hi Benjamin,

On Mon, 10 Nov 2003, Benjamin Kopic wrote:
> I am using Gnome 2.4 and keep getting the following error when trying to
> load any JPG file:
> 
> Loading failed
> Loading of image BigBrother.jpg failed.
> Reason: Unrecognized image file format.
> 
> However, I am able to load it using 'xloadimage' or analyse the files
> using 'jpeginfo' utility:
> 
> benko@smee benko $ jpeginfo download/BigBrother.jpg 
> download/BigBrother.jpg  600 x 554  24bit JFIF  N   97033 
> 
> Also, I can convert the JPG file into PNG (using 'jpegtopnm' utility)
> and then open it without any problem in 'eog'.
> 
> The problem is only with JPG (JPEG) files, and I have not noticed any
> issues with other file types. I tried running 'eog' in a verbose/debug
> mode but could not found an option for it.
> 
> Annoyingly, this used to work (in my Gnome 2.2), which stopped working
> when I updated one of my applications (not sure which one). I suspect it
> has something to do with MIME types or something, but I cannot find out
> what. As a result the problem is in all Gnome applications that display
> JPG files (except mozilla and epiphany).

All Gnome programs use gdk-pixbuf as a graphic library for loading and
saving image files. Since this happens in all Gnome programs for you
(epiphany and mozilla both use other code for displaying images), it is
very likely a bug in this basic library (which comes with GTK).

Does it happen with all kind of jpeg files? This is a 24bit jpeg file, 
which may be the source of the problem. Anyway, could you attach a test 
file where it doesn't work to a bug in our bug tracking system at 
bugzilla.gnome.org? This would be very helpful. Thanks.


   Jens





-- 
benjamin kopic
m: +44 (0)780 154 7643
t: +44 (0)20 7794 3090
e: benjamin.kopic@panContext.com
w: http://www.panContext.com/
--=-F+jv7/Vb+ANyLJCgCgkr--