shotwell issueshttps://gitlab.gnome.org/GNOME/shotwell/-/issues2021-05-19T13:50:45Zhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/4256Thumbnails are colored purple2021-05-19T13:50:45ZBugzillaThumbnails are colored purple## Submitted by an unknown user
**[Link to original bug (#719126)](https://bugzilla.gnome.org/show_bug.cgi?id=719126)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2013-10-05 04:31:00 -0700 ----
Original Redmine bu...## Submitted by an unknown user
**[Link to original bug (#719126)](https://bugzilla.gnome.org/show_bug.cgi?id=719126)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2013-10-05 04:31:00 -0700 ----
Original Redmine bug id: 7596
Original URL: http://redmine.yorba.org/issues/7596
Searchable id: yorba-bug-7596
Original author: Tobias Eitel
Original description:
Most of the thumbnails in the main window have a strange purple color
distortion (see attached file) . This happens immediately after importing
images from a harddisk folder via linking. The images have not been opened by
any other software. The files in the imported directory are ... IMG_0613.CR2
IMG_0613.JPG ...
For every .jpg there's also a raw file. I see no obvious difference between
images that are correctly displayed and the purple ones. When I change to
full-window mode, all images are displayed correctly. This affects only the
thumbnails, but it is a big annoyance since I cannot really use the preview
any more.
---- Additional Comments From shotwell-maint@gnome.bugs 2013-11-13 17:26:00 -0800 ----
### History
---
Comment 1
Updated by Jim Nelson about 1 month ago
* **Status** changed from _Open_ to _Need Information_
What version of Shotwell are you using? Can you tell us what version of LibRaw
are you using? And, what camera make and model produced your CR2's?
---
Comment 2
Updated by Tobias Eitel about 1 month ago
0.14.1 from the repository. OS is Ubuntu 12.04
libraw5 0.14.4-0ubuntu2.2
Camera Canon EOS 700D
---
Comment 3
Updated by Jim Nelson about 1 month ago
What is your RAW Developer setting? If you click on one of the affected photos
and select Photos -> RAW Developer, which is selected, Shotwell or Camera? I
suspect it's Shotwell. Try setting it to Camera.
If that works, you'll need to do that for all affected photos. (You can select
multiple photos and do the operation all at once.) To make future imported
photos work that way, go to Edit -> Preferences -> RAW Developer.
---
Comment 4
Updated by Tobias Eitel about 1 month ago
* **File** 28.png added
* **File** 40.png added
In the general settings it's set to camera (see attached screen shot). In the
picture's context menu nothing is selected, but in the image info at the
bottom left you can see it's also set to camera (second screen shot).
---
Comment 5
Updated by Jim Nelson about 1 month ago
In that case, I wonder if there's a usable JPEG available inside the RAW file.
If not, Shotwell has to fall back on its own developer, which may produce
these results. Or, your camera has RAW+JPEG available but Shotwell is not
finding the paired JPEG due to its filename. So, are you using RAW+JPEG? If
so, what do the filenames look like?
If not, can you send the RAW file to shotwell@yorba.org? I can take a look and
potentially see what the problem is.
---
Comment 6
Updated by Tobias Eitel about 1 month ago
I use RAW+JPEG. In the folder there are two separate files: IMG_0608.CR2 and
IMG_0608.JPG
Please note that only the thumbnails are affected. As stated above: When I
change to full-window mode, all images are displayed correctly. Let me know,
if you want some sample files.
---
Comment 7
Updated by Jim Nelson about 1 month ago
If you could send a RAW+JPEG pair to shotwell@yorba.org, that would help us
see what the problem is here.
---
Comment 8
Updated by Tobias Eitel about 1 month ago
Here are the files:
https://www.dropbox.com/s/vxgh2esa99ktsix/IMG_0608.CR2
https://www.dropbox.com/s/c0ds4t5nicrtnzw/IMG_0608.JPG
---
Comment 9
Updated by Jim Nelson 29 days ago
If I import these at the same time or just the RAW file, I see the purple
coloration. But if I switch the Developer to Camera, they look fine. Be sure
you're doing this:
* Single-click on the photo(s)
* Right-click to bring up the context menu
* Choose Developer -> Camera
Does that fix your problem?
---
Comment 10
Updated by Tobias Eitel 25 days ago
When I tried
* Single-click on the photo(s)
* Right-click to bring up the context menu
* Choose Developer -> Camera
nothing happened.
I then tried
* Single-click on the photo(s)
* Right-click to bring up the context menu
* Choose Developer -> Shotwell
* Right-click to bring up the context menu
* Choose Developer -> Camera
After this the image color is ok. I can also select more than one picture at
the same time.
So the developer setting http://redmine.yorba.org/issues/7596#note-5 only
works after changing to shotwell and then back to camera.
---
Comment 11
Updated by Jim Nelson 24 days ago
I can't reproduce that, however, what you're describing is a problem that
should've been fixed in 0.14. I'm curious if you're still seeing the problem
in anothet form, although I can't get Shotwell to act the way you describe.
With the RAW Developer set to Camera in Preferences, if you import a new photo
do you see the same problem? Or does it work then?
---
Comment 12
Updated by Tobias Eitel 20 days ago
* **File** _18.png_ added
I tried everything as you described.
- set RAW developer to Camera
- import 6 new images
- three of them are purple (see attached screenshot)
---
Comment 13
Updated by Tobias Eitel 20 days ago
* **File** deleted (`<strike>`_18.png_`</strike>`)
---
Comment 14
Updated by Tobias Eitel 20 days ago
* **File** 18.png added
---
Comment 15
Updated by Jim Nelson 8 days ago
* **Status** changed from _Need Information_ to _Open_
The only other thing I can suggest is to check that the settings are correct
in dconf-editor at **org.yorba.shotwell.preferences.files.raw-developer-
default**. The setting there should match the setting in Shotwell.
---
Comment 16
Updated by Jim Nelson 8 days ago
* **Category** set to _raw_
--- Bug imported by chaz@yorba.org 2013-11-25 21:59 UTC ---
This bug was previously known as _bug_ 7596 at http://redmine.yorba.org/show_bug.cgi?id=7596
Imported an attachment (id=262702)
Imported an attachment (id=262703)
Imported an attachment (id=262704)
Imported an attachment (id=262705)
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/4287Shotwell doesn't re-import the RAW files I deleted2021-05-19T13:52:06ZBugzillaShotwell doesn't re-import the RAW files I deleted## Submitted by an unknown user
**[Link to original bug (#719157)](https://bugzilla.gnome.org/show_bug.cgi?id=719157)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2013-08-29 11:32:00 -0700 ----
Original Redmine bu...## Submitted by an unknown user
**[Link to original bug (#719157)](https://bugzilla.gnome.org/show_bug.cgi?id=719157)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2013-08-29 11:32:00 -0700 ----
Original Redmine bug id: 7415
Original URL: http://redmine.yorba.org/issues/7415
Searchable id: yorba-bug-7415
Original author: Kevin Brubeck Unhammer
Original description:
To reproduce:
1. import some RAW+JPEG files
2. delete the newly imported folder using your file manager
4. restart shotwell
5. try importing again (with hide already imported ticked)
6. see shotwell import JPEGs and ignore CR2's
This seems like a rather dangerous bug since it means I might delete the
memory card thinking I've successfully gotten back my RAW files when I
haven't.
---- Additional Comments From shotwell-maint@gnome.bugs 2013-09-03 16:28:00 -0700 ----
### History
---
Comment 1
Updated by Kevin Brubeck Unhammer 3 months ago
Tested on 0.14.1-0ubuntu1 (13.04 raring).
---
Comment 2
Updated by Jim Nelson 3 months ago
* **Category** set to _raw_
* **Priority** changed from _Normal_ to _High_
--- Bug imported by chaz@yorba.org 2013-11-25 22:00 UTC ---
This bug was previously known as _bug_ 7415 at http://redmine.yorba.org/show_bug.cgi?id=7415
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/4102Can't get original dimensions of RAW image2021-05-19T13:44:06ZBugzillaCan't get original dimensions of RAW image## Submitted by Lucas Beeler
**[Link to original bug (#718971)](https://bugzilla.gnome.org/show_bug.cgi?id=718971)**
## Description
---- Reported by lucas@yorba.org 2013-03-15 13:11:00 -0700 ----
Original Redmine bug id: 6585
...## Submitted by Lucas Beeler
**[Link to original bug (#718971)](https://bugzilla.gnome.org/show_bug.cgi?id=718971)**
## Description
---- Reported by lucas@yorba.org 2013-03-15 13:11:00 -0700 ----
Original Redmine bug id: 6585
Original URL: http://redmine.yorba.org/issues/6585
Searchable id: yorba-bug-6585
Original author: Lucas Beeler
Original description:
Steps to reproduce:
Open the Extended Information pane and note that the "Original Dimensions:"
field of some RAW images is blank. This isn't right. Photos should always have
an original dimension. I'm emailing a photo that exhibits this problem to
shotwell@yorba.org now...
Related issues:
* related to shotwell - 6594: [interim] Don't use embedded camera preview
JPEG if it's ... (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-10-13 07:34:00 -0700 ----
### History
---
Comment 1
Updated by Clinton Rogers 8 months ago
* **Status** changed from _Open_ to _Review_
Part one - fall back to the pixbuf dimensions if there's absolutely nothing
else.
As for part two, it looks like the image in question lists its real size in
the fields `Exif.SubImage2.ImageWidth` and `Exif.SubImage2.ImageLength`;
getting guidance from team lead about how to proceed.
---
Comment 2
Updated by Clinton Rogers 8 months ago
* **Status** changed from _Review_ to _Open_
We're rejecting - the right way to fix this is #6594.
---
Comment 3
Updated by Jim Nelson 8 months ago
* **Assignee** deleted (`<strike>`_Clinton Rogers_`</strike>`)
---
Comment 4
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.14.0_ to _0.15.0_
---
Comment 5
Updated by Jim Nelson 8 months ago
* **Assignee** set to _Clinton Rogers_
#6594 is fixed now -- does that fix this as well, Clinton?
---
Comment 6
Updated by Clinton Rogers 8 months ago
@Jim - not quite; there are some raw files whose true width and height aren't
found in the usual spot (and, unfortunately, but perhaps predictably, this
differs by manufacturer), and they either leave the fields we use for this
unset, or put the size of the (first) preview there, so even with that fix in
place, while the image will still display correctly, the fields will either be
wrong or won't contain anything meaningful.
---
Comment 7
Updated by Jim Nelson 7 months ago
* **Assignee** deleted (`<strike>`_Clinton Rogers_`</strike>`)
The Original Dimensions are supposed to be the dimensions of the baseline
image (rotated but otherwise untransformed), and so in the case of RAW this
should be the developed image. That means this value can change when the
developer changes.
As a rule, we should never be using dimensions from the metadata unless we're
explicitly displaying them as metadata from the EXIF/IPTC/XMP/etc.
---
Comment 8
Updated by Jim Nelson 6 months ago
* **Target version** deleted (`<strike>`_0.15.0_`</strike>`)
---
Comment 9
Updated by Joe Bylund about 1 month ago
Jim,
I'm confused on this one. In my mind original dimensions of a raw image are
the full resolution image, rotated. Shouldn't that mean the camera & Shotwell
developer give the same dimensions, which would also be equal to the
width/height from the exif of the raw?
-Joe
---
Comment 10
Updated by Jim Nelson about 1 month ago
There's a couple of issues at play.
First, metadata is easily manipulated by applications. We learned early on
that some programs would alter these values in bad ways. We've also seen
cameras not properly write metadata values out (although I don't think we've
ever seen dimensions wrongly encoded.) The point is, we decided early on in
Shotwell's development to treat metadata like user input, that is, with a bit
of distrust. That's why we shouldn't use the metadata dimensions but rather
store in the database the actual decoded dimensions and display that.
Second, with RAW, there are 2 - 3 "actual" dimensions, which confuses things
further. The RAW-raw image (the pixels stored straight from the CCD) have
"bleed-over" border pixels that may be cropped off by the camera when
developing its JPEG. Cameras may not store a full-sized development inside the
RAW image. There's also optimizations with JPEG that can be obtained by using
pixel dimensions that are a factor of some power of 2 (I think 8) that cameras
may use; either one of these will yield dimensions different than the RAW-raw
image. And there's no guarantee that LibRaw will trim off the same border
pixels as any particular camera. That's why we have potentially three
different dimensions for a RAW image.
That's why we need to show the untransformed-but-rotated dimensions of the
developed image (which may change based on the developer) and can't use the
metadata values.
I realize this complicates what should be a simple issue, but RAW throws a lot
of monkey wrenches into photo management, and this is one of them.
--- Bug imported by chaz@yorba.org 2013-11-25 21:59 UTC ---
This bug was previously known as _bug_ 6585 at http://redmine.yorba.org/show_bug.cgi?id=6585
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolution
CC member joseph.bylund+shotwell@gmail.com does not have an account herehttps://gitlab.gnome.org/GNOME/shotwell/-/issues/4125[norepro] When RAW developer is set to Camera, Shotwell-developed thumbnails ...2021-05-19T13:45:12ZBugzilla[norepro] When RAW developer is set to Camera, Shotwell-developed thumbnails are used on new filesystem imports## Submitted by Lucas Beeler
**[Link to original bug (#718994)](https://bugzilla.gnome.org/show_bug.cgi?id=718994)**
## Description
---- Reported by lucas@yorba.org 2013-03-08 17:38:00 -0800 ----
Original Redmine bug id: 6501
...## Submitted by Lucas Beeler
**[Link to original bug (#718994)](https://bugzilla.gnome.org/show_bug.cgi?id=718994)**
## Description
---- Reported by lucas@yorba.org 2013-03-08 17:38:00 -0800 ----
Original Redmine bug id: 6501
Original URL: http://redmine.yorba.org/issues/6501
Searchable id: yorba-bug-6501
Original author: Lucas Beeler
Original description:
None
Related issues:
* related to shotwell - 6502: [norepro] RAW thumbnails are improperly
rotated when swit... (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
### History
---
Comment 1
Updated by Clinton Rogers 8 months ago
* **Subject** changed from _When RAW developer is set to Camera, Shotwell-developed thumbnails are used on new filesystem imports_ to _[norepro] When RAW developer is set to Camera, Shotwell-developed thumbnails are used on new filesystem imports_
* **Assignee** deleted (`<strike>`_Clinton Rogers_`</strike>`)
This has been seen by at least two Yorbans, but, unfortunately, we don't have
a solid repro path for it, and there are more-serious bugs that deserve
attention prior to releasing 0.14.
Unassigning for now with the understanding that we'll pick it back up if
someone can reliably trigger it.
---
Comment 2
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.14.0_ to _0.15.0_
---
Comment 3
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.15.0_ to _0.16.0_
---
Comment 4
Updated by Jim Nelson 6 months ago
* **Target version** deleted (`<strike>`_0.16.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-25 21:59 UTC ---
This bug was previously known as _bug_ 6501 at http://redmine.yorba.org/show_bug.cgi?id=6501
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/4169Multiple RAW development presets2021-05-19T13:47:04ZBugzillaMultiple RAW development presets## Submitted by Eric Gregory
**[Link to original bug (#719038)](https://bugzilla.gnome.org/show_bug.cgi?id=719038)**
## Description
---- Reported by eric@yorba.org 2013-02-15 11:45:00 -0800 ----
Original Redmine bug id: 6391
O...## Submitted by Eric Gregory
**[Link to original bug (#719038)](https://bugzilla.gnome.org/show_bug.cgi?id=719038)**
## Description
---- Reported by eric@yorba.org 2013-02-15 11:45:00 -0800 ----
Original Redmine bug id: 6391
Original URL: http://redmine.yorba.org/issues/6391
Searchable id: yorba-bug-6391
Original author: Eric Gregory
Original description:
This one comes from an [Ubuntu Forums
post](http://ubuntuforums.org/showpost.php?p=12510763&postcount=9)
> A simplified toolset would be welcomed. Picasa does a good job here. Where
multiple previews let you shoose the result you want. If anyone needs more
they will use the specialist tools anyway.
In other words we could offer, let's say six different RAW developments for a
photo, each with different parameters. The user would simply click the one
they like most and Shotwell will set it as the development for that photo.
Related issues:
* related to shotwell - Feature #3061: improve interaction with external RAW
editors (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-02-15 14:58:00 -0800 ----
### History
---
Comment 1
Updated by Jim Nelson 9 months ago
One possibility we discussed here is to improve the way JPEGs developed by
external editors are associated with the original RAW file (#3061), possibly
by means of plugins to deal with each particular RAW editor. Then, this ticket
could be solved by a separate app that works as specified that's launched from
Shotwell.
--- Bug imported by chaz@yorba.org 2013-11-25 21:59 UTC ---
This bug was previously known as _bug_ 6391 at http://redmine.yorba.org/show_bug.cgi?id=6391
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/4203Suggestion: develop camera-raw images at import time, rather than first photo...2021-05-19T13:48:26ZBugzillaSuggestion: develop camera-raw images at import time, rather than first photo page view.## Submitted by cli..@..ba.org
**[Link to original bug (#719072)](https://bugzilla.gnome.org/show_bug.cgi?id=719072)**
## Description
---- Reported by clinton@yorba.org 2013-01-23 12:16:00 -0800 ----
Original Redmine bug id: 625...## Submitted by cli..@..ba.org
**[Link to original bug (#719072)](https://bugzilla.gnome.org/show_bug.cgi?id=719072)**
## Description
---- Reported by clinton@yorba.org 2013-01-23 12:16:00 -0800 ----
Original Redmine bug id: 6254
Original URL: http://redmine.yorba.org/issues/6254
Searchable id: yorba-bug-6254
Original author: Clinton Rogers
Original description:
A mailing list user has suggested that it might enhance the user experience if
we develop raw images at import time, rather than the first time they're
viewed; on many computers, the developed .jpeg takes significant time to
produce, making navigating quickly through one's library somewhat unpleasant.
Tentatively marking as 0.15.
Related issues:
* related to shotwell - 4702: use Camera developer by default (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
### History
---
Comment 1
Updated by Eric Gregory 10 months ago
This is exactly what Shotwell _used_ to do -- we changed it to develop at
viewing time because people who shoot in RAW complained about waiting several
hours for an import to complete.
---
Comment 2
Updated by Eric Gregory 10 months ago
Also see: http://askubuntu.com/questions/243823/shotwell-develop-raw-files-on-
import/
---
Comment 3
Updated by Clinton Rogers 10 months ago
The mailing list request that sparked the discussion can be found
[here](http://lists.yorba.org/pipermail/shotwell/2013-January/004462.html) .
Maybe the way forward would be to default to the current behaviour, but allow
the user to specifically ask for it to happen at import time via a GSettings
key.
---
Comment 4
Updated by Jim Nelson 10 months ago
I'm opposed to using a gsettings key. Hidden or "advanced" config settings
lead to untested code. Plus, my guess is that someone who wants this feature
and turns it on will regret it if they ever import 1000 RAW files.
We went this route originally and users complained, so I'm not inclined to go
back. The only alternative I can come up with is to have something akin to the
metadata writer that, in the background, detects undeveloped RAW photos and
develops them. Eric, since you worked on this in the past, does this seem
reasonable? Was this an avenue you considered before?
---
Comment 5
Updated by Eric Gregory 10 months ago
Doing the writing in the background could work, as long as it didn't slow the
machine down too much. I don't think we considered that when we delved into
RAW many moons ago.
I'd wonder if simply making the camera developer the default would satisfy
most people here.
---
Comment 6
Updated by Jim Nelson 10 months ago
It might, that's something else we should keep in mind here.
---
Comment 7
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.15.0_ to _0.16.0_
---
Comment 8
Updated by Jim Nelson 6 months ago
* **Target version** deleted (`<strike>`_0.16.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-25 21:59 UTC ---
This bug was previously known as _bug_ 6254 at http://redmine.yorba.org/show_bug.cgi?id=6254
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3862Excessive memory use on changing developer2023-10-28T03:06:42ZBugzillaExcessive memory use on changing developer## Submitted by Charles Lindsay
**[Link to original bug (#718728)](https://bugzilla.gnome.org/show_bug.cgi?id=718728)**
## Description
---- Reported by joseph.bylund+shotwell@gmail.com 2012-12-03 15:26:00 -0800 ----
Original Red...## Submitted by Charles Lindsay
**[Link to original bug (#718728)](https://bugzilla.gnome.org/show_bug.cgi?id=718728)**
## Description
---- Reported by joseph.bylund+shotwell@gmail.com 2012-12-03 15:26:00 -0800 ----
Original Redmine bug id: 6118
Original URL: http://redmine.yorba.org/issues/6118
Searchable id: yorba-bug-6118
Original author: Joe Bylund
Original description:
Changing the developer for a large number of files (shotwell->camera)
simultaneously will cause excessive memory use ending in swap death.
To reproduce: Starting with a large photo library (mine is 10k+) select all
raw photos and change developer. Follow progress in top in another terminal.
Related issues:
* related to shotwell - 3586: RAW thumbnail generation is CPU intensive (Open)
* related to shotwell - 1856: System sluggish during a drag-and-drop RAW
import (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson 12 months ago
* **Priority** changed from _Normal_ to _High_
* **Target version** set to _0.14.0_
---
Comment 2
Updated by Jim Nelson 12 months ago
We'll look at this as part of our RAW effort for 0.14.
---
Comment 3
Updated by Jim Nelson 11 months ago
* **Category** set to _raw_
---
Comment 4
Updated by Jim Nelson 11 months ago
* **Priority** changed from _High_ to _Normal_
If we fix this, it might concievably fix #3586.
---
Comment 5
Updated by Jim Nelson 10 months ago
* **Target version** changed from _0.14.0_ to _0.15.0_
---
Comment 6
Updated by Jim Nelson 10 months ago
This may be a duplicate of #1856.
---
Comment 7
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.15.0_ to _0.16.0_
---
Comment 8
Updated by Jim Nelson 6 months ago
* **Target version** deleted (`<strike>`_0.16.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-25 21:58 UTC ---
This bug was previously known as _bug_ 6118 at http://redmine.yorba.org/show_bug.cgi?id=6118
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
The original reporter of this bug does not have
an account here. Reassigning to the person who moved
it here: chaz@yorba.org.
Previous reporter was joseph.bylund+shotwell@gmail.com.
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3716Shotwell developer makes monochrome photos appear in color2021-05-19T13:28:26ZBugzillaShotwell developer makes monochrome photos appear in color## Submitted by an unknown user
**[Link to original bug (#718580)](https://bugzilla.gnome.org/show_bug.cgi?id=718580)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2012-05-27 01:43:00 -0700 ----
Original Redmine bu...## Submitted by an unknown user
**[Link to original bug (#718580)](https://bugzilla.gnome.org/show_bug.cgi?id=718580)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2012-05-27 01:43:00 -0700 ----
Original Redmine bug id: 5311
Original URL: http://redmine.yorba.org/issues/5311
Searchable id: yorba-bug-5311
Original author: Hermann Detz
Original description:
When developing images with the shotwell developer instead of the camera
developer, photos taken as monochrome suddenly appear in color.
This is (at least) affecting Canon raw (.CR2) files.
---- Additional Comments From shotwell-maint@gnome.bugs 2012-05-28 13:32:00 -0700 ----
### History
---
Comment 1
Updated by Adam Dingle over 1 year ago
* **Priority** changed from _Normal_ to _High_
---
Comment 2
Updated by Lucas Beeler over 1 year ago
This is really a special case of #5316 or #1624. Since RAW, by definition, is
a dump of raw CCD data, it's unlikely that even if one's camera has been
configured to shoot in monochrome mode that the RAW image data is affected by
this setting. Either the camera (or manufacturer-provided photo import
software) can easily apply the desaturation transformation to the JPEG, but
since RAW image data is supposed to be kept pristine, it's unlikely that color
data is ever removed from the CCD dump in a RAW file. There may be special
metainformation in the photo itself or in a sidecar file that flags a photo as
being in monochrome, and we could respect this in Shotwell by running a full
de-saturate on the photo when we display it, but as per #1624, this should
really be done in 16-bits to preserve as much of the original image data as
possible.
I know the above discussion is breezy, but what I wanted to convey here is
that fixing this case isn't simple and, in my opinion, should be considered as
part of the overall problem of expanding RAW support in Shotwell.
--- Bug imported by chaz@yorba.org 2013-11-25 21:57 UTC ---
This bug was previously known as _bug_ 5311 at http://redmine.yorba.org/show_bug.cgi?id=5311
Unknown Component
Using default product and component set in Parameters
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3470CHDK-based RAW images not detected and paired2021-05-19T13:19:03ZBugzillaCHDK-based RAW images not detected and paired## Submitted by an unknown user
**[Link to original bug (#718330)](https://bugzilla.gnome.org/show_bug.cgi?id=718330)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2012-03-25 10:18:00 -0700 ----
Original Redmine bu...## Submitted by an unknown user
**[Link to original bug (#718330)](https://bugzilla.gnome.org/show_bug.cgi?id=718330)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2012-03-25 10:18:00 -0700 ----
Original Redmine bug id: 4916
Original URL: http://redmine.yorba.org/issues/4916
Searchable id: yorba-bug-4916
Original author: Jeremy Nickurak
Original description:
I'm using a Canon digital camera with CHDK, which enables the camera to shoot
with RAW. Unfortunately, Shotwell doesn't seem to pick up on the fact that
there are JPG/RAW pairs.
Since the raw is too big to attach here, please see: http://nickurak.ca/~atrus
/shotwell-crw-pair/ for an example pair of images.
Related issues:
* related to shotwell - Feature #4040: combine/separate RAW+JPEG photos (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
### History
---
Comment 1
Updated by Adam Dingle over 1 year ago
* **Priority** changed from _Normal_ to _High_
---
Comment 2
Updated by Eric Gregory over 1 year ago
Normally when you have a RAW+JPEG pair, only the extensions of the file name
differ. But not so in this case, which explains why Shotwell's import
mechanism doesn't pair them.
---
Comment 3
Updated by Jeremy Nickurak over 1 year ago
Interesting. Per http://chdk.wikia.com/wiki/CHDK_User_Manual , this is
configurable on my side.
Do you know if renaming them in place will cause Shotwell to notice the
changes in past imports?
---
Comment 4
Updated by Eric Gregory over 1 year ago
A-ha! Interesting find. Also, you'll need to make sure "RAW File in Dir with
JPEG" is enabled, though it appears that's the default.
Are other photo managers able to pair your RAW+JPEG photos with your current
settings? If so, I wonder how they're able to do it...
---
Comment 5
Updated by Jeremy Nickurak over 1 year ago
Never used anything else with RAW support, so I couldn't say :)
---
Comment 6
Updated by Adam Dingle over 1 year ago
Jeremy: renaming the files in place will not cause Shotwell to associate the
photos as RAW+JPEG pairs. Shotwell currently isn't super flexible in this
regard. We hope to improve the situation in future releases; see #4040, for
example.
---
Comment 7
Updated by Jeremy Nickurak over 1 year ago
I can confirm that this works correctly when I change the prefix, for new
files at least. I'll watch 4040 :)
---
Comment 8
Updated by Jim Nelson 11 months ago
* **Target version** set to _0.14.0_
---
Comment 9
Updated by Jim Nelson 11 months ago
* **Category** set to _raw_
---
Comment 10
Updated by Jim Nelson 11 months ago
* **Status** changed from _Open_ to _Need Information_
Jeremy, the link you provided is now 404. Could you (or anyone interested in
this ticket) supply us with a couple of CHDK+JPEG pairs to test with, or point
us to a web site with some? I've looked and can't find any with the CHDK
files, only JPEGs.
---
Comment 11
Updated by Joe Bylund 10 months ago
I've put a pair at: http://www.columbia.edu/~jhb2147/shotwell/issue_4916/
(obviously let me know if you have any issues accessing)
---
Comment 12
Updated by Jim Nelson 10 months ago
* **Status** changed from _Need Information_ to _Open_
Thanks for the photos, Joseph, this helps me confirm the issue.
The files Joseph link to will not be paired by Shotwell when they're imported.
It's not because of CHDK explicitly, but because of how they're named. One is
CRW_1001.DNG and the other is IMG_1001.JPG. If you rename the second to
CRW_1001.JPG (or vice-versa, IMG_1001.DNG), they will be paired at import. The
entire requirement for pairing is the same file title (i.e. the name without
the extension) in the same directory. Renaming after import will not work, as
explained above. #4040 is how we plan on allowing users to solve this problem
in that case.
Joseph, I assume that you did not alter these filenames before posting them on
the Internet. That tells me that this is CHDK's naming convention. We'll
probably have to make an exception in the import code to fix this.
---
Comment 13
Updated by Jeremy Nickurak 10 months ago
It's worth noting that you can reconfigure CHDK's prefixes so this works right
with Shotwell. But it would be nice if the default was handled. (Sorry I
haven't had time to update this ticket with my own pair...)
---
Comment 14
Updated by Jim Nelson 10 months ago
Ah -- that's a useful data point. That means it's possible for a CHDK user to
pick anything, I presume? Is CRW/IMG the default?
---
Comment 15
Updated by Jim Nelson 10 months ago
* **Target version** changed from _0.14.0_ to _0.15.0_
This looks like a more complicated problem than we can deal with in the time
remaining. We'll see if we can get to this in 0.15.
---
Comment 16
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.15.0_ to _0.16.0_
---
Comment 17
Updated by Jim Nelson 6 months ago
* **Target version** deleted (`<strike>`_0.16.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-25 21:56 UTC ---
This bug was previously known as _bug_ 4916 at http://redmine.yorba.org/show_bug.cgi?id=4916
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3042Adding a tag to a RAW+JPEG image with metadata writing enabled has no effect.2021-05-19T13:02:49ZBugzillaAdding a tag to a RAW+JPEG image with metadata writing enabled has no effect.## Submitted by cli..@..ba.org
**[Link to original bug (#717899)](https://bugzilla.gnome.org/show_bug.cgi?id=717899)**
## Description
---- Reported by clinton@yorba.org 2011-09-19 19:49:00 -0700 ----
Original Redmine bug id: 415...## Submitted by cli..@..ba.org
**[Link to original bug (#717899)](https://bugzilla.gnome.org/show_bug.cgi?id=717899)**
## Description
---- Reported by clinton@yorba.org 2011-09-19 19:49:00 -0700 ----
Original Redmine bug id: 4156
Original URL: http://redmine.yorba.org/issues/4156
Searchable id: yorba-bug-4156
Original author: Clinton Rogers
Original description:
Steps to reproduce:
1. In Shotwell, with metadata writing enabled, import at least one RAW+JPEG pair, choosing to copy it when prompted.
2. Add at least one tag to it.
3. Exit the application.
4. Delete the files ~/.shotwell/data/photo.db and ~/.shotwell/data/photo.db.bak.
5. Relaunch Shotwell, allow the auto-import to complete and observe the results.
Notice that the tag added in step two is no longer present.
Originally reported by Roumano form the mailing list.
Related issues:
* related to shotwell - Feature #1879: Metadata in sidecar file (Open)
* related to shotwell - 4372: metadata from RAW files is not displayed
after they are f... (Fixed)
* related to shotwell - Feature #5451: Use new EXIF rating metadata fields (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
### History
---
Comment 1
Updated by Clinton Rogers about 2 years ago
* **Description** updated (diff)
* **Keywords** set to _RAW+JPEG, metadata_
---
Comment 2
Updated by Clinton Rogers about 2 years ago
* **Description** updated (diff)
---
Comment 3
Updated by Laura Khalil almost 2 years ago
This also appears to be the case if you manually import the photos instead of
auto-import (listed in step 5 above).
---
Comment 4
Updated by Adam Dingle over 1 year ago
* **Target version** deleted (`<strike>`_0.12_`</strike>`)
---
Comment 5
Updated by Lucas Beeler over 1 year ago
* **Assignee** set to _Lucas Beeler_
* **Target version** set to _0.13_
---
Comment 6
Updated by Adam Dingle about 1 year ago
* **Assignee** deleted (`<strike>`_Lucas Beeler_`</strike>`)
---
Comment 7
Updated by Adam Dingle about 1 year ago
* **Target version** changed from _0.13_ to _0.14.0_
---
Comment 8
Updated by Jim Nelson 11 months ago
* **Category** set to _raw_
---
Comment 9
Updated by Jim Nelson 11 months ago
* **Target version** changed from _0.14.0_ to _0.15.0_
We'll try and knock this out in 0.15.
---
Comment 10
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.15.0_ to _0.16.0_
---
Comment 11
Updated by Jim Nelson 6 months ago
* **Target version** deleted (`<strike>`_0.16.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4156 at http://redmine.yorba.org/show_bug.cgi?id=4156
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3052Copied developed file is only auto-imported during runtime, not startup2021-05-19T13:03:13ZBugzillaCopied developed file is only auto-imported during runtime, not startup## Submitted by Jim Nelson
**[Link to original bug (#717909)](https://bugzilla.gnome.org/show_bug.cgi?id=717909)**
## Description
---- Reported by jim@yorba.org 2011-09-19 15:01:00 -0700 ----
Original Redmine bug id: 4146
Orig...## Submitted by Jim Nelson
**[Link to original bug (#717909)](https://bugzilla.gnome.org/show_bug.cgi?id=717909)**
## Description
---- Reported by jim@yorba.org 2011-09-19 15:01:00 -0700 ----
Original Redmine bug id: 4146
Original URL: http://redmine.yorba.org/issues/4146
Searchable id: yorba-bug-4146
Original author: Jim Nelson
Original description:
To reproduce:
1. Turn on library monitoring.
2. Import RAW (or RAW+JPEG) files with Shotwell as the developer.
3. Double-click the RAW files to force Shotwell to produce development files
alongside the original.
4. Copy one of the development files to the same directory. (In Nautilus,
Edit -> Copy followed by Edit -> Paste works fine.)
Note that Shotwell will auto-import this new file as a plain JPEG.
5. Close Shotwell.
6. Make a copy of another development file as in Step 4.
7. Start Shotwell.
Note that Shotwell will **not** import this new file.
It seems to me that copied developments should be imported every time, so the
bug is in the startup scan.
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
### History
---
Comment 1
Updated by Adam Dingle over 1 year ago
* **Target version** deleted (`<strike>`_0.12_`</strike>`)
---
Comment 2
Updated by Jim Nelson 11 months ago
* **Target version** set to _0.14.0_
---
Comment 3
Updated by Jim Nelson 11 months ago
* **Category** set to _import_
---
Comment 4
Updated by Jim Nelson 11 months ago
* **Description** updated (diff)
* **Category** changed from _import_ to _raw_
* **Target version** changed from _0.14.0_ to _0.15.0_
---
Comment 5
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.15.0_ to _0.16.0_
---
Comment 6
Updated by Jim Nelson 6 months ago
* **Target version** deleted (`<strike>`_0.16.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4146 at http://redmine.yorba.org/show_bug.cgi?id=4146
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/2675RAW thumbnail generation is CPU intensive2023-10-28T03:04:25ZBugzillaRAW thumbnail generation is CPU intensive## Submitted by an unknown user
**[Link to original bug (#717532)](https://bugzilla.gnome.org/show_bug.cgi?id=717532)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-05-07 22:25:00 -0700 ----
Original Redmine bu...## Submitted by an unknown user
**[Link to original bug (#717532)](https://bugzilla.gnome.org/show_bug.cgi?id=717532)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-05-07 22:25:00 -0700 ----
Original Redmine bug id: 3586
Original URL: http://redmine.yorba.org/issues/3586
Searchable id: yorba-bug-3586
Original author: Pedro C ôrte-Real
Original description:
I decided to test shotwell by importing all my library into it. It consists of
300GB in 38k files of which 19k are RAW files. I currently manage it with
f-spot and imported in place (without copying). The test was done on a Lenovo
X61 with a 2.2GHz Core2Duo and shotwell 0.9.2 as shipped by ubuntu natty.
Shotwell took around 15 hours to do the full import and that's without
generating all the mimics. This seemed excessive so I did some tests on the
same machine:
Using the dcraw settings f-spot uses and piping that into convert:
$time for i in `find ~/Photos/ -name "*.ARW" | sort -R | tail -n 100`; do
dcraw -h -w -c -t 0 $i | convert -geometry 128×128 - $(basename $i).jpg ;
done
real 1m44.282s
user 1m4.250s
sys 0m10.490s
So for 38k photos it would be 1.75m*380 = 11 hours, which sounds around the
right ballpark for what we got.
Then I tested importing 2GB of RAW photos into both f-spot and shotwell. The
results were:
Importing from CF card (so needing to copy)
f-spot: ~3m10s with <50% of a core used
shotwell: ~3m40s with 100% of a core used
Importing from ~/Pictures (in place)
f-spot: ~1m20s with 100% of a core used
shotwell: ~4m07s with <100% of a core used (that this ended up slower is odd
and probably just means my methodology was too sloppy)
Clearly there's some improvement potential here. f-spot is doing the half-size
RAW conversion trick (-h) but so is shotwell I think. I wonder if there's any
technical limitation to doing raw conversions in quarter or eigth size to
speed up conversions more. It could also help with not needing mimics any
more.
Related issues:
* related to shotwell - 3051: Camera timing out during import (Open)
* related to shotwell - 6118: Excessive memory use on changing developer (Open)
* related to shotwell - 1856: System sluggish during a drag-and-drop RAW
import (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
### History
---
Comment 1
Updated by Pedro Côrte-Real over 2 years ago
Note that one reason f-spot probably saturates the CPU a bit better is that
they fork out for dcraw so they probably end up using the two cores, one for
the raw conversions, another for everything else. They don't seem to be
forking more than one conversion at a time though. This isn't enough to
explain the difference though as there's more than a 2x difference between
f-spot and shotwell.
---
Comment 2
Updated by Adam Dingle over 2 years ago
* **Priority** set to _High_
Would be good to investigate this more.
---
Comment 3
Updated by Lucas Beeler about 2 years ago
* **Description** updated (diff)
* **Target version** set to _0.12_
Since we're going to be digging into the RAW developer stuff again in 0.12, we
might be able to attack this.
---
Comment 4
Updated by Jim Nelson about 2 years ago
* **Description** updated (diff)
* **Target version** deleted (`<strike>`_0.12_`</strike>`)
---
Comment 5
Updated by Jim Nelson 11 months ago
* **Target version** set to _0.14.0_
---
Comment 6
Updated by Jim Nelson 11 months ago
* **Category** set to _raw_
---
Comment 7
Updated by Jim Nelson 11 months ago
* **Tracker** changed from _Feature_ to _Bug_
* **Priority** changed from _High_ to _Normal_
We should retest this with latest Shotwell and LibRaw and see how it looks.
---
Comment 8
Updated by Jim Nelson 10 months ago
* **Target version** changed from _0.14.0_ to _0.15.0_
---
Comment 9
Updated by Jim Nelson 10 months ago
Also, this may be a duplicate of #1856.
---
Comment 10
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.15.0_ to _0.16.0_
---
Comment 11
Updated by Jim Nelson 6 months ago
* **Target version** deleted (`<strike>`_0.16.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-25 21:52 UTC ---
This bug was previously known as _bug_ 3586 at http://redmine.yorba.org/show_bug.cgi?id=3586
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/2354improve interaction with external RAW editors2021-05-19T12:35:50ZBugzillaimprove interaction with external RAW editors## Submitted by an unknown user
**[Link to original bug (#717210)](https://bugzilla.gnome.org/show_bug.cgi?id=717210)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-01-05 03:40:00 -0800 ----
Original Redmine bu...## Submitted by an unknown user
**[Link to original bug (#717210)](https://bugzilla.gnome.org/show_bug.cgi?id=717210)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-01-05 03:40:00 -0800 ----
Original Redmine bug id: 3061
Original URL: http://redmine.yorba.org/issues/3061
Searchable id: yorba-bug-3061
Original author: Ruth -
Original description:
possibly related to ticket #1772: If I edit a raw photo externally with the
raw editor, then it creates a jpg file in the same directory. As it is now,
this jpg photo will be displayed in shotwell next to the original raw version.
I would like it to display only the jpg file.
I think this behaviour works already when 'open with external editor' is used,
because then a file 'XXX_modified.jpg' is created, and that one is shown
instead of the original.
I would like the same sort of thing to happen when 'open with raw editor' is
selected.
Related issues:
* related to shotwell - Feature #1772: allow a single photo to contain a
RAW+JPEG pair (Fixed)
* related to shotwell - Feature #6391: Multiple RAW development presets (Open)
* duplicated by shotwell - 4335: Use of external RAW editor saves in bad
file format; resu... (Duplicate)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-01-17 12:23:00 -0800 ----
### History
---
Comment 1
Updated by Jim Nelson almost 3 years ago
I'm not sure I follow. If you select “Open with External Editor†on a RAW
file, it will create a _modified file, but it shouldn't display both it and
the RAW file, only the _modified file (in place of the RAW file). Is that not
happening for you? What version of Shotwell are you using?
---
Comment 2
Updated by Ruth - almost 3 years ago
yes, open with **external** editor works. But open with **raw** editor doesn't
. I would like that to behave the same way.
I use rawtherapee as raw editor, I have tried to let it save the file as
XXX_modified.jpg but shotwell still imports that as a new file.
I use shotwell 0.8
---
Comment 3
Updated by Adam Dingle almost 3 years ago
* **Subject** changed from _keep jpg version combined with raw_ to _keep jpg version combined with raw after external edit_
This ticket is related to#1772(allow a single photo to contain a RAW+JPEG
pair). Once we implement that, when the user edits an image using an external
RAW editor and the external editor writes out a JPEG, it would be nice if the
resulting JPEG could be associated with the original RAW image as suggested
here.
---
Comment 4
Updated by Adam Dingle over 2 years ago
* **Subject** changed from _keep jpg version combined with raw after external edit_ to _improve interaction with external RAW editors_
To make this work smoothly, we might need to have special-case code for
various RAW editors because they might save photos in different ways. But that
might still be worth doing (perhaps via a plugin interface). Some external
editors might not even save JPEGs automatically, in which case we might need
to ask them to render the image explicitly; see
http://lists.yorba.org/pipermail/shotwell/2011-February/001838.html
---
Comment 5
Updated by Adam Dingle over 2 years ago
* **Target version** set to _0.11_
* **Priority** set to _High_
---
Comment 6
Updated by Eric Gregory over 2 years ago
See related ticket: #3730
---
Comment 7
Updated by Adam Dingle over 2 years ago
* **Target version** deleted (`<strike>`_0.11_`</strike>`)
---
Comment 8
Updated by Adam Dingle about 2 years ago
* **Description** updated (diff)
There's one more important case here: a user might have existing JPEG images
which have already been generated from RAW images in the library using an
external RAW editor. In this case, Shotwell will have no opportunity to
observe the RAW editor being launched.
Since we've seen that may be difficult for Shotwell to automatically determine
which JPEG images have been written by RAW editors, as a first step we could
implement a command which allows the user to specify manually that an existing
JPEG image is actually the external raw development of an existing RAW image.
That would require an extra manual step, but would work in any case. If we
take this approach, this feature will now look a lot like #4040
(combine/separate RAW+JPEG photos) with the difference that when the user
merges a RAW and JPEG photos, they'd like the JPEG photo to be considered as
an external development of the RAW image (whereas in #4040 it's a camera
development). We should think hard about whether that distinction is even
worth maintaining. As an alternative approach, we could implement some sort
of photo stacking (#2090) in which RAW and JPEG images can be grouped together
but it's the user's reponsibility to know where they came from, exactly.
---
Comment 9
Updated by Martin Ling over 1 year ago
* **Description** updated (diff)
I am waiting impatiently for this feature, it's the only thing blocking me
from using Shotwell at the moment. I am in the situation mentioned in comment
#8: I have a library of 20,000+ photos processed with UFRaw that I would love
to import - right now I have no solution for tagging, etc - but I need
Shotwell to recognise these for what they are and also work correctly with new
images that I process in UFRaw, otherwise it's not a usable solution for me.
Some information that might be useful: in some cases you may be able to read
the Exif.Image.Software and/or Exif.Image.ProcessingSoftware tags to identify
the developer of an image. Many raw editors will identify themselves in these
tags. I know UFRaw writes this tag because I added that code myself a couple
of years ago, and some searching suggests a lot of others do too including
Adobe & Apple packages, digiKam, and rawstudio. Also those that don't could
very easily have this feature added to help them interoperate with Shotwell,
if their users request it.
In my case at least, it would be sufficient for Shotwell to treat any JPEG
file, with the same filename as a corresponding raw image in the same
directory, where the Exif.Image.ProcessingSoftware tag starts with 'UFRaw', as
an externally-developed version of that raw image. This would work for both
initial identification, and catching newly edited images that appear in a
library directory. A simple list of tag patterns for matching known RAW
editors would let this support other programs too, with new ones added easily.
This won't catch the cases where the externally developed version gets saved
with a different filename, or in a different directory, but in many cases the
user will be able to adapt their workflow to avoid doing that.
Catching every possible case would require fancy configuration of where raw
and processed images get stored, or metadata/image based detection of probable
edited duplicates, but both of those are separate features in their own right
and aren't needed just to make this usable.
---
Comment 10
Updated by Eric Anderson 12 months ago
This is an issue that causes me a lot of trouble as well. With my particular
camera, the "Camera" development option produces a low-resolution image, and
the "Shotwell" option makes the colors painfully flat. Either way, the benefit
of shooting in raw is almost completely lost. (I say almost, because the raw
file is still there; it just means giving up the convenience of using
Shotwell.)
It seems to me that the "right" behavior is about like this:
* "Open with raw editor" waits for the editor to terminate and then either (a) takes the file produced, or if that's not possible (b) gives the user a file-selection dialog to find it manually.
* Any (supported) raw editor should be an option for the "develop" menu, so that the editor is invoked automatically after the raw files are imported.
As far as I can tell, doing this intelligently requires special-casing the raw
editors, and/or letting the user define command line and generated-JPEG-
finding rules directly.
Am I out in left field here, or do the rest of you agree?
---
Comment 11
Updated by Moe Blue 12 months ago
Eric Anderson wrote:
> This is an issue that causes me a lot of trouble as well. With my particular
camera, the "Camera" development option produces a low-resolution image, and
the "Shotwell" option makes the colors painfully flat. Either way, the benefit
of shooting in raw is almost completely lost. (I say almost, because the raw
file is still there; it just means giving up the convenience of using
Shotwell.)
Eric, maybe shotwell recovers the embedded jpeg as the camera developed
version. My workaround is to use Shotwell as default developer (which produces
the flat color/dark image) and then switch to camera developer afterwards.
Eric Anderson wrote:
> Am I out in left field here, or do the rest of you agree?
Using Camera-Developed JPEG is fine for me in 95 percent. However, it would be
great to have better integration to other raw development tools such as ufraw
or darktable. Btw, darktable has a new CLI, maybe that helps.
---
Comment 12
Updated by Jim Nelson 12 months ago
* **Target version** set to _0.14.0_
Integrating the various RAW editors out there is a challenge and it may be
that we have to use some of the suggestions you've made, Eric. I'm curious:
how low is the resolution of the camera-developed image? Most RAW cameras
embed full-sized (or near-full-sized) images in their RAW file.
We'd rather not wait for the RAW editor to finish, as that has a lot of
problems on its own. What we do for "normal" external editing (i.e. GIMP
editing a JPEG) is to monitor the file for changes and made that file the
baseline for all future changes within Shotwell. That's a similar strategy
we've elected for Shotwell with RAW development.
---
Comment 13
Updated by Jim Nelson 11 months ago
* **Category** set to _library-mode_
---
Comment 14
Updated by Jim Nelson 11 months ago
* **Category** changed from _library-mode_ to _raw_
---
Comment 15
Updated by Jim Nelson 11 months ago
* **Target version** deleted (`<strike>`_0.14.0_`</strike>`)
Unfortunately, this is a big enough problem we're not going to be able to get
this for 0.14.
---
Comment 16
Updated by Roumano - 10 months ago
Darktable (a raw developer) as just commit a dbus server to add a way to tell
it to load images/folders.
Etherwise, it's can also be launch via command line
For more information, see
http://www.darktable.org/redmine/projects/darktable/repository/revisions/543e6
64f367721e88dfa0cddf5c93006adbc7576
It's will be great, if darktable can be added as external raw developer in
shotwell
--- Bug imported by chaz@yorba.org 2013-11-25 21:49 UTC ---
This bug was previously known as _bug_ 3061 at http://redmine.yorba.org/show_bug.cgi?id=3061
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/2397convert RAW photos to DNG2021-05-19T13:55:29ZBugzillaconvert RAW photos to DNG## Submitted by Adam Dingle
**[Link to original bug (#717253)](https://bugzilla.gnome.org/show_bug.cgi?id=717253)**
## Description
---- Reported by adam@yorba.org 2010-12-25 04:41:00 -0800 ----
Original Redmine bug id: 3018
Or...## Submitted by Adam Dingle
**[Link to original bug (#717253)](https://bugzilla.gnome.org/show_bug.cgi?id=717253)**
## Description
---- Reported by adam@yorba.org 2010-12-25 04:41:00 -0800 ----
Original Redmine bug id: 3018
Original URL: http://redmine.yorba.org/issues/3018
Searchable id: yorba-bug-3018
Original author: Adam Dingle
Original description:
A user on the mailing list suggested it would be nice if Shotwell could
convert RAW photos to DNG. I agree this would make sense, especially since DNG
is a more open format than the various proprietary RAW formats.
Related issues:
* related to shotwell - Feature #2622: Support writing metadata to RAW formats (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-01-15 11:20:00 -0800 ----
### History
---
Comment 1
Updated by Jim Nelson 10 months ago
* **Category** set to _raw_
* **Priority** changed from _Low_ to _Normal_
One thing we need to consider about this feature: if Shotwell converts all RAW
files to DNG at import, does Shotwell keep the RAW file around? If not, then
it's possible to lose some information (the conversion will most likely be
inexact, i.e. certain metadata, previews, and camera-specific data may be
lost). If so, now Shotwell will have three files to maintain: RAW, DNG, and
the development.
If it's converting at export only, that's much easier to implement, but
obviously less desireable to a user who wants their entire collection in DNG
format.
--- Bug imported by chaz@yorba.org 2013-11-25 21:50 UTC ---
This bug was previously known as _bug_ 3018 at http://redmine.yorba.org/show_bug.cgi?id=3018
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/1493unable to export DNG: size of Exif JPEG segment larger than 65535 bytes2021-05-19T12:00:59ZBugzillaunable to export DNG: size of Exif JPEG segment larger than 65535 bytes## Submitted by Adam Dingle
**[Link to original bug (#716349)](https://bugzilla.gnome.org/show_bug.cgi?id=716349)**
## Description
---- Reported by adam@yorba.org 2010-06-28 10:07:00 -0700 ----
Original Redmine bug id: 2221
Or...## Submitted by Adam Dingle
**[Link to original bug (#716349)](https://bugzilla.gnome.org/show_bug.cgi?id=716349)**
## Description
---- Reported by adam@yorba.org 2010-06-28 10:07:00 -0700 ----
Original Redmine bug id: 2221
Original URL: http://redmine.yorba.org/issues/2221
Searchable id: yorba-bug-2221
Original author: Adam Dingle
Original description:
From Peter Smith <pdo.smith@gmail.com>:
After having imported DNG files from my camera I tried to launch an external
editor “Open with external editor†and got the following error
Unable to launch editor: Size of Exif JPEG segment is larger than 65535 bytes.
However if I open with RAW editor it launches Ufraw and everything works
properly.
===
OK, here is an example of a file that causes the problem:
http://www.mediafire.com/file/jzng3zz0qto/IMGP8875.%(=caps)DNG%
It seems to happen with all my DNG files.
I tried importing the file and I can reproduce this. I also receive the same
error (Size of Exif JPEG segment is larger than 65535 bytes) if I try to
export the photo from Shotwell as a JPEG.
Related issues:
* related to shotwell - 6442: The Shotwell development of camera raw files
with EXIF se... (Invalid)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:45:00 -0700 ----
### History
---
Comment 1
Updated by Adam Dingle over 3 years ago
* **Subject** changed from _unable to export: size of Exif JPEG segment larger than 65535 bytes_ to _unable to export DNG: size of Exif JPEG segment larger than 65535 bytes_
---
Comment 2
Updated by Jim Nelson over 3 years ago
* **Priority** set to _High_
Verified. It appears that DNG files support EXIF blocks larger than 64K, which
is the hard upper limit for JPEG files. When you edit with an external editor,
we essentially export the RAW file to JPEG (this is why export fails as well)
and then copy the metadata from the RAW file to the JPEG file. This fails,
causing the entire operation to fail.
We won't be able to attack this problem in time for 0.6. We should be able to
correct this for 0.7, however.
---
Comment 3
Updated by Omer Akram about 3 years ago
also reported at: https://bugs.launchpad.net/ubuntu/source/shotwell/bug/675023
---
Comment 4
Updated by Adam Dingle about 3 years ago
Jim explained that we can address this by stripping embedded JPEGs. (If the
remaining EXIF data is still over 64K then perhaps we can remove it entirely
and/or store it using XMP instead.)
---
Comment 5
Updated by Adam Dingle about 3 years ago
* **Priority** deleted (`<strike>`_High_`</strike>`)
---
Comment 6
Updated by Jim Nelson almost 3 years ago
I've seen this error with an SRW file as well when I select Open with External
Editor. The bug is essentially the same: we can't convert RAW to JPEG with the
oversized EXIF block.
---
Comment 7
Updated by Jim Nelson 9 months ago
* **Description** updated (diff)
* **Category** set to _raw_
* **Priority** changed from _Low_ to _High_
* **Target version** set to _0.15.0_
This is fundamentally broken and I'd like to see this fixed, but we won't be
able to attack this right now. We'll shoot for this in 0.15.
---
Comment 8
Updated by Jim Nelson 8 months ago
* **Assignee** set to _Clinton Rogers_
* **Keywords** set to _needs-testing_
Let's see if Exiv2 0.23 fixes this in any way.
---
Comment 9
Updated by Lucas Beeler 8 months ago
* **Status** changed from _Open_ to _Need Information_
Setting to Needs Information since we need to test this with the new version
of exiv2.
---
Comment 10
Updated by Jim Nelson 7 months ago
* **Status** changed from _Need Information_ to _Open_
* **Assignee** changed from _Clinton Rogers_ to _Jim Nelson_
Quantal ships with 0.23, so if that version fixes this problem, we can close
this ticket.
---
Comment 11
Updated by Jim Nelson 6 months ago
* **Target version** deleted (`<strike>`_0.15.0_`</strike>`)
---
Comment 12
Updated by Jim Nelson 6 months ago
* **Assignee** deleted (`<strike>`_Jim Nelson_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-25 21:45 UTC ---
This bug was previously known as _bug_ 2221 at http://redmine.yorba.org/show_bug.cgi?id=2221
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/1393System sluggish during a drag-and-drop RAW import2023-10-28T03:06:42ZBugzillaSystem sluggish during a drag-and-drop RAW import## Submitted by Jim Nelson
**[Link to original bug (#716249)](https://bugzilla.gnome.org/show_bug.cgi?id=716249)**
## Description
---- Reported by jim@yorba.org 2010-04-30 15:11:00 -0700 ----
Original Redmine bug id: 1856
Orig...## Submitted by Jim Nelson
**[Link to original bug (#716249)](https://bugzilla.gnome.org/show_bug.cgi?id=716249)**
## Description
---- Reported by jim@yorba.org 2010-04-30 15:11:00 -0700 ----
Original Redmine bug id: 1856
Original URL: http://redmine.yorba.org/issues/1856
Searchable id: yorba-bug-1856
Original author: Jim Nelson
Original description:
When I import a lot of RAW photos via drag-and-drop, my system is sluggish.
Related issues:
* related to shotwell - 3586: RAW thumbnail generation is CPU intensive (Open)
* related to shotwell - 6118: Excessive memory use on changing developer (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
### History
---
Comment 1
Updated by Adam Dingle over 3 years ago
* **Priority** deleted (`<strike>`_High_`</strike>`)
Dropping from 0.6.
---
Comment 2
Updated by Jim Nelson 11 months ago
* **Target version** set to _0.14.0_
---
Comment 3
Updated by Jim Nelson 11 months ago
* **Category** set to _raw_
---
Comment 4
Updated by Jim Nelson 11 months ago
* **Category** changed from _raw_ to _performance_
* **Priority** changed from _Low_ to _Normal_
---
Comment 5
Updated by Jim Nelson 11 months ago
* **Tracker** changed from _Feature_ to _Bug_
---
Comment 6
Updated by Anonymous 10 months ago
* **Status** changed from _Open_ to _5_
Applied in changeset 66c2ffaa70cd2bbe539c8324511ca243394e5db2.
---
Comment 7
Updated by Lucas Beeler 10 months ago
* **Status** changed from _5_ to _Open_
---
Comment 8
Updated by Jim Nelson 10 months ago
The revision listed above is actually for #1846.
---
Comment 9
Updated by Jim Nelson 10 months ago
* **Category** changed from _performance_ to _raw_
* **Target version** changed from _0.14.0_ to _0.15.0_
We should check if this is merely a duplicate (or closely related to) #3586
and/or #6118.
---
Comment 10
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.15.0_ to _0.16.0_
---
Comment 11
Updated by Jim Nelson 6 months ago
* **Target version** deleted (`<strike>`_0.16.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-25 21:44 UTC ---
This bug was previously known as _bug_ 1856 at http://redmine.yorba.org/show_bug.cgi?id=1856
Unknown version " in product shotwell.
Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolution