what i really need to know why is the pic info provided by darktable so
much off. So if an independent program displays the same info, then i
dont have to look further as to why.
Anyway, i see another entry in the bug system .:(
On 4/3/21 5:55 PM, KOVÁCS István wrote:
One way to 'verify'
isn't that a linux thing? He's probab;y on windows which means he will
need to install cygwin or something similar first.
https://itsfoss.com/run-linux-commands-in-windows/
then figure out how to install convert
On Sat, Apr 3, 2021 at 5:56 PM KOVÁCS István wrote:
>
> One way to 'verify' the
One way to 'verify' the data is to decode the file. The following
command will try to convert the JPG into PNM, but will not actually
write the output file. If an error occurs, it'll be printed. E.g. for
an intentionally corrupted file:
kofa@eagle:~$ convert /tmp/test.jpg -format pnm - >/dev/null
A couple of tools for finding info about files include "identify" from
the ImageMagick suite and "exiftool"
[wohler@olgas export (olgas)]$ identify img_6133.jpg
img_6133.jpg JPEG 5535x3687 5535x3687+0+0 8-bit sRGB 5.83985MiB 0.010u
0:00.011
[wohler@olgas export (olgas)]$ exiftool
What do you mean with 'independent of darktable'
On 03-Apr-21 19:06, Postmaster wrote:
is there a linux program that will verify the contents of a jpg file
independent of darktable?
darktable user mailing list
to
What do you mean by 'verify'?
On Sat, Apr 3, 2021, 14:30 Postmaster wrote:
> is there a linux program that will verify the contents of a jpg file
> independent of darktable?
>
darktable user mailing list
to
Try,
https://github.com/tjko/jpeginfo
On Sat, 3 Apr 2021 at 18:30, Postmaster wrote:
> is there a linux program that will verify the contents of a jpg file
> independent of darktable?
>
>
> darktable user mailing
is there a linux program that will verify the contents of a jpg file
independent of darktable?
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Yes exactly. That's the behaviour for my big image collection. But I
cannot reproduce this behaviour in a small test collection that I
created as an example for the bug report. So I guess it is somehow
related to my specific collection. I'll do some more testing.
On 03.04.21 12:29, Bernhard
Thomas Werzmirzowsky schrieb am 03.04.21 um 12:13:
Oh no, sadly the cache thumbnail gets removed as soon as I open an image
that does not exist. Afterwards the skull is shown again. This only
happens when opening an image from the develop module. From the
lighttable it is not possible to open
Oh no, sadly the cache thumbnail gets removed as soon as I open an image
that does not exist. Afterwards the skull is shown again. This only
happens when opening an image from the develop module. From the
lighttable it is not possible to open an image and therefore it doesn't
happen there.
On
That sounds really interesting, thanks.
Anyhow I have to take back my original claim. I just recreated my whole
cache and now darktable seems to show all thumbnails no matter if the
original file is available or not. I don't know why I had to regenerate
the cache to get this behaviour because
You may want to keep 'recent' (WIP) images as 'local copies'.
https://www.darktable.org/usermanual/en/overview/sidecar-files/local-copies/
darktable user mailing list
to unsubscribe send a mail to
Hi Bernhard,
that will definitely come in handy at some time. Thanks for that
Anyhow for my current case it doesn't solve the problem. By disk I
really meant different / multiple physical disks. I don't want to
connect all the disks when working with darktable (this would also
include talking
14 matches
Mail list logo
