After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 118262 - support inline photoshop jpeg thumbnails?
support inline photoshop jpeg thumbnails?
Status: RESOLVED DUPLICATE of bug 56443
Product: GIMP
Classification: Other
Component: Plugins
1.x
Other Linux
: Normal enhancement
: 2.0
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks: 118202
 
 
Reported: 2003-07-25 06:30 UTC by Jamie Zawinski
Modified: 2003-08-25 09:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Photoshop JPEG which contains an inline thumbnail (66.08 KB, image/jpeg)
2003-07-25 06:32 UTC, Jamie Zawinski
Details

Description Jamie Zawinski 2003-07-25 06:30:36 UTC
So, I recently saw this page:
http://www.shackspace.com/~mcbiggins@shackmail.com/cat.html
which describes how some girl posted cropped JPEGs of herself to her
web site, and someone else managed to extract the Photoshop-written
thumbnails out of them, which show the un-cropped image in which you
can see her boobs.

Now, I think that's pretty funny, in a middle-school kind of way, but
that's not the point.

The point is, JPEGs written by Photoshop have thumbnails in them --
and GIMP does not display them, since (as far as I can tell) GIMP
uses on the .xvpics version.  (Right?)

So, it would be nice if

   1)  gimp would display the thumbnails that are in the JPEG
   2)  gimp would save thumbnails into JPEGs, instead of / in addition
       to using the .xvpics directory;

and maybe even:

   3)  provide the ability to extract the thumbs themselves (present
       as a special layer?)

From looking at the raw file data, it looks to me like one of these
is the thumbnail:

    Miscellaneous marker 0xe1, length 6531
    Miscellaneous marker 0xed, length 7204

There's a second JFIF embedded in there, but doing the obvious thing
and hacking off the part of the file before it doesn't cause it to be
readable -- so perhaps it's in some strange or custom JPEG format that
only Photoshop knows about?  I did some searching and wasn't able to
find any documentation on what kinds of stuff Photoshop puts there.

What do you think?
Comment 1 Jamie Zawinski 2003-07-25 06:32:24 UTC
Created attachment 18588 [details]
Photoshop JPEG which contains an inline thumbnail
Comment 2 Maurits Rijk 2003-07-25 06:41:12 UTC
> What do you think?

She has nice boobs.. uhh.. I mean, this sounds like a enhancement, so
I'm changing the Severity and set the Milestone to future. You are
asking for 3 seperate things, so this report should be split-up.
Comment 3 Dave Neary 2003-07-25 07:55:49 UTC
Adding this to the metadata tracking bug - the thumbnail looks to me
like it's probably a standard exif thumbnail. I will check with
libexif to see what I get out of it... gphoto could probably do the
same thing.

If it is, then we're already saving the thumbnail unchanged in the
latest 1.3 builds, but we haven't been creating a metadata block to
add to the image at save time for images that don't have it. I kind of
agree with the Future though - doesn't look like it'll be done for a
few months. 

That said, not that much work would be needed for this, if it is an
exif thumbnail, and we could consider this for 1.3.x. I'll report back.

Dave.
Comment 4 Sven Neumann 2003-07-25 09:00:59 UTC
Just FYI, GIMP-1.3 doesn't use the .xvpics format for thumbnails any
longer. Instead it implements
http://triq.net/~jens/thumbnail-spec/index.html
Comment 5 Dave Neary 2003-07-25 11:20:09 UTC
Confirmed that this is a standard exif thumbnail. So we already do
what photoshop does and keep an unaltered copy when the jpeg plug-in
is linked against libexif. Just the thumbnail can be extracted using
exif -e cat.jpeg. 

So do we want to create an exif header when saving to jpeg if one
doesn't already exist? If so, what do we put in it? 

This is something which could be addressed as part of general exif
support, or at a very basic level it could be treated separately (as I
say, create an exif header with just a thumbnail, and throw it into
the jpeg) - this would in fact be very easy. Since the easy thing is
probably grand, I'll target this for 1.3.

And this time I'm *really* adding this to the metadata tracking bug.

Dave.
Comment 6 Dave Neary 2003-07-25 20:42:31 UTC
In terms of the original 1,2,3 I think that it would be possible o
extract the thumbnail (very easily), but displaying it nicely is
probably not that easy (simply put, I don't see how to display a
thumbnail except as we now do, when loading an image), and we can save
thumbs into the jpeg. 

But after extracting the thumbnail, what do we do with it?

Cheers,
Dave.
Comment 7 Dave Neary 2003-07-26 20:46:02 UTC
I think we address the most important part of this - we don't destroy
the thumbnail. I don't think we should start writing exif headers. I
don't think we should use possibly out-of-date thumbnails stored in
exif  rather than generating up-to-date thumbnails. Even if they are
of attractive women topless.

So I'm in favour of resolving this as a duplicate of the exif bug and
be done with it.

Dave.

*** This bug has been marked as a duplicate of 56443 ***
Comment 8 Tomas Mraz 2003-07-26 21:17:23 UTC
Heh the support of saving unchanged exif is then actually a security
problem. :-)
I'll open a new bug for it.
Comment 9 Raphaël Quinet 2003-08-25 09:27:47 UTC
Cross-reference: the "security issue" is tracked in bug #118384.