re JPEG lossiness, PNG

[Paul Verizzo]

"I'm not sure if that's a rhetorical question. Anyway, I was doing some

changes on the images, and didn't want to lose more info due to the
jpg-compression.
I think of it this way (maybe I'm wrong): every time I change a jpg
image, some info of the origional gets lost and the image cannot ever
be put in the original state by just reverting the changes, because it
drops the original info and adds in some new based on the changes.
But (that's what I think) when I change a png image, I can get the
original state back by reverting the changes.
I knew that png makes the files bigger, but I still do not understand
how the jpg can become 10 times bigger by converting it to png. Even
the raw images of the same picture are less than half the size of the
png file.
I'll probably never fully understand the mysteries behind this,
because I can't even see the difference. I'll probably stick to jpg
even though some information is not stored in the file. Why don't
camera manufacturers use a non-lossy format that produces smaller
images than the raw images? Or isn't that possible at all?

Regards

Martin"
--------------------------------------
Martin, you are correct about changing and saving JPEG files.  Oh, I wish I had known that a dozen years ago!  I manipulated many of my 2.1mp (!!) files, not understanding the consequences.  It was all pretty new back then, not many good maps for us digital Conquistadors!

Now that hard drive space is so cheap, the solution to this problem is simple: Save your original (RAW and/or post-RAW or out-of-the-camera JPEG's) files in a subfolder, possibly named, um, "Originals". Mark them all "Read Only."  Now you can manipulate to your heart's content and you always have an original to fall back on.

I also save all files with 100% quality level, or whatever the "no compression" setting is for whatever program you are using.  Again, disk space is so cheap.

PNG certainly should not be ten times as large as a JPEG. If you took a picture of an all monotone color, that would be maximum JPEG compression.  Every pixel is just like the others.  But I still can't imagine what would cause your issue. PNG is a nifty format with lots of potential and uses, but the not-lossiness isn't an issue if you save your originals as I've suggested. JPEG rules the jungle still, there is no downside as long as you don't keep working on, and then saving a file repeatedly.

I hope this helps a bit in your quest.

--
The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -John Kenneth Galbraith

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Dr. Martin Senftleben]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I find it interesting that this has become a thread about which format
is the best. It is a question that still bugs me, so thank you for all
your comments! I'm still searching for the best way, but I understand
the best would be to work with the raw images and use them as the
initials. Right. I was always a bit reluctant to work on raws, because
it seemed quite complex, but it doesn't seem to be with digikam.
I took one raw image now and saved it in different formats, without
any changes applied.
The outcome is as follows:
cr2 (original from camera of course): 23.7 MB
jpg (produced by camera): 5.7 MB
jpg (produced by digikam from cr2): 1.6 MB
tif: 51.7 MB (w/o compression, w/ compression it's 27.4 MB)
pgf: 22.8 MB
png: 22.3 MB
jpg2000: 22 MB

pgf is for me out of the question, I had too much trouble with that
format. jpg is lossy, tif quite big (even with compression). Remain
png and jpg2000, where jpg2000 is a format not so well supported.

What puzzles me (is this a bug?) is that none of the tags which I had
saved with the raw file have been taken over by any of the exported
formats. It would be very difficult to create new images from the raw
file and again and again add the tags to the new versions. Only the
description and other exif data were taken over - at least something.

What workflow would be the best to make sure that I have not to repeat
adding tags to the different versions of the same file? Or is there
some setting that I missed which would do the trick?
I could think of: loading raws from the camera, then creating copies
and then starting to tag them etc. But this would only be ok for the
first version I create. As soon as I start to create another version
with some other settings from the raw file, I'll have to redo the
tagging... Another limitation, if I use png as the format to work
with, is that the files are too big for uploading to flickr. This will
always add the step of converting to jpg to the workflow. It's not too
much work, but it's a step that requires some attention and time,
depending on the number of images I want to upload. What if
flickrexport would do the conversion?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk8RJD0ACgkQUmmuY48ByEgNvACfUgM6iUQaPtOXigkmzbkcIlZF
rWAAnRv1FMPWaEpX7XXyWOXVY/wmoO01
=rdHu
-----END PGP SIGNATURE-----

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

On Saturday 14 January 2012 07:44:17 Dr. Martin Senftleben wrote:

> Hi all,
>
> I find it interesting that this has become a thread about which format
> is the best. It is a question that still bugs me, so thank you for all
> your comments! I'm still searching for the best way, but I understand
> the best would be to work with the raw images and use them as the
> initials. Right. I was always a bit reluctant to work on raws, because
> it seemed quite complex, but it doesn't seem to be with digikam.
> I took one raw image now and saved it in different formats, without
> any changes applied.
> The outcome is as follows:
> cr2 (original from camera of course): 23.7 MB
> jpg (produced by camera): 5.7 MB
> jpg (produced by digikam from cr2): 1.6 MB
> tif: 51.7 MB (w/o compression, w/ compression it's 27.4 MB)
> pgf: 22.8 MB
> png: 22.3 MB
> jpg2000: 22 MB
>
> pgf is for me out of the question, I had too much trouble with that
> format. jpg is lossy, tif quite big (even with compression). Remain
> png and jpg2000, where jpg2000 is a format not so well supported.
>

Personally, I save and tag my raw files, then convert to (16-bit) PNG for
editing, and use JPG for the final images, after resizing to the required
size.

> What puzzles me (is this a bug?) is that none of the tags which I had
> saved with the raw file have been taken over by any of the exported
> formats. It would be very difficult to create new images from the raw
> file and again and again add the tags to the new versions. Only the
> description and other exif data were taken over - at least something.

I saw that as well, in that Digikam showed tags with the converted image, but
tags and description were not stored in the image file itself. (and I have
selected all but the last three options in the 'Settings/Metadata/Common
metadata actions' section). To get that information in my png files, I used
the menu-item 'Image/write metadata to image'. But I'm not sure if that works
on a series of selected files.

> What workflow would be the best to make sure that I have not to repeat
> adding tags to the different versions of the same file? Or is there
> some setting that I missed which would do the trick?
> I could think of: loading raws from the camera, then creating copies
> and then starting to tag them etc. But this would only be ok for the
> first version I create. As soon as I start to create another version
> with some other settings from the raw file, I'll have to redo the
> tagging...

Do you use XMP files? I get the impression that the interactions between in-
file metadata and XMP metadata isn't quite optimal yet.

> Another limitation, if I use png as the format to work
> with, is that the files are too big for uploading to flickr. This will
> always add the step of converting to jpg to the workflow. It's not too
> much work, but it's a step that requires some attention and time,
> depending on the number of images I want to upload. What if
> flickrexport would do the conversion?

For that kind of things I use batch mode (with the tools 'resize', 'sharpen',
'add metadata template', 'export to jpg'). This also means I never resize my
pngs (I do crop them to get the optimal aspect ration and composition).

I prefer working from raw files, as I get better results from them. But it
depends also on your kind of photography: if you shoot events yielding 100s of
photos to be processed quickly, you might be better off using in-camera JPG
(or save as both JPG and RAW to use the raw for the best shots). If you're
mostly doing subjects where you end up with a few (10s) of images that are
kept/processed (macro, portrait, landscape), RAW might be the preferred
starting format, for the control and quality it can give you.

Just a few points if you start working in RAW.
Try to do as much as possible in the RAW converter: white balance, exposure
correction, noise reduction if needed, etc. This can reduce artifacts and
information loss, as some steps can be done before demosaicing. Though I
basically ignore the Post Processing tab, as changes there are done after
demosaicing, and the normal edit page gives me more control.

And, don't forget to sharpen your images. At least apply an unsharp mask at
the end of your edits (for a 10MP pic, radius 25/amount 0.6/threshold 0.03
seems to work nicely for me as a starting point, you'll have to adapt it to
your image). Just don't overdo the sharpening to avoid artifacts.
(If I really want to pull out all the stops, I sharpen 2 or 3 times:
- capture sharpening  after raw conversion: refocus on default settings
- unsharp mask after edits as mentioned above
- unsharp mask after resizing for final output; usually radius=10, amount to
taste)

Regards

Remco
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse]

Hello all,

Some comments about that files formats discussion and a recurrent
issue, "JPEG or not JPEG ? ".

It's often said that JPEG is a lossy format. Well, no, not exactly.
The JPEG standard features compression algorithms, as other images
formats do, GIF, PNG et al. And a compression algorithm is just a way to
reorganise the same data in a more clever way, in order to save space.

What is particular to JPEG is that the standard provides also means to
increase compression efficiency if the user accepts slight
simplifications to data, making the compression algorithm give better
results regarding the final size. Consequent data loss is neither a
weakness of the standard nor a fatality, it's a feature, and an optional
feature, when final small size is important.

The major idea in data compression with slight losses is to consider
slightly different pixels as identical, thus increasing dramatically
compression techniques based on similar data re-encoding (this concerns
Run Length Encoding, Huffman groups tables and others). Of course,
doing this leads to loose the initial full information,
the transformation "almost similar pixels" into "same pixels" is not
reversible. But it's up to the user to choose, or not, to do this,
according to a final satisfying visual quality.

JPEG can compress in a lossless way, until the algorithm bumps against
some limits. GIF does so, PNG does so. But JPEG can boost compression
efficiency if the user accept some losses.
That's what Marie-Noëlle Augendre said, on this thread :
"I guess that to produce something smaller, you'll have to loose
something."
Definitely right, there's no magic at all, and Santa Claus doesn't
exist:-)

JPEG has been initially elaborated by and for photographers. And a
photography is never intended to be measured with instruments, but to be
looked at by human eyes. Thus, the JPEG philosophy is : if you don't see
the difference, do it and save file size and disk space.

And there's no definitive algorithm to determine that "satisfying visual
quality", but the user's eye. That's why JPEG writing programs provide
the option to select final quality.

If one selects the best, 100% quality, there won't be data loss but the
final file size won't be that small, comparable to the size of the same
image saved in PNG format.

If one selects, says 90% quality, there will be some data loss but the
final file will be significantly smaller. It's a user choice, not a
JPEG format intrinsic fatality.

Paul Verizzo wrote on this thread :
"I also save all files with 100% quality level, or whatever the "no
compression" setting is for whatever program you are using."
Right. I do the same thing. Just to point that the "no compression"
setting in programs is to be understood as "Use standard compression
lossless techniques but keep all my image data intact, don't boost over
the limit". That's what do PNG compression algorithms.

Problems may arise, as was mentioned by Andrew Goodbody :
"Yes, you will lose more information every time you re-save a jpg file."
That's true because most JPEG writing programs have a default preset value
of 90% or 95% for quality. (Some, as The GIMP, evaluate an optimal quality
according to the current picture.) And in that case, of course, several
re-writing will have a cumulative effect, 90% of 90% of 90% etc.

(Btw this default setting of 90%, choosen on a standard image use basis,
may probably be the reason of the "lossy" JPEG reputation.)

But if you configure your program to use 100% quality, you can re-write
tens of times, without loss. (But with larger files, obviously, as said
above, Santa Claus doesn't exist.)

I fully agree with Paul when he says : "Again, disk space is so cheap."
And my personal opinion is that JPEG used in 100% quality mode, i.e.
no data loss, is a good disk storage format, equivalent to PNG.
Anyway it's the same image data.

Space considerations become relevant when one uses the web, because
files sizes means disk space on the web hosting and transmission time
and bandwidth use when a visitor looks at the images pages. And in that
context, it's useful to ask the good question "What do I want to do with
my images on my web album(s) ? " In most cases, photos displayed on web
pages will have reasonable dimensions, 600 to 700 pixels width is a
common size, well suited to a standard HTML page.

Such dimensions allow good looking images, but too small to pretend
begin "print quality". So, probably, we should not focus strictly on
image quality and data loss or not, for such usage. A good practise
could be :

1. Keep original images in original size, and without data loss, TIFF,
or PNG, or JPEG at 100% quality.

2. Build specific "web variants" of your images, at significant lower
size and compressed efficiently for faster upload, smaller hosting
space, and faster download for visitors. (400 to 600 Kbytes images is
fine, 5 to 7 Mbytes images can be a nightmare for people that have a
slow ADSL connection.)
The compression, or image quality, could be tuned by hand and eye,
via testing with different quality factors, 95%, 90%, 85%, etc. as long
as the result looks acceptable.

Also, instead of uploading to web albums original big photos files, building
specific web versions allows to downsize a bit more by stripping all non
image informations (all metadata sections) and allows also building
progressive JPEG, and this is appreciated by users with a slow connection,
image loading/display is smoother and the visual effect more pleasant.

My conclusion would be : Don't throw JPEG to the trashcan:-) It's a
powerful standard, thought and designed for photography, and can be used
in different ways according to what you want to do; keep original image
data in your archives or show your images on the web. Two different
problems, so two different uses.

Best,
Jean-François

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Thorsten Schnebeck-3]

Am Samstag 14 Januar 2012, 17:15:33 schrieb =?ISO-8859-1?Q?Jean=2DFran=E7ois?=
Rabasse:

> If one selects the best, 100% quality, there won't be data loss but the
> final file size won't be that small, comparable to the size of the same
> image saved in PNG format.

Nope, 100% jpeg quality still creates a minor loss of information.
http://www.jpeg.org/faq.phtml?action=show_answer&question_id=q404fa5e29aeb6

Bye

  Thorsten
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse]

On Sat, 14 Jan 2012, Thorsten Schnebeck wrote:

>> If one selects the best, 100% quality, there won't be data loss but the
>> final file size won't be that small, comparable to the size of the same
>> image saved in PNG format.

> Nope, 100% jpeg quality still creates a minor loss of information.
> http://www.jpeg.org/faq.phtml?action=show_answer&question_id=q404fa5e29aeb6
>
> Bye
>
>  Thorsten

Hi Thorsten,

Hem, yes and no. It's not inherent to the standard but implementation
dependent. Since 1993, and during the 2000s, many enhancements have been
proposed and developed for the compression scheme.

See, e.g. http://www.jpeg.pro/articles/132599/Lossless-Further-Compression

But only some JPEG generation software implement them because in most cases
they are useless. As the article you mention states clearly, concerning the
final result, "certainly as far as the human eye can detect".

Probably the ambiguity comes from the definition of what is lossy or
lossless. Or, what exactly is lost ?
I agree the word "data" is not accurate and often used as a "joker" word.
Do we speak about "binary data" loss or "quality" loss ?
Binary data is expected to be somewhat modified, because all heuristic
schemes have different solutions to represent the same image.
But the important thing for us, photographers, is the visual image quality,
colours rendering, brightness gradients, etc.
And this can be achieved without modifications and with the guarantee that
your image will stay as you have it, as you shot it.

But ok for my lexical unaccuracy, I'd replace data by quality.

Regards,
Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

On Saturday 14 January 2012 20:26:53 Jean-François Rabasse wrote:

> On Sat, 14 Jan 2012, Thorsten Schnebeck wrote:
> >> If one selects the best, 100% quality, there won't be data loss but
> >> the
> >> final file size won't be that small, comparable to the size of the
> >> same
> >> image saved in PNG format.
> >
> > Nope, 100% jpeg quality still creates a minor loss of information.
> > http://www.jpeg.org/faq.phtml?action=show_answer&question_id=q404fa5e29a
> > eb6
> >
> > Bye
> >
> >  Thorsten
>
> Hi Thorsten,
>
> Hem, yes and no. It's not inherent to the standard but implementation
> dependent. Since 1993, and during the 2000s, many enhancements have been
> proposed and developed for the compression scheme.
>
> See, e.g. http://www.jpeg.pro/articles/132599/Lossless-Further-Compression
>
> But only some JPEG generation software implement them because in most cases
> they are useless. As the article you mention states clearly, concerning the
> final result, "certainly as far as the human eye can detect".
>
> Probably the ambiguity comes from the definition of what is lossy or
> lossless. Or, what exactly is lost ?

Afaik, there's no ambiguity in the case of compression algorithms: lossless
means that the binary data recovered after a compression-decompression cycle
is exactly the same as the original data.

> I agree the word "data" is not accurate and often used as a "joker" word.
> Do we speak about "binary data" loss or "quality" loss ?
> Binary data is expected to be somewhat modified, because all heuristic
> schemes have different solutions to represent the same image.
> But the important thing for us, photographers, is the visual image quality,
> colours rendering, brightness gradients, etc.
> And this can be achieved without modifications and with the guarantee that
> your image will stay as you have it, as you shot it.
>
> But ok for my lexical unaccuracy, I'd replace data by quality.
>

And the problem is exactly there, when images are edited: one jpeg
compression/decompression cycle might not induce _visible_ artifacts, but it
seems we agree it can cause 'binary' artifacts. Those artifacts will increase
with each compression cycle (edit session), leading finally to visible
degradation of the image (and personally, I really dislike the kind of
artifacts it causes).

I prefer using png for intermediate edits (with the space penalty that
implies), also so i can easily see which image to edit (raw, png: editable,
jpeg: final). Thus no need to mess with filenames etc. for non-final images
(but that's not a quality issue).

Regards,

Remco

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse]

Hi Remco,

And thanks for that accurate post. You definitions are indeed far less
cloudy as were mine:-)

On Sun, 15 Jan 2012, Remco Viëtor wrote:

> Afaik, there's no ambiguity in the case of compression algorithms:
> lossless means that the binary data recovered after a
> compression-decompression cycle is exactly the same as the original
> data.

Definitely unambiguous. From a mathematical point of view, you mean the
function is reversible.

> And the problem is exactly there, when images are edited: one jpeg
> compression/decompression cycle might not induce _visible_ artifacts,
> but it seems we agree it can cause 'binary' artifacts. Those artifacts
> will increase with each compression cycle (edit session), leading
> finally to visible degradation of the image (and personally, I really
> dislike the kind of artifacts it causes).

Ok, I trust you. Never seen that but probably because I'd never "cycled"
enough times.

> I prefer using png for intermediate edits (with the space penalty that
> implies), also so i can easily see which image to edit (raw, png:
> editable, jpeg: final). Thus no need to mess with filenames etc.
> for non-final images (but that's not a quality issue).

Ok again. I'd skipped that edition cycles because - as for me - that was
outside a discussion about flat images formats. As I'm a GIMP user,
the natural edition process is to open raw files with GIMP and its UFRAW
plug-in, and keep editable versions under the GIMP xcf format.

It's probably the worst format regarding file size, but I don't know
other solution to keep edition stuff such as layers, masks et al.



I have a question (no longer quality issue), for you and other users of
course, about what could be considered as a "lifetime" for non final
images files ?

Said otherwise, after what time a no more modified final image should be
considered as definitive, and intermediate files, raw file, editable
file, could be discarded to recover storage space ?
Six months, one year, two years ?

Or do users keep all, "just in case", and fill CD or DVD for the
future ? And if yes, how long do people keep CD before rewriting them to
be sure to save a readable copy, even 10 years later ?

Regards,

Jean-François

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

On Sunday 15 January 2012 19:14:23 Jean-François Rabasse wrote:
> Hi Remco,
>
> And thanks for that accurate post. You definitions are indeed far less
> cloudy as were mine:-)

Thank you :)

...
> As I'm a GIMP user,
> the natural edition process is to open raw files with GIMP and its UFRAW
> plug-in, and keep editable versions under the GIMP xcf format.
>
> It's probably the worst format regarding file size, but I don't know
> other solution to keep edition stuff such as layers, masks et al.

Neither do I, and yes, it's a disaster in terms of space (but so is TIFF...)
 
> I have a question (no longer quality issue), for you and other users of
> course, about what could be considered as a "lifetime" for non final
> images files ?
>
> Said otherwise, after what time a no more modified final image should be
> considered as definitive, and intermediate files, raw file, editable
> file, could be discarded to recover storage space ?
> Six months, one year, two years ?

Only my personal take, but for images I keep, I never delete the RAW files.
the edited PNG will also be kept, as it's the basis from which I make the JPGs
that are used for screen/web/printing. The JPGs can be thrown away fairly soon
after use, as they are produced for a specific purpose (another reason not to
use JPG for editable files, btw).

Given what's happening to disk space, I don't feel any need to recover storage
space. But that will depend on the number of images you create per year.

> Or do users keep all, "just in case", and fill CD or DVD for the
> future ? And if yes, how long do people keep CD before rewriting them to
> be sure to save a readable copy, even 10 years later ?

I don't use CDs or DVDs anymore, but removable hard drives.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Andrew Goodbody]

On 15/01/12 18:14, Jean-François Rabasse wrote:
> I have a question (no longer quality issue), for you and other users of
> course, about what could be considered as a "lifetime" for non final
> images files ?

For ever. Or as near to that as possible.

> Said otherwise, after what time a no more modified final image should be
> considered as definitive, and intermediate files, raw file, editable
> file, could be discarded to recover storage space ? Six months, one
> year, two years ?

Disk space is cheap. I do not delete any original files. Ever.

> Or do users keep all, "just in case", and fill CD or DVD for the
> future ? And if yes, how long do people keep CD before rewriting them to
> be sure to save a readable copy, even 10 years later ?

Disk space is cheap. Use a HDD, or three. You can get caddies that can
take bare drives. Have at least two copies in addition to the originals
and keep one copy at a remote location.

Andrew
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Peter Mc Donough]

> Now that hard drive space is so cheap, the solution to this problem
> is simple: Save your original (RAW and/or post-RAW or
> out-of-the-camera JPEG's) files in a subfolder, possibly named, um,
> "Originals". Mark them all "Read Only."  Now you can manipulate to
> your heart's content and you always have an original to fall back
> on.

Well, you should consider that each camera manufacturer seems to be
proud of its own RAW format, which of course changes to reflect newer
models, which, in turn, might produce an other problen in the future:
What if the manufacture stopps producing cameras (who remembers Minolta
??) and doesn't support its RAW program any more?

Possible solution: Move to a non camera specific RAW format.

Adobe offers a free RAW converter to its DNG RAW format, which might be
solution as long as Adobe stays in business, and you have one format for
all your cameras.
Digikam can use it directly.

Peter
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Dr. Martin Senftleben]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 18.01.2012 14:00, schrieb Peter Mc Donough:
> Possible solution: Move to a non camera specific RAW format.
>
> Adobe offers a free RAW converter to its DNG RAW format, which
> might be solution as long as Adobe stays in business, and you have
> one format for all your cameras. Digikam can use it directly.

If I recall correctly, dng has problems with maintaining meta data.

regards
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk8W0oQACgkQUmmuY48ByEguVQCgjBD0Pep2hZEmVFEVJMhV5VvP
yToAoMHr3T0hhG8e2ONEyP/y5pz16GkR
=TD3d
-----END PGP SIGNATURE-----

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Peter Mc Donough]

> > Adobe offers a free RAW converter to its DNG RAW format, which
> > might be solution as long as Adobe stays in business, and you have
> > one format for all your cameras. Digikam can use it directly.
>
> If I recall correctly, dng has problems with maintaining meta data.

That shouldn't be a problem (I hope) if I set the converted DNG-RAWs to
read only and keep them as the new originals.

I intend leaving all meta data maintaining to digikam and those worked
on saved as PNGs and "finish" them as JPEGs.
Digikam, as it is set up on my computer, hasn't modified any of my RAW
photos, yet.
Gimp with Ufraw also works with DNG-RAWs.

BTW The Adobe DNGConverter version 6.5 works on my computer under wine
(opensuse 11.4 64bit, standard repository)

cu
Peter
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Andrew Goodbody]

On 18/01/12 13:00, Peter Mc Donough wrote:
> Well, you should consider that each camera manufacturer seems to be
> proud of its own RAW format, which of course changes to reflect newer
> models, which, in turn, might produce an other problen in the future:
> What if the manufacture stopps producing cameras (who remembers Minolta
> ??) and doesn't support its RAW program any more?

It does not matter if the support is already in libraw or equivalent
open source code. Continued manufacturer support is irrelevant.

> Possible solution: Move to a non camera specific RAW format.
>
> Adobe offers a free RAW converter to its DNG RAW format, which might be
> solution as long as Adobe stays in business, and you have one format for
> all your cameras.
> Digikam can use it directly.
>
> Peter

If you have programs that can work with the original file format, and we
do, then you are always better off working with the original files.
Converting to DNG gains you absolutely nothing.

Andrew
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Peter Mc Donough]

> > What if the manufacture stopps producing cameras (who
> > remembers Minolta ??) and doesn't support its RAW program any
> > more?
>
> It does not matter if the support is already in libraw or equivalent
> open source code. Continued manufacturer support is irrelevant.

True if you have an open source programm and someone willing to maintain
it over the years.
 
> > Possible solution: Move to a non camera specific RAW format.
> >
> If you have programs that can work with the original file format, and
> we do, then you are always better off working with the original
> files. Converting to DNG gains you absolutely nothing.


You speak of DCRAW, I suppose. I don't know anything about the inner
working of it, but with the tons of supported cameras, there surely is
one common output format for front-ends.

Well with DCRAW, my Olympus SP550uz is, my Olympus E-450 is (was) not
listed as supported.
With DNG-RAW no problem.

I would prefer a camera independent open source RAW format. I think
DCRAW could provide such a format, but probably cannot call it RAW
because of patent or trademark restrictions.

Peter
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Andrew Goodbody]

On 18/01/12 23:28, Peter Mc Donough wrote:

>
>>> What if the manufacture stopps producing cameras (who
>>> remembers Minolta ??) and doesn't support its RAW program any
>>> more?
>>
>> It does not matter if the support is already in libraw or equivalent
>> open source code. Continued manufacturer support is irrelevant.
>
> True if you have an open source programm and someone willing to maintain
> it over the years.

Well, yes, but libraw is the same library that gives digikam support for
DNG as well as the other RAW formats so if libraw stops being supported
in the future you will equally have a problem with DNG.

>>> Possible solution: Move to a non camera specific RAW format.
>>>
>> If you have programs that can work with the original file format, and
>> we do, then you are always better off working with the original
>> files. Converting to DNG gains you absolutely nothing.
>
>
> You speak of DCRAW, I suppose.

Not exactly. Above I was talking about a common library used to decode
RAW files, libraw, which is based on dcraw source. Here I was talking
about the programs such as digikam, RawTherapee, Darktable, ufraw, that
use libraw et al or have their own RAW decoder, in order to be able to
work on those files.

> Well with DCRAW, my Olympus SP550uz is, my Olympus E-450 is (was) not
> listed as supported.
> With DNG-RAW no problem.

OK, not listed, but it may work anyway. Did you try it? If it did not
work did you provide sample files to Dave Coffin for him to implement
the support?

Andrew
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Dr. Martin Senftleben]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Am 14.01.2012 10:54, schrieb Remco Viëtor:

>> What puzzles me (is this a bug?) is that none of the tags which I
>> had saved with the raw file have been taken over by any of the
>> exported formats. It would be very difficult to create new images
>> from the raw file and again and again add the tags to the new
>> versions. Only the description and other exif data were taken
>> over - at least something.
>
> I saw that as well, in that Digikam showed tags with the converted
> image, but tags and description were not stored in the image file
> itself. (and I have selected all but the last three options in the
> 'Settings/Metadata/Common metadata actions' section). To get that
> information in my png files, I used the menu-item 'Image/write
> metadata to image'. But I'm not sure if that works on a series of
> selected files.

How does this help in keeping metadata that is already stored in the
original file? Writing metadata to image works only on the metadata
that is available for that image. If digikam doesn't take over the
tags or descriptions from the raw file when saving an edited version
as png or jpg, all the data has to be reentered. That is my main
problem, particularly with tags, as I add some five to ten tags to
each file, and having to do this over and over again, is very cumbersome.

Regards
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk8ZAucACgkQUmmuY48ByEi0SgCgv5j7fKn9sj295QMWgXvzwnQw
YNgAoKSBmk7sE3Y+1t+uESEN4EoWzfvb
=abp2
-----END PGP SIGNATURE-----

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

On Friday 20 January 2012 07:00:07 Dr. Martin Senftleben wrote:

> Hi,
>
> Am 14.01.2012 10:54, schrieb Remco Viëtor:
> >> What puzzles me (is this a bug?) is that none of the tags which I
> >> had saved with the raw file have been taken over by any of the
> >> exported formats.
> >>...
> >
> > I saw that as well, in that Digikam showed tags with the converted
> > image, but tags and description were not stored in the image file
> > itself.
> > ...
>
> How does this help in keeping metadata that is already stored in the
> original file? Writing metadata to image works only on the metadata
> that is available for that image. If digikam doesn't take over the
> tags or descriptions from the raw file when saving an edited version
> as png or jpg, all the data has to be reentered. That is my main
> problem, particularly with tags, as I add some five to ten tags to
> each file, and having to do this over and over again, is very cumbersome.

OK, then this seems to be a different problem. At least in 2.5.0, tags get
nicely transferred to the converted image (RAW -> PNG)

What settings do you use for the metadata (in Settings->Configure Digikam,
then the 'Metadata' tab, 'Behaviour' section, 'Common metadata actions')?
I have all but the last three options checked there, especially the 'Save
image tags as "Keywords"...'.
The options
'Update file timestamp...',
'Write Metadata to RAW...',
'Read metadata from XMP...'
I've left unchecked (the latter seems to cause the metadata in the raw file to
be ignored),
and 'Metadata Writing Mode' is set to 'Write to XMPsidecar for read-only image
only'

Remco


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[jag59]

Remco Viëtor wrote

What settings do you use for the metadata (in Settings->Configure Digikam,
then the 'Metadata' tab, 'Behaviour' section, 'Common metadata actions')?
I have all but the last three options checked there, especially the 'Save
image tags as "Keywords"...'.


Remco


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Hi all,
Long back I deselected 'Save image tags as "keywords" tags as metadata embedded in file'.
Because in DK 1.2 of mint9 and 1.9 of Pardus 2011.2, one can not remove the tags from file once written into the file, though they are removed from DK database. 'Image> read metadata from image' brings back those unwanted tags.
One needs to edit the 'XMP' through 'image>metadata>edit XMP' and also remove them from DK database.
If the situation is not improved with DK 2.x, writing keywords to files need to be mark as 'Experimental'....
so that nobody will blame DK

[Peter Mc Donough]

> > Well with DCRAW, my Olympus SP550uz is, my Olympus E-450 is (was)
> > not listed as supported.
> > With DNG-RAW no problem.
>
> OK, not listed, but it may work anyway. Did you try it? If it did not
> work did you provide sample files to Dave Coffin for him to implement
> the support?

No, I didn't. When I bought the camera, at that time I used jpeg - it
was a special offer and has suited my idea of a DSLR since - there were
at least three newer Olympus DSLR camera model generations.
Later I gave RAW a try and browsing the web I couldn't find any demand
for a RAW profile of my "new" camera, so asking for one especially for
me seems to be a waste of the "resource" Dave Coffin.

In fact, Digikam could read the original raw file and I didn't notice
any problems. On the other hand, I don't know enough about RAW files for
deciding what, if anything, was missing or faulty.

What I read in the web was an unhappiness about propriatary RAW formats.
There may be a good reason for propriatary formats - the obvious one I
see and don't like is that a user may stick to one brand because his
valuable photos are of in a certain RAW type.

What brough me to Adobe DNG were several discussions, among them:

http://mansurovs.com/dng-vs-raw

The version I have, DNGConverter 6.5, runs under standard Wine in
Opensuse 11.4 64bit and of course in virtualized Windows XP.

I am very pro open standards and when I buy my next camera I will check
before whether its RAW format is supported under Linux.

Peter
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users