digikam, (sRGB) color space conversion at flickr export doesn work
Locked
digikam, (sRGB) color space conversion at flickr export doesn work
 
|
Hi
folks
the kipi plugin
flickr export has a problem at the color space conversion from proPhoto Gamut,
Wide Gamut ... to sRGB:
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
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: digikam, (sRGB) color space conversion at flickr export doesn work
|
|
It's sound like a bug in Flickr... Excepted if image are re-sized before to be sent to web service, file are passed as well to flickr. If images are resized, color conversion are done in background by Qt API through QImage. photo are converted to sRGB normally.
Do you see any difference with or without size transform ? Gilles Caulier
2013/5/28 Steffen Bode <[hidden email]>
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: digikam, (sRGB) color space conversion at flickr export doesn work
|
|
Hi Gilles
hmm i dont think so, i mean the "wash
out colors" like this mailing-thread:
if i edit this photos with the digikam "image editor" to
convert the color space to >>sRGB<<< and after this i take the export,
all its fine. my archive images have
mostly a nikon wide gamut space.
all images are resized before to be sent to flickr.
Cheers
Steffen
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: digikam, (sRGB) color space conversion at flickr export doesn work
|
|
Hi,
can anyone here use successfully the digikam flickr
export with wide gamut pictures ? I mean with a sRGB
source picture exists no export problems .
Greetings Steffen
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Images.uniquehash calculation
|
|
In reply to this post by Steffen Bode
Hello, On Monday 17 Jun 2013 17:24:45 Marcel Wiesweg wrote: > That's the fun of a hash...Well, I dont know. > For debugging, I would record the binary data you feed into the hash > in Python and C++ to a file, compare that one. If it differs, you'll be > able to locate the problem. If not, there's a difference in the hash > implementation, but I doubt that. Implementations are the same as this is mandatory for using MD5 as files signatures. (One should be able to produce a md5 hash with any md5 software, then check it against the file with any other md5 software.) What is different in Marcos's problem is the way the file is read. The Digikam C++ code opens the file in binary mode : if (!file.open( QIODevice::Unbuffered | QIODevice::ReadOnly )) and this is the default with Qt. (Text mode requires an explicit extra flag, QIODevice::Text.) Marcos's Python script opens the file in text mode, the default with Python (and Unix open primitive). This means that each time the image file (a binary stream) contains bytes that relate to end of lines, CR (Apple) or CR-LF (Microsoft), they will be translated into a Unix line feed LF. Thus the 100 Kb buffer is modified and of course the md5 hash computation is modified too. Marcos, open in binary mode in your script, line #10 f = open (fname, 'b') Regards, Jean-François _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Images.uniquehash calculation
|
|
On Mon, Jun 17, 2013 at 09:14:40PM +0200, Jean-François Rabasse wrote:
> Marcos's Python script opens the file in text mode, the default with > Python (and Unix open primitive). > This means that each time the image file (a binary stream) contains > bytes that relate to end of lines, CR (Apple) or CR-LF (Microsoft), > they will be translated into a Unix line feed LF. > Thus the 100 Kb buffer is modified and of course the md5 hash computation > is modified too. > > Marcos, open in binary mode in your script, line #10 > f = open (fname, 'b') actually the mode has to be 'rb'. still no cigar: mdione@diablo:~/Pictures$ sqlite3 digikam4.db SQLite version 3.7.17 2013-05-20 00:56:22 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> select * from Images where name='DSC_9531_9532.tif'; 44205|683|DSC_9531_9532.tif|1|1|2013-01-06T23:36:02|27272850|9bc1b21ee7fbc2fba60a150e00d54b5f mdione@diablo:~/Pictures$ python resize.py incoming/stitch/DSC_9531_9532.tif 7fb76fbde85e2ba15604482c0b54343a this time I made sure the image is recent enough, as I was not sure if hashes were updated when the new version of the algo was put in place. -- (Not so) Random fortune: [12:32] <xanthus> el viaje mas largo que hice fue cuando sali del vientre de mi madre _______________________________________________ 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 |