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 718242 - Camera RAW developer wastes disk space by extracting embedded JPEGs
Camera RAW developer wastes disk space by extracting embedded JPEGs
Status: RESOLVED OBSOLETE
Product: shotwell
Classification: Other
Component: raw
unspecified
Other All
: High normal
: ---
Assigned To: Shotwell Maintainers
Shotwell Maintainers
: 718911 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-10-16 01:10 UTC by Shotwell Maintainers
Modified: 2019-12-23 17:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Charles Lindsay 2013-11-25 21:55:19 UTC


---- Reported by shotwell-maint@gnome.bugs 2011-10-16 06:10:00 -0700 ----

Original Redmine bug id: 4261
Original URL: http://redmine.yorba.org/issues/4261
Searchable id: yorba-bug-4261
Original author: Anton Keks
Original description:

When viewing photos with RAW developer set to Camera (ie Embedded), Shotwell
extracts *_embedded.jpg files from CR2 files - wasting space, because this
data is readily available from inside the CR2 file anyway.

In case of 5D MarkII these embedded JPEGs take 2-3 Mb each, why extract them
if they can be read from the CR2 on the fly?

Related issues:
related to shotwell - 4702: use Camera developer by default (Fixed)
related to shotwell - Feature #1798: keep full-resolution version of each
edited image (Open)
related to shotwell - 4262: Camera (Embedded) RAW developer fails to show
correct pho... (Fixed)



---- Additional Comments From shotwell-maint@gnome.bugs 2013-04-23 13:58:00 -0700 ----

### History

####

#1

Updated by Lucas Beeler about 2 years ago

  * **Target version** deleted (<strike>_0.11.2_</strike>)

####

#2

Updated by Anton Keks about 2 years ago

Try this fix that partially does the thing (also fixes #4262 as a side-
effect):

https://github.com/angryziber/shotwell/compare/master...dont-save-embedded-
jpegs

Or just:

git pull git://github.com/angryziber/shotwell.git dont-save-embedded-jpegs

####

#3

Updated by Adam Dingle about 2 years ago

  * **Priority** changed from _Normal_ to _High_
  * **Target version** set to _0.12_

Lucas, please review. Thanks!

####

#4

Updated by Lucas Beeler about 2 years ago

Hi Anton,

This patch looks good so far. As you note in your TODO comment in
RawSupport.vala:24, you need to select which reader to use based on the reader
currently associated with the photo. Do you need any help or technical
guidance with this or are you already working on an updated patch now? Let us
know if we can help.

Lucas

####

#5

Updated by Anton Keks almost 2 years ago

I have developed the patch a little further, implemented the previous TODO and
made further code improvements.

There is still some problem with importing photos when developer is set to
Shotwell, but all in all, it is much more useful already than the master
branch.

Please review:

https://github.com/angryziber/shotwell/compare/master...dont-save-embedded-
jpegs

IMHO, the developer should be set to Camera by default on new Shotwell
installations - this works much quicker, doesn't waste the disk space and
provides images that users expect to see, not the dark and flat image usually
produced by the Shotwell developer.

####

#6

Updated by Adam Dingle almost 2 years ago

  * **Status** changed from _Open_ to _Review_

I personally agree that we should set the developer to Camera by default.
Lucas, do you agree with that too? If so can we add that change to this patch?

####

#7

Updated by Adam Dingle almost 2 years ago

I've created a separate ticket for switching to the Camera developer by
default: see #4702.

####

#8

Updated by Adam Dingle over 1 year ago

  * **Target version** deleted (<strike>_0.12_</strike>)

####

#9

Updated by Adam Dingle over 1 year ago

  * **Target version** set to _0.13_

####

#10

Updated by Lucas Beeler over 1 year ago

  * **Category** set to _4_
  * **Assignee** set to _Lucas Beeler_

####

#11

Updated by Adam Dingle about 1 year ago

  * **Assignee** deleted (<strike>_Lucas Beeler_</strike>)

####

#12

Updated by Adam Dingle about 1 year ago

  * **Target version** changed from _0.13_ to _0.14.0_

####

#13

Updated by Jim Nelson 11 months ago

  * **Category** set to _raw_

####

#14

Updated by Lucas Beeler 11 months ago

  * **Status** changed from _Review_ to _Open_
  * **Assignee** set to _Anton Keks_

@anton:

Could you update your GitHub branch such that your changes are made on top of
the current git master? Yorba is surfacing from a period where we haven't been
able to dedicate many resources to Shotwell; now that Shotwell development is
picking up steam again, we're very interested in getting this patch to the
point where it can undergo a pre-landing review.

I did spend quite a while looking over your work and I'm really impressed that
you've created the notion of a developer-specific RAW FileReader. This is
something I've wanted to do in Shotwell for quite a while.

Once again, thanks for the patch. I'm looking forward to an updated version!

####

#15

Updated by Anton Keks 10 months ago

Fortunately, it was easy to rebase, here you are:

https://github.com/angryziber/shotwell/compare/master...dont-save-embedded-
jpegs

####

#16

Updated by Lucas Beeler 10 months ago

  * **Status** changed from _Open_ to _Review_

####

#17

Updated by Jim Nelson 10 months ago

  * **Target version** changed from _0.14.0_ to _0.15.0_

We're going to bump this down to 0.15. We have some concerns about this
approach in general. Users have long-complained about not having direct file
system access to the image displayed in Shotwell (for example, to drag-and-
drop from Shotwell to another application). This feature also needs to deal
with allowing the JPEG to be edited by an external application (i.e. GIMP),
and we would prefer not to have a special-case code path where the JPEG is
extracted at the last minute before editing.

We'll reevaluate this in the 0.15 timeframe. Anton, in the meantime, please
feel free to respond and provide suggestions how to address these concerns.

####

#18

Updated by Lucas Beeler 7 months ago

  * **Status** changed from _Review_ to _Open_
  * **Target version** deleted (<strike>_0.15.0_</strike>)

For reasons Jim mentioned in his previous comment: direct file access and
interoperability with external editing applications, I'm moving the status of
this ticket back to "open." We need to think hard about several things before
considering a patch like this. In addition to what Jim said earlier, it's also
unclear how this change would interact with #1798 ("keep full-resolution
version of each edited image") which is a more immediate priority for Shotwell
development.



--- Bug imported by chaz@yorba.org 2013-11-25 21:55 UTC  ---

This bug was previously known as _bug_ 4261 at http://redmine.yorba.org/show_bug.cgi?id=4261

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 

Comment 1 Jim Nelson 2015-03-25 19:08:04 UTC
*** Bug 718911 has been marked as a duplicate of this bug. ***
Comment 2 kertase 2017-07-19 16:55:48 UTC
This is also a waste of space when Raws are accompanied by jpgs from the camera. You should be able to disable automatique raw development.
Comment 3 Jens Georg 2017-07-19 19:07:54 UTC
That's rather by accident then by design.
Comment 4 Jens Georg 2017-08-23 03:06:35 UTC
(In reply to kertase from comment #2)
> This is also a waste of space when Raws are accompanied by jpgs from the
> camera. You should be able to disable automatique raw development.

That's fixed on master
Comment 5 simvrh 2018-01-01 14:21:18 UTC
According to the earlier IRC chat, I propose a solution for this bug:

It would make sense to separate the photo library from shotwell-generated files. The shotwell-generated *_embedded* or *_shotwell* could be stored e.g. in ~/.cache folder or picture/thumbnail/preview database.

This would also solve the duplicate photos bug (see e.g. https://askubuntu.com/questions/489951/how-to-remove-duplicate-imported-photos-in-shotwell). This bug seems to be still present on Shotwell 0.24.5 that I'm currently running.

Reasoning:

Shotwell supports two model for raw developer that cannot be disabled due to performance issues.

The raw developer produces a new jpg image that is stored in the same folder as the original photo. I am using the manufacturer software (on Windows/Mac) for raw processing and adding new files to the photo folders makes is not making it easier -- it makes a mess. In case the shotwell raw developer is used on RAW+JPG, this produces a second jpg of the same image in the photo folder. Also, the shotwell-produced jpg can be very different from the camera produced one.

There are 3 photos: RAW, camera JPG (produced by camera or manufacturer software) and shotwell JPG. It would be best if shotwell displayed the camera JPG. In not available, then it would produce its own JPG but store it in a different location. If the camera JPG is produced at a later time, this would avoid the confusion on multiple JPGs in the same folder. Also, shotwell wouldn't mistake its own photo for an imported one (keep in mind that the same library can be used on different systems, e.g. portable disks).
Comment 6 Jens Georg 2019-12-23 17:17:06 UTC
Tracked as https://gitlab.gnome.org/GNOME/shotwell/issues/197