trouble with image degradation using DK with kipi-plugin: flickr export

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Progress bar doesn't

Andrew Goodbody
Hi Giles,

I was not sure if I should add to that bug or not as I am still using
1.9.0 and I am not sure if it matches what is talked about in that bug
anyway.

But just to add a couple of data points to this thread:

1) When I am tagging images, the progress bar works as expected for the
first group of images only.

2) I have DK set to write the metadata to the image files.

3) The progress bar sits at 0% until it has finished writing the
metadata to the files, at which point it goes away.

4) My CPU is an Intel Core2 Quad Q6600 at 2.40GHz.

Andrew

On 05/03/12 06:07, Gilles Caulier wrote:

> Please, feedback in this file :
>
> https://bugs.kde.org/show_bug.cgi?id=295263
>
> Note : specify which CPU you have. Operations are paralelized, and we
> need to know if you have multi-core or not...
>
> Thanks in advance.
>
> Gilles Caulier
>
> 2012/3/5 Guy Stalnaker<[hidden email]>:
>> Progress that is. I've been tagging 1000s of images and I must say that
>> doing so brings my dual-core Lenovo desktop to its knees. It's not pretty
>> LOL
>>
>> But, Digikam is doing the job. But I noticed that the progress bar that says
>> "Writing metadata to files. Please wait...(0%)" never says anything else --
>> that percentage stays at 0 no matter how long it takes and what I assumed
>> (?) was a progress bar doesn't progress.
>>
>> Is that right?
>>
>> Guy
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Progress bar doesn't

Gilles Caulier-4
2012/3/5 Andrew Goodbody <[hidden email]>:
> Hi Giles,
>
> I was not sure if I should add to that bug or not as I am still using 1.9.0
> and I am not sure if it matches what is talked about in that bug anyway.

1.9.0 is pretty old. in this bug report, we talking about Progress
Manager introduced with 2.6.0-beta1. Implementation have been
completly re-written...

>
> But just to add a couple of data points to this thread:
>
> 1) When I am tagging images, the progress bar works as expected for the
> first group of images only.

This is interresting. Group handling is perhaps not properly
implemented, in 1.x and 2.x. I will reprot this point to Marcel.

>
> 2) I have DK set to write the metadata to the image files.

ok

>
> 3) The progress bar sits at 0% until it has finished writing the metadata to
> the files, at which point it goes away.
>

Ah, it's an HDD data workflow problem.

> 4) My CPU is an Intel Core2 Quad Q6600 at 2.40GHz.
>

in 1.9.0, will still use single CPU for all in digiKam

Only with 2.6.0, we use multicore CPU. This must increase speed issue...

Gilles Caulier
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: trouble with image degradation using DK with kipi-plugin: flickr export

sbodo
In reply to this post by Andrew Goodbody
Hi folks,

i use the windows version:
Version 3.0.0
Using KDE Development Platform 4.9.5

and i have the same issue at the end of 2012 - 2013 about the color space conversion at the flickr export.  If i make a sRGB colorspace conversion with the image editor, gimp or photoshopper and export this picture to flickr all is fine. But so i must create copys of each photo to avoid the loss of the bigger color space of my archive photos ... and this creates a intricate workflow

Exists actually a patch to solve this?

Cheers

Steffen
Reply | Threaded
Open this post in threaded view
|

Re: trouble with image degradation using DK with kipi-plugin: flickr export

Remco Viëtor
On Monday 27 May 2013 06:30:48 sbodo wrote:

> Hi folks,
>
> i use the windows version:
> Version 3.0.0
> Using KDE Development Platform 4.9.5
>
> and i have the same issue at the end of 2012 - 2013 about the color space
> conversion at the flickr export.  If i make a sRGB colorspace conversion
> with the image editor, gimp or photoshopper and export this picture to
> flickr all is fine. But so i must create copys of each photo to avoid the
> loss of the bigger color space of my archive photos ... and this creates
a
> intricate workflow
>
> Exists actually a patch to solve this?

There is an 'ICC conversion' tool in the batch queue. Depending on your
workflow, that might be just what you need. For me it would be something
like:
- Select images to upload,
- put in batch queue
 - add tools to use:
        'ICC conversion', 'resize', 'unsharp mask', and 'convert to jpeg'.

I work in RAW and store edited full-sized images as PNG, to be converted
to proper format when output is needed (web, print, slideshow, ...).

Regards,

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