Digikam internal precision?
Locked
 
|
Images come out of my camera as 8-bit JPEG files. Does Digikam
convert them to a higher-precision internal format when using the editing tools? If so, is there a way I can adjust the precision? If not, would that be a useful feature? -Greg _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Digikam internal precision?
|
|
There is no advantage to convert 8 bits to 16 bits. digiKam convert
JPEG to PNG as 8 bits. Anyway, you can switch 8 to 16 bits in editor to Colors/Depth menu entry. But currently, colors histogram is not adjusted to fill whole generated by high precision conversion. If somebody as a good algorithm to do it, i can introduce it in digiKam core (there is a file in bugzilla about this subject) Gilles 2010/1/18 Greg Kennedy <[hidden email]>: > Images come out of my camera as 8-bit JPEG files. Does Digikam > convert them to a higher-precision internal format when using the > editing tools? If so, is there a way I can adjust the precision? If > not, would that be a useful feature? > > -Greg > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
But would it not help, say if you were doing repeatedly lots of
operations, to prevent loss of quality due to imprecision in 8-bit? If the 8-bit numbers were expanded to 16 bit (say mul. by 256) then you could do all kinds of operations on them, then save the result back as 8-bit rounded or truncated. I don't know if the effect is severe or not. Just an idea I had. -Greg Gilles Caulier wrote: > There is no advantage to convert 8 bits to 16 bits. digiKam convert > JPEG to PNG as 8 bits. > > Anyway, you can switch 8 to 16 bits in editor to Colors/Depth menu > entry. But currently, colors histogram is not adjusted to fill whole > generated by high precision conversion. > > If somebody as a good algorithm to do it, i can introduce it in > digiKam core (there is a file in bugzilla about this subject) > > Gilles > > 2010/1/18 Greg Kennedy <[hidden email]>: > >> Images come out of my camera as 8-bit JPEG files. Does Digikam >> convert them to a higher-precision internal format when using the >> editing tools? If so, is there a way I can adjust the precision? If >> not, would that be a useful feature? >> >> -Greg >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> >> > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > > _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Digikam internal precision?
|
|
2010/1/19 Greg Kennedy <[hidden email]>:
> But would it not help, say if you were doing repeatedly lots of > operations, to prevent loss of quality due to imprecision in 8-bit? If > the 8-bit numbers were expanded to 16 bit (say mul. by 256) then you > could do all kinds of operations on them, then save the result back as > 8-bit rounded or truncated. With current code to convert 8 to 16, no, because expanded histogram has holes everywhere. Color informations are missing. Gilles _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Il giorno 19/gen/2010, alle ore 08.40, Gilles Caulier ha scritto: > 2010/1/19 Greg Kennedy <[hidden email]>: >> But would it not help, say if you were doing repeatedly lots of >> operations, to prevent loss of quality due to imprecision in 8-bit? If >> the 8-bit numbers were expanded to 16 bit (say mul. by 256) then you >> could do all kinds of operations on them, then save the result back as >> 8-bit rounded or truncated. > > With current code to convert 8 to 16, no, because expanded histogram > has holes everywhere. Color informations are missing. This is true, after we convert to 16 bits there are holes everywhere, but after a little tinkering with the image (for example denoising, blurring, curves adjust, ...) don't we get a more uniform histogram? Image editing don't spread that color informations around? From this point of view, don't you think that working in 16 bits and truncating them back to 8 bits could be useful? These are only my hypothesis. I'm sure you can give us better explanations. Or maybe we need some experiments with some images... bye gerlos _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Wed, Jan 20, 2010 at 8:22 AM, gerlos <[hidden email]> wrote:
> > Il giorno 19/gen/2010, alle ore 08.40, Gilles Caulier ha scritto: > >> 2010/1/19 Greg Kennedy <[hidden email]>: >>> But would it not help, say if you were doing repeatedly lots of >>> operations, to prevent loss of quality due to imprecision in 8-bit? If >>> the 8-bit numbers were expanded to 16 bit (say mul. by 256) then you >>> could do all kinds of operations on them, then save the result back as >>> 8-bit rounded or truncated. >> >> With current code to convert 8 to 16, no, because expanded histogram >> has holes everywhere. Color informations are missing. > > This is true, after we convert to 16 bits there are holes everywhere, but after a little tinkering with the image (for example denoising, blurring, curves adjust, ...) don't we get a more uniform histogram? > Image editing don't spread that color informations around? > > From this point of view, don't you think that working in 16 bits and truncating them back to 8 bits could be useful? > > These are only my hypothesis. I'm sure you can give us better explanations. Or maybe we need some experiments with some images... > > bye > gerlos > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > Right, that was my thinking: convert 8 -> 16 (or 24, 32, etc) gives no benefit until you start doing image manipulations. Sometimes I adjust white balance, then further do brightness / contrast adjust, then change the saturation. All these repeated manips done in 8-bit surely have a loss in precision, while 16+ bit would help to prevent that to some degree. (Yes I could probably do it all in one go with curves, but that's unfamiliar territory for me...) _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Digikam internal precision?
|
|
This is why, working with RAW file is interresting here. RAW is 12/14
bits color depth format. digiKam store it as 16 bits color depth internally. All manipulation are processed with 16 bits. It's definitively better than 8 bits. At end you export to 8 bits with JPEG. Gilles Caulier 2010/1/20 Greg Kennedy <[hidden email]>: > On Wed, Jan 20, 2010 at 8:22 AM, gerlos <[hidden email]> wrote: >> >> Il giorno 19/gen/2010, alle ore 08.40, Gilles Caulier ha scritto: >> >>> 2010/1/19 Greg Kennedy <[hidden email]>: >>>> But would it not help, say if you were doing repeatedly lots of >>>> operations, to prevent loss of quality due to imprecision in 8-bit? If >>>> the 8-bit numbers were expanded to 16 bit (say mul. by 256) then you >>>> could do all kinds of operations on them, then save the result back as >>>> 8-bit rounded or truncated. >>> >>> With current code to convert 8 to 16, no, because expanded histogram >>> has holes everywhere. Color informations are missing. >> >> This is true, after we convert to 16 bits there are holes everywhere, but after a little tinkering with the image (for example denoising, blurring, curves adjust, ...) don't we get a more uniform histogram? >> Image editing don't spread that color informations around? >> >> From this point of view, don't you think that working in 16 bits and truncating them back to 8 bits could be useful? >> >> These are only my hypothesis. I'm sure you can give us better explanations. Or maybe we need some experiments with some images... >> >> bye >> gerlos >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> > > Right, that was my thinking: convert 8 -> 16 (or 24, 32, etc) gives no > benefit until you start doing image manipulations. Sometimes I adjust > white balance, then further do brightness / contrast adjust, then > change the saturation. All these repeated manips done in 8-bit surely > have a loss in precision, while 16+ bit would help to prevent that to > some degree. > > (Yes I could probably do it all in one go with curves, but that's > unfamiliar territory for me...) > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
But my camera only outputs JPG - I can't get RAW out of it! (it's
old). So I have no choice : ) On Wed, Jan 20, 2010 at 9:39 AM, Gilles Caulier <[hidden email]> wrote: > This is why, working with RAW file is interresting here. RAW is 12/14 > bits color depth format. digiKam store it as 16 bits color depth > internally. All manipulation are processed with 16 bits. It's > definitively better than 8 bits. > > At end you export to 8 bits with JPEG. > > Gilles Caulier > > 2010/1/20 Greg Kennedy <[hidden email]>: >> On Wed, Jan 20, 2010 at 8:22 AM, gerlos <[hidden email]> wrote: >>> >>> Il giorno 19/gen/2010, alle ore 08.40, Gilles Caulier ha scritto: >>> >>>> 2010/1/19 Greg Kennedy <[hidden email]>: >>>>> But would it not help, say if you were doing repeatedly lots of >>>>> operations, to prevent loss of quality due to imprecision in 8-bit? If >>>>> the 8-bit numbers were expanded to 16 bit (say mul. by 256) then you >>>>> could do all kinds of operations on them, then save the result back as >>>>> 8-bit rounded or truncated. >>>> >>>> With current code to convert 8 to 16, no, because expanded histogram >>>> has holes everywhere. Color informations are missing. >>> >>> This is true, after we convert to 16 bits there are holes everywhere, but after a little tinkering with the image (for example denoising, blurring, curves adjust, ...) don't we get a more uniform histogram? >>> Image editing don't spread that color informations around? >>> >>> From this point of view, don't you think that working in 16 bits and truncating them back to 8 bits could be useful? >>> >>> These are only my hypothesis. I'm sure you can give us better explanations. Or maybe we need some experiments with some images... >>> >>> bye >>> gerlos >>> >>> _______________________________________________ >>> Digikam-users mailing list >>> [hidden email] >>> https://mail.kde.org/mailman/listinfo/digikam-users >>> >> >> Right, that was my thinking: convert 8 -> 16 (or 24, 32, etc) gives no >> benefit until you start doing image manipulations. Sometimes I adjust >> white balance, then further do brightness / contrast adjust, then >> change the saturation. All these repeated manips done in 8-bit surely >> have a loss in precision, while 16+ bit would help to prevent that to >> some degree. >> >> (Yes I could probably do it all in one go with curves, but that's >> unfamiliar territory for me...) >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Gilles Caulier-4
Il giorno 20/gen/2010, alle ore 16.39, Gilles Caulier ha scritto: > This is why, working with RAW file is interresting here. RAW is 12/14 > bits color depth format. digiKam store it as 16 bits color depth > internally. All manipulation are processed with 16 bits. It's > definitively better than 8 bits. > > At end you export to 8 bits with JPEG. Ok. If you have from the start more informations, you don't want to waste them in the calculations working in 8 bits. But the point is *also* that you want to lose as less information is possible when you edit any image, since usually we do more than just one operation on our photos. If for example we do some blurring on a 8 bit image, we get always 256 shades of gray. In some next operation, for example levels adjust, we could reduce it to 200 shades of gray. But if we convert the same image to 16 bits and then we apply the same blurring, we get 65536 shades of gray, isn't it? If we do some other operations next, we still have a lot of shades to work with, and this could help preserve detail in dark or light areas, no? Even 30000 shades, less than the initial dynamics, are a LOT of informations. So this could be useful if we do more operations on the images, don't you think? bye gerlos _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Just a silly question, but I'd like to be sure.
All this 8bit vs. 16bit discussion is applicable to digiKam and showFoto? Or digiKam only? My 2 cents: I'd like to suggest (put my vote for) changing this to 16bits inthe future. Not sure how much effort is this for developers, but certainly we've herd some good arguments where 16bits would be more beneficial to the overall picture quality after applying enhanceme operations. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Digikam internal precision?
|
|
2010/1/21 Brano <[hidden email]>:
> Just a silly question, but I'd like to be sure. > > All this 8bit vs. 16bit discussion is applicable to digiKam and > showFoto? Or digiKam only? Showfoto is digiKam image editor as stand alone version. All digiKam core support 16 bits color depth. Image editor use digiKam core, so, yes, showfoto support 16 bits color depth... Gilles Caulier _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Digikam internal precision?
|
|
In reply to this post by gerlos
It is funny, that we are talking about that. The advantage of the 16 bits over 8 bits from a 8 bit file when a few operations are performed seems to be logical. I shoot in raw and the raw developers usually work with 16 bits, but I don't care. I've never tried to make some raw developer to work on 8 bits because I've read many times that this is the advantage of raw and I haven't checked this by myself. The white balance is the main reason why I use raw now.
Now, I mean funny, because I've just realized that I also have this feeling and non of us have never checked whether the difference can be spotted on a final picture at all, not on its histogram, which can be easily done ;) So simply, can one of you/us, who made a few operation on some jpgeg, make a test and tell us whether the difference can by spotted and show the example?
When I get some jpges from some friends, family etc. the only thing which I do is usually is to crop, curves or simply contrast and sharpen, sometimes perspective and/or distortion correction. I have a feeling that the difference can't be spotted when only those few operations are performed. High time to check this ;)
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Excellent idea. What would be a good type of picture to
try it on? Perhaps one with areas with pixels close in value, to see
if they end up with the same value. From: Bartek Pietrasiak [mailto:[hidden email]] Sent: Friday, 22 January 2010 9:34 AM To: digiKam - Home Manage your photographs as a professional with the power of open source Subject: Re: [Digikam-users] Digikam internal precision?
It is funny, that we are talking about that. The advantage of the 16 bits
over 8 bits from a 8 bit file when a few operations
are performed seems to be logical. I shoot in raw and the raw
developers usually work with 16 bits, but I don't care. I've never tried to make
some raw developer to work on 8 bits because I've read many times that this is
the advantage of raw and I haven't checked this by myself. The white balance is
the main reason why I use raw now.
Now, I mean funny, because I've just realized that I also have this feeling
and non of us have never checked whether the difference can be spotted on a
final picture at all, not on its histogram, which can be easily done
;) So simply, can one of you/us, who made a few operation on some jpgeg, make a
test and tell us whether the difference can by spotted and show the
example?
When I get some jpges from some friends, family etc. the only thing
which I do is usually is to crop, curves or simply contrast and sharpen,
sometimes perspective and/or distortion correction. I have a feeling that
the difference can't be spotted when only those few operations
are performed. High time to check this ;) _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Digikam internal precision?
|
|
Anybody? ;)
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Digikam internal precision?
|
|
Look there :
https://bugs.kde.org/show_bug.cgi?id=170170 Gilles 2010/1/26 Bartek Pietrasiak <[hidden email]>: > Anybody? ;) > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > > _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |