I just used the batch queue manager to add a text watermark to some
images and save them as a new file name. The original files were some 6.6MB in size but the new copy was only about 1.9MB but were the same pixel sizes and still had metadata. What am I doing wrong here as what I expected was simply a new file with the same file size but with an added watermark. Stuart -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Saturday 30 August 2014 08:49:23 Stuart T Rogers wrote:
> I just used the batch queue manager to add a text watermark to some > images and save them as a new file name. The original files were some > 6.6MB in size but the new copy was only about 1.9MB but were the same > pixel sizes and still had metadata. What am I doing wrong here as what I > expected was simply a new file with the same file size but with an added > watermark. > > Stuart > Please post the commands (with parameters) you used in your queue, and sample files, so we have a chance to see what's going wrong. With the information you provide, we can only waste our time guessing... Regards, Remco _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Well not sure how to do this.... the only command used was a watermark
using text and no background at 20% size otherwise all default values and I renamed them and stored them in the same folder (album). The input images were standard jpegs from my Pentax K500 and the saved files were also jpegs. I looked for compression settings on the batch queue manager but cold not find any. Comparing the images afterwards showed the renamed ones at about 1.8 or 1.9MB but the same pixel resolution as the originals which seems to me that somewhere a compression setting of less than 100% was used but as I say I cannot find anywhere how to set this for jpegs in the batch queue manager. I cant send images that size to a mailing list. Stuart On 30/08/14 09:18, Remco Viëtor wrote: > On Saturday 30 August 2014 08:49:23 Stuart T Rogers wrote: >> I just used the batch queue manager to add a text watermark to some >> images and save them as a new file name. The original files were some >> 6.6MB in size but the new copy was only about 1.9MB but were the same >> pixel sizes and still had metadata. What am I doing wrong here as what I >> expected was simply a new file with the same file size but with an added >> watermark. >> >> Stuart >> > > Please post the commands (with parameters) you used in your queue, and > sample files, so we have a chance to see what's going wrong. With the > information you provide, we can only waste our time guessing... > > Regards, > > Remco > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Remco Viëtor
OK so I have uploaded two images to my website, a before IMGP3685 and an
after test3685 both jpegs. You can find them at http://www.stella-maris.org.uk/digikam/IMGP3685.JPG http://www.stella-maris.org.uk/digikam/test3685.JPG please note these are case sensitive file names. Stuart On 30/08/14 09:18, Remco Viëtor wrote: > On Saturday 30 August 2014 08:49:23 Stuart T Rogers wrote: >> I just used the batch queue manager to add a text watermark to some >> images and save them as a new file name. The original files were some >> 6.6MB in size but the new copy was only about 1.9MB but were the same >> pixel sizes and still had metadata. What am I doing wrong here as what I >> expected was simply a new file with the same file size but with an added >> watermark. >> >> Stuart >> > > Please post the commands (with parameters) you used in your queue, and > sample files, so we have a chance to see what's going wrong. With the > information you provide, we can only waste our time guessing... > > Regards, > > Remco > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Stuart T Rogers
Am 30.08.2014 11:18, schrieb Stuart T Rogers: > Well not sure how to do this.... the only command used was a watermark > using text and no background at 20% size otherwise all default values > and I renamed them and stored them in the same folder (album). The input > images were standard jpegs from my Pentax K500 and the saved files were > also jpegs. I looked for compression settings on the batch queue manager > but cold not find any. Comparing the images afterwards showed the > renamed ones at about 1.8 or 1.9MB but the same pixel resolution as the > originals which seems to me that somewhere a compression setting of less > than 100% was used but as I say I cannot find anywhere how to set this > for jpegs in the batch queue manager. > > I cant send images that size to a mailing list. > > Stuart > I just did a small test and I see that indeed batch process does not respect the settings under Einstellungen -> digikam einrichten -> Bilder speichern - JPEG-Qualität (free tanslation: settings -> set up digikam -> save images -> jpg-quality) I set there jpg-quality once to 100%, once to 5%. The results of a batch were exactly the same (in quality and in file size). So I /guess/ that digikam uses a fixed compression ratio in batch processes (when saving directly with "save as" indeed there is a huge difference between 5 or 100%...). I think this is a bug, if someone wants to report it... However, I do not use digikam to place watermarks, I use imagemagick command line tool. I can place any text (or image would be possible, too) in any manner and convert to any file format/compression I like. I have several scripts in my digikam root folder, open them in kwrite, adjust the needed, save as "once.sh" (which is executable) and run it from the digikam root folder... My every-day-watermark-script looks like this: > #!/bin/sh > cd /to-where-the-selected-originals are > mkdir topublish > > for bild in *.png > do > convert "$bild" -resize 1280x1280\> -quality 88 -interlace line -strip -font /path-to-for-example/arial__0.ttf -pointsize 18 \ > -draw "gravity SouthEast \ > fill black text 20,9 '© www.daniel-bauer.com' \ > fill white text 21,10 '© www.daniel-bauer.com' " \ > -verbose ./topublish/"${bild%.png}.jpg" > done (pasted as quote for line length, remove quote marks...) You find all the tricks on http://www.imagemagick.org/Usage/ hth Daniel -- Daniel Bauer photographer Basel Barcelona professional photography: http://www.daniel-bauer.com google+: https://plus.google.com/109534388657020287386 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Stuart T Rogers
On Saturday 30 August 2014 10:18:40 Stuart T Rogers wrote:
> Well not sure how to do this.... the only command used was a watermark > using text and no background at 20% size otherwise all default values > and I renamed them and stored them in the same folder (album). The input > images were standard jpegs from my Pentax K500 and the saved files were > also jpegs. I looked for compression settings on the batch queue manager > but cold not find any. Comparing the images afterwards showed the > renamed ones at about 1.8 or 1.9MB but the same pixel resolution as the > originals which seems to me that somewhere a compression setting of less > than 100% was used but as I say I cannot find anywhere how to set this > for jpegs in the batch queue manager. > As you manipulate the image by adding the watermark, the image will have to be recompressed on saving. And like was said in a similar thread, a PC has more power than a camera, so it might do a better job at compressing w/o degradation. Also, looking at the images you provided, I don't see any degradation. So if you agree on that point, there seems to be no problem. Unless, perhaps, when you have to do more editing on the images (but then why put the watermark already...) Remco. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Well what I will do is use both imagemagic and gimp to put a watermark
on the image and see what file size I get from them. I think you might be right but there is certainly still a doubt in my mind about this, not sure that a camera would be that poor at compression especially a quite recent one. Stuart On 30/08/14 12:40, Remco Viëtor wrote: > On Saturday 30 August 2014 10:18:40 Stuart T Rogers wrote: >> Well not sure how to do this.... the only command used was a watermark >> using text and no background at 20% size otherwise all default values >> and I renamed them and stored them in the same folder (album). The input >> images were standard jpegs from my Pentax K500 and the saved files were >> also jpegs. I looked for compression settings on the batch queue manager >> but cold not find any. Comparing the images afterwards showed the >> renamed ones at about 1.8 or 1.9MB but the same pixel resolution as the >> originals which seems to me that somewhere a compression setting of less >> than 100% was used but as I say I cannot find anywhere how to set this >> for jpegs in the batch queue manager. >> > That helps already. > > As you manipulate the image by adding the watermark, the image will have to > be recompressed on saving. And like was said in a similar thread, a PC has > more power than a camera, so it might do a better job at compressing w/o > degradation. > > Also, looking at the images you provided, I don't see any degradation. So > if you agree on that point, there seems to be no problem. Unless, perhaps, > when you have to do more editing on the images (but then why put the > watermark already...) > > Remco. > > > _______________________________________________ > 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 |
As I suspected my camera is not that bad at compression. My image with
added watermark from GIMP is 6.2MB against the camera 6.7MB so in my view something is going wrong in Digikam. In GIMP I exported the image as 100% jpeg. I'll try imagemagik later. Stuart On 30/08/14 15:37, Stuart T Rogers wrote: > Well what I will do is use both imagemagic and gimp to put a watermark > on the image and see what file size I get from them. I think you might > be right but there is certainly still a doubt in my mind about this, not > sure that a camera would be that poor at compression especially a quite > recent one. > > Stuart > > On 30/08/14 12:40, Remco Viëtor wrote: >> On Saturday 30 August 2014 10:18:40 Stuart T Rogers wrote: >>> Well not sure how to do this.... the only command used was a watermark >>> using text and no background at 20% size otherwise all default values >>> and I renamed them and stored them in the same folder (album). The input >>> images were standard jpegs from my Pentax K500 and the saved files were >>> also jpegs. I looked for compression settings on the batch queue manager >>> but cold not find any. Comparing the images afterwards showed the >>> renamed ones at about 1.8 or 1.9MB but the same pixel resolution as the >>> originals which seems to me that somewhere a compression setting of less >>> than 100% was used but as I say I cannot find anywhere how to set this >>> for jpegs in the batch queue manager. >>> >> That helps already. >> >> As you manipulate the image by adding the watermark, the image will >> have to >> be recompressed on saving. And like was said in a similar thread, a PC >> has >> more power than a camera, so it might do a better job at compressing w/o >> degradation. >> >> Also, looking at the images you provided, I don't see any >> degradation. So >> if you agree on that point, there seems to be no problem. Unless, >> perhaps, >> when you have to do more editing on the images (but then why put the >> watermark already...) >> >> Remco. >> >> >> _______________________________________________ >> 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 > -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Remco Viëtor
On Sat, 30 Aug 2014 13:40:03 +0200, Remco Viëtor wrote:
> > As you manipulate the image by adding the watermark, the image will have > to be recompressed on saving. And like was said in a similar thread, a > PC has more power than a camera, so it might do a better job at > compressing w/o degradation. > I don't think this is true, given how the JPEG algorithm does compression. It's been a long time since I looked carefully at this, but my recollection is that the "compression ratio" you set directly affects only a single step where you divide the discrete cosine transform coefficients (for the standard 8x8 block that JPEG operates on) by the corresponding coefficients in a quantization matrix that is determined by the percentage compression you specify. It's conceivable that there's some difference in numerical precision between what's done on a camera and what's done on various computers, which would affect other parts of the JPEG process, and that this would affect the reduction achieved by the lossless run-length compression that's done afterwards, but I don't think that having additional computing power means that compression with specified percentage will typically yield a smaller file. As I understand it, higher numerical precision might make the run-length compression less effective, depending on the inputs. If I'm wrong about that, I'd be grateful if someone would straighten me out. :-) George _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users signature.asc (180 bytes) Download Attachment |
On Saturday 30 August 2014 13:04:29 George Avrunin wrote:
> On Sat, 30 Aug 2014 13:40:03 +0200, Remco Viëtor wrote: > > > > > As you manipulate the image by adding the watermark, the image will have > > to be recompressed on saving. And like was said in a similar thread, a > > PC has more power than a camera, so it might do a better job at > > compressing w/o degradation. > > > > I don't think this is true, given how the JPEG algorithm does > compression. It's been a long time since I looked carefully at this, but > my recollection is that the "compression ratio" you set directly affects > only a single step where you divide the discrete cosine transform > coefficients (for the standard 8x8 block that JPEG operates on) by the > corresponding coefficients in a quantization matrix that is determined by > the percentage compression you specify. It's conceivable that there's > some difference in numerical precision between what's done on a camera > what's done on various computers, which would affect other parts of the > JPEG process, and that this would affect the reduction achieved by > the lossless run-length compression that's done afterwards, but I don't > think that having additional computing power means that compression with > specified percentage will typically yield a smaller file. As I understand > it, higher numerical precision might make the run-length compression less > effective, depending on the inputs. > > If I'm wrong about that, I'd be grateful if someone would straighten me > out. :-) > > George > > True, so that's not the cause. What Stuart might try is add a 'convert to jpeg' step in tgeh batch queue and see if that changes things (this will also allow him to play with the jpeg compression paramters). _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Stuart T Rogers
Well I just tried adding a watermark in darktable and that ended up
slightly larger at 7.0MB. Next was a manual watermark in digikam edit and that saved as 6.5MB. So in batch mode there is something very strange going on to reduce the image so much. I believe there is a bug here.... Stuart On 30/08/14 17:47, Stuart T Rogers wrote: > As I suspected my camera is not that bad at compression. My image with > added watermark from GIMP is 6.2MB against the camera 6.7MB so in my > view something is going wrong in Digikam. In GIMP I exported the image > as 100% jpeg. I'll try imagemagik later. > > Stuart > > On 30/08/14 15:37, Stuart T Rogers wrote: >> Well what I will do is use both imagemagic and gimp to put a watermark >> on the image and see what file size I get from them. I think you might >> be right but there is certainly still a doubt in my mind about this, not >> sure that a camera would be that poor at compression especially a quite >> recent one. >> >> Stuart >> >> On 30/08/14 12:40, Remco Viëtor wrote: >>> On Saturday 30 August 2014 10:18:40 Stuart T Rogers wrote: >>>> Well not sure how to do this.... the only command used was a watermark >>>> using text and no background at 20% size otherwise all default values >>>> and I renamed them and stored them in the same folder (album). The >>>> input >>>> images were standard jpegs from my Pentax K500 and the saved files were >>>> also jpegs. I looked for compression settings on the batch queue >>>> manager >>>> but cold not find any. Comparing the images afterwards showed the >>>> renamed ones at about 1.8 or 1.9MB but the same pixel resolution as the >>>> originals which seems to me that somewhere a compression setting of >>>> less >>>> than 100% was used but as I say I cannot find anywhere how to set this >>>> for jpegs in the batch queue manager. >>>> >>> That helps already. >>> >>> As you manipulate the image by adding the watermark, the image will >>> have to >>> be recompressed on saving. And like was said in a similar thread, a PC >>> has >>> more power than a camera, so it might do a better job at compressing w/o >>> degradation. >>> >>> Also, looking at the images you provided, I don't see any >>> degradation. So >>> if you agree on that point, there seems to be no problem. Unless, >>> perhaps, >>> when you have to do more editing on the images (but then why put the >>> watermark already...) >>> >>> Remco. >>> >>> >>> _______________________________________________ >>> 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 >> > -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Le 30/08/2014 19:23, Stuart T Rogers a écrit :
> So in batch mode there is something very strange going on to reduce the image > so much. I believe there is a bug here.... yes, probably a default jpeg compression around 75% jdd -- http://www.dodin.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Remco Viëtor
On 30/08/14 18:23, Remco Viëtor wrote:
> On Saturday 30 August 2014 13:04:29 George Avrunin wrote: >> On Sat, 30 Aug 2014 13:40:03 +0200, Remco Viëtor wrote: >> >>> >>> As you manipulate the image by adding the watermark, the image will > have >>> to be recompressed on saving. And like was said in a similar thread, a >>> PC has more power than a camera, so it might do a better job at >>> compressing w/o degradation. >>> >> >> I don't think this is true, given how the JPEG algorithm does >> compression. It's been a long time since I looked carefully at this, but >> my recollection is that the "compression ratio" you set directly affects >> only a single step where you divide the discrete cosine transform >> coefficients (for the standard 8x8 block that JPEG operates on) by the >> corresponding coefficients in a quantization matrix that is determined by >> the percentage compression you specify. It's conceivable that there's >> some difference in numerical precision between what's done on a camera > and >> what's done on various computers, which would affect other parts of the >> JPEG process, and that this would affect the reduction achieved by >> the lossless run-length compression that's done afterwards, but I don't >> think that having additional computing power means that compression with >> specified percentage will typically yield a smaller file. As I > understand >> it, higher numerical precision might make the run-length compression less >> effective, depending on the inputs. >> >> If I'm wrong about that, I'd be grateful if someone would straighten me >> out. :-) >> >> George >> >> > > True, so that's not the cause. > > What Stuart might try is add a 'convert to jpeg' step in tgeh batch queue > and see if that changes things (this will also allow him to play with the > jpeg compression paramters). > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > Well I did just that (connvert to jpeg first and watermark second) and guess what .... the file ended up at 1.7MB with 100% set for the jpeg option. However I tried it again doing the watermark FIRST and the convert to jpeg second and this time I get a file of 6.5MB the same as GIMP. So it looks like the batch watermark option seems to be at fault. Equally it makes no sense to convert a jpeg to a jpeg. There HAS to be a bug here somewhere.... Stuart -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
I agree Stuart .... I am experiencing the same problem, and I had
already posted the same issue in the last week. Regards Quoting Stuart T Rogers <[hidden email]>: > On 30/08/14 18:23, Remco Viëtor wrote: >> On Saturday 30 August 2014 13:04:29 George Avrunin wrote: >>> On Sat, 30 Aug 2014 13:40:03 +0200, Remco Viëtor wrote: >>> >>>> >>>> As you manipulate the image by adding the watermark, the image will >> have >>>> to be recompressed on saving. And like was said in a similar thread, a >>>> PC has more power than a camera, so it might do a better job at >>>> compressing w/o degradation. >>>> >>> >>> I don't think this is true, given how the JPEG algorithm does >>> compression. It's been a long time since I looked carefully at this, but >>> my recollection is that the "compression ratio" you set directly affects >>> only a single step where you divide the discrete cosine transform >>> coefficients (for the standard 8x8 block that JPEG operates on) by the >>> corresponding coefficients in a quantization matrix that is determined by >>> the percentage compression you specify. It's conceivable that there's >>> some difference in numerical precision between what's done on a camera >> and >>> what's done on various computers, which would affect other parts of the >>> JPEG process, and that this would affect the reduction achieved by >>> the lossless run-length compression that's done afterwards, but I don't >>> think that having additional computing power means that compression with >>> specified percentage will typically yield a smaller file. As I >> understand >>> it, higher numerical precision might make the run-length compression less >>> effective, depending on the inputs. >>> >>> If I'm wrong about that, I'd be grateful if someone would straighten me >>> out. :-) >>> >>> George >>> >>> >> >> True, so that's not the cause. >> >> What Stuart might try is add a 'convert to jpeg' step in tgeh batch queue >> and see if that changes things (this will also allow him to play with the >> jpeg compression paramters). >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> > > Well I did just that (connvert to jpeg first and watermark second) > and guess what .... the file ended up at 1.7MB with 100% set for the > jpeg option. > > However I tried it again doing the watermark FIRST and the convert > to jpeg second and this time I get a file of 6.5MB the same as GIMP. > > So it looks like the batch watermark option seems to be at fault. > Equally it makes no sense to convert a jpeg to a jpeg. > > There HAS to be a bug here somewhere.... > > Stuart > -- > Website: http://www.stella-maris.org.uk > or: http://www.broadstairs.org > _______________________________________________ > 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 |
Yes I see it now, dont know why I ignored that.... must be selective
blindness!!!! Stuart On 30/08/14 20:50, cerp wrote: > I agree Stuart .... I am experiencing the same problem, and I had > already posted the same issue in the last week. > > Regards > > > Quoting Stuart T Rogers <[hidden email]>: > >> On 30/08/14 18:23, Remco Viëtor wrote: >>> On Saturday 30 August 2014 13:04:29 George Avrunin wrote: >>>> On Sat, 30 Aug 2014 13:40:03 +0200, Remco Viëtor wrote: >>>> >>>>> >>>>> As you manipulate the image by adding the watermark, the image will >>> have >>>>> to be recompressed on saving. And like was said in a similar thread, a >>>>> PC has more power than a camera, so it might do a better job at >>>>> compressing w/o degradation. >>>>> >>>> >>>> I don't think this is true, given how the JPEG algorithm does >>>> compression. It's been a long time since I looked carefully at >>>> this, but >>>> my recollection is that the "compression ratio" you set directly >>>> affects >>>> only a single step where you divide the discrete cosine transform >>>> coefficients (for the standard 8x8 block that JPEG operates on) by the >>>> corresponding coefficients in a quantization matrix that is >>>> determined by >>>> the percentage compression you specify. It's conceivable that there's >>>> some difference in numerical precision between what's done on a camera >>> and >>>> what's done on various computers, which would affect other parts of the >>>> JPEG process, and that this would affect the reduction achieved by >>>> the lossless run-length compression that's done afterwards, but I don't >>>> think that having additional computing power means that compression >>>> with >>>> specified percentage will typically yield a smaller file. As I >>> understand >>>> it, higher numerical precision might make the run-length compression >>>> less >>>> effective, depending on the inputs. >>>> >>>> If I'm wrong about that, I'd be grateful if someone would straighten me >>>> out. :-) >>>> >>>> George >>>> >>>> >>> >>> True, so that's not the cause. >>> >>> What Stuart might try is add a 'convert to jpeg' step in tgeh batch >>> queue >>> and see if that changes things (this will also allow him to play with >>> the >>> jpeg compression paramters). >>> _______________________________________________ >>> Digikam-users mailing list >>> [hidden email] >>> https://mail.kde.org/mailman/listinfo/digikam-users >>> >> >> Well I did just that (connvert to jpeg first and watermark second) and >> guess what .... the file ended up at 1.7MB with 100% set for the jpeg >> option. >> >> However I tried it again doing the watermark FIRST and the convert to >> jpeg second and this time I get a file of 6.5MB the same as GIMP. >> >> So it looks like the batch watermark option seems to be at fault. >> Equally it makes no sense to convert a jpeg to a jpeg. >> >> There HAS to be a bug here somewhere.... >> >> Stuart >> -- >> Website: http://www.stella-maris.org.uk >> or: http://www.broadstairs.org >> _______________________________________________ >> 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 -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Stuart T Rogers
On 30/08/14 20:38, Stuart T Rogers wrote:
> On 30/08/14 18:23, Remco Viëtor wrote: >> On Saturday 30 August 2014 13:04:29 George Avrunin wrote: >>> On Sat, 30 Aug 2014 13:40:03 +0200, Remco Viëtor wrote: >>> >>>> >>>> As you manipulate the image by adding the watermark, the image will >> have >>>> to be recompressed on saving. And like was said in a similar thread, a >>>> PC has more power than a camera, so it might do a better job at >>>> compressing w/o degradation. >>>> >>> >>> I don't think this is true, given how the JPEG algorithm does >>> compression. It's been a long time since I looked carefully at this, >>> but >>> my recollection is that the "compression ratio" you set directly affects >>> only a single step where you divide the discrete cosine transform >>> coefficients (for the standard 8x8 block that JPEG operates on) by the >>> corresponding coefficients in a quantization matrix that is >>> determined by >>> the percentage compression you specify. It's conceivable that there's >>> some difference in numerical precision between what's done on a camera >> and >>> what's done on various computers, which would affect other parts of the >>> JPEG process, and that this would affect the reduction achieved by >>> the lossless run-length compression that's done afterwards, but I don't >>> think that having additional computing power means that compression with >>> specified percentage will typically yield a smaller file. As I >> understand >>> it, higher numerical precision might make the run-length compression >>> less >>> effective, depending on the inputs. >>> >>> If I'm wrong about that, I'd be grateful if someone would straighten me >>> out. :-) >>> >>> George >>> >>> >> >> True, so that's not the cause. >> >> What Stuart might try is add a 'convert to jpeg' step in tgeh batch queue >> and see if that changes things (this will also allow him to play with the >> jpeg compression paramters). >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> > > Well I did just that (connvert to jpeg first and watermark second) and > guess what .... the file ended up at 1.7MB with 100% set for the jpeg > option. > > However I tried it again doing the watermark FIRST and the convert to > jpeg second and this time I get a file of 6.5MB the same as GIMP. > > So it looks like the batch watermark option seems to be at fault. > Equally it makes no sense to convert a jpeg to a jpeg. > > There HAS to be a bug here somewhere.... > > Stuart Just to confirm after some more testing that everything I have tried (including now imagemagick) correctly saves a watermarked image with only slightly better compression than the original from my camera. The only thing which fails to correctly save the image is a digikam watermark using the batch queue manager. This is a real PITA as I was hoping to use this digikam facility to replace a windows program I was using, so until this bug is fixed I will have to continue booting a W7 VM to do my watermarking. Please someone fix this..... Stuart -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Stuart T Rogers
Am 30.08.2014 12:09, schrieb Stuart T Rogers:
> OK so I have uploaded two images to my website, a before IMGP3685 and an > after test3685 both jpegs. You can find them at > Hi Stuart, when you compare these images with IM (e.g. compare IMGP3685.jpg test3685.jpg x: ) you'll see that a lot of pixels are affected by the watermarking (unchanged pixels are shown white, changeds red). Maybe these overall changes allow a better compression then? I would have expected that only the image region with the watermark would be affected. But this should know a digikam insider/programmer. I tried same watermarking in batch queue here (dk 2.4.0, KDE 4.13.2) with the same your result. -- _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Am 31.08.2014 12:44, schrieb guenter:
> Am 30.08.2014 12:09, schrieb Stuart T Rogers: >> OK so I have uploaded two images to my website, a before IMGP3685 and an >> after test3685 both jpegs. You can find them at >> > > Hi Stuart, > when you compare these images with IM (e.g. compare IMGP3685.jpg > test3685.jpg x: ) you'll see that a lot of pixels are affected by the > watermarking (unchanged pixels are shown white, changeds red). Maybe > these overall changes allow a better compression then? > I would have expected that only the image region with the watermark > would be affected. But this should know a digikam insider/programmer. > > I tried same watermarking in batch queue here (dk 2.4.0, KDE 4.13.2) > with the same your result. > Add: Adding the "Convert to JPEG"-tool as suggested in the mailing archive: http://mail.kde.org/pipermail/digikam-users/2010-October/011373.html and specifying there 100% quality creates a big result file but compare shows nevertheless changes allover the image. Maybe these changes come from the conversions jpeg -> internal format -> jpeg and the result is acceptable for you? HTH -- _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On 31/08/14 13:27, guenter wrote: > Am 31.08.2014 12:44, schrieb guenter: >> Am 30.08.2014 12:09, schrieb Stuart T Rogers: >>> OK so I have uploaded two images to my website, a before IMGP3685 and an >>> after test3685 both jpegs. You can find them at >>> >> >> Hi Stuart, >> when you compare these images with IM (e.g. compare IMGP3685.jpg >> test3685.jpg x: ) you'll see that a lot of pixels are affected by the >> watermarking (unchanged pixels are shown white, changeds red). Maybe >> these overall changes allow a better compression then? >> I would have expected that only the image region with the watermark >> would be affected. But this should know a digikam insider/programmer. >> >> I tried same watermarking in batch queue here (dk 2.4.0, KDE 4.13.2) >> with the same your result. >> > > Add: > Adding the "Convert to JPEG"-tool as suggested in the mailing archive: > > http://mail.kde.org/pipermail/digikam-users/2010-October/011373.html > > and specifying there 100% quality creates a big result file but compare > shows nevertheless changes allover the image. Maybe these changes come > from the conversions jpeg -> internal format -> jpeg and the result is > acceptable for you? > > HTH > Bottom line here is that in my view there is a bug. You should be able to start with a jpeg and using Batch Queue Manager add a watermark and save it as a jpeg and it should work EXACTLY like it does when using the digikam editor and saving the image. There should be NO need to add a Convert to JPEG to get it to work. As of now I will go back to using my Windows7 VM and a Windows program to watermark any images I need to and will not attempt to use digikam for this purpose again until this bug is fixed. For me there is no more debate on this it is unquestionably a bug in digikam. Stuart -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Free forum by Nabble | Edit this page |