calculate file size

[kkiel]

Dear Mario, dear all,

is there a way to calculate the file size of image versions that are currently not in the IMatch database?
Specifically: I store my black and white line drawings as tif-files, with lzw-compression, because this works better than jpg to reduce file sizes. But for several use cases I need the size the file would have as a jpg-file, uncompressed.
I guess IMatch would be able to calculate this somehow - but how?

Thank you very much for any help!

Regards,

kkiel

[sinus]

I do not fully understand.

If the image versions are not in the Database, I think, IMatch can do nothing.

[Mario]

If the image versions are not in the Database, I think, IMatch can do nothing.

Correct. IMatch does not know a thing about files not in the database.

Specifically: I store my black and white line drawings as tif-files, with lzw-compression, because this works better than jpg to reduce file sizes. But for several use cases I need the size the file would have as a jpg-file, uncompressed.

This can only be calculated by actually loading the file and creating a JPG file at the compression level you plan to use.
Photoshop does this, for example, in the export dialog. When you export to JPEG it exports the file in the background to a temp file, and then shows the size. This allows you to judge the file size based on the settings you use for export.

An IMatch app could do the same, but that is so special that this app would probably have only one user. Not worth it.

If you can program/script, you could use something like Image Magick to store your files to JPEG and calculate the file size.

[kkiel]

Thank you for your answers!

I hoped I could take width, height, color depth, file size, whatever, of the tif-file stored in IMatch to calculate the file size the same file would have if stored as jpg, without actually storing it because this would inflate the database enormously.

I didn't find an algorithm for this by now, but I remember that IMatch allows to perform calculations with metadata it stores?

I once had a function that calculated image prices from width and height of the files but unfortunately can't reconstruct it.

Thanks again for your support!

Regards,

kkiel

[Mario]

Of course the JPEG would be stored only temporary, to get the final size. There is no way to calculate this without actual producing the JPEG, because both the source image (what it actually shows) and the compression ratio affect the size.

I didn't find an algorithm for this by now, but I remember that IMatch allows to perform calculations with metadata it stores?

Yes, you can do math with variables. See math:Op, Value {,Decimals}

[thrinn]

The file size of a JPG file can not be calculated by just looking at the properties (length, width, color depth) of an original file. The resulting JPG file size depends mostly on the content of the file itself: A very big file (say, 10.000 x 10.000 pixel) which only contains a white background will compress much, much better than a file of the same size which contains a real photo with many details.

[Jingo]

For the fun of it - I decided to help and create an APP to do just this... but I'm running into to trouble getting IMatch to successfully execute the call to magick.exe... works from the cmd line every time.. but when I launch via Imatch using the IMatch.processRun({executable: 'C:\Program Files\ImageMagick-7.1.0-Q16-HDRI\magick.exe',.... command - I am not getting an exitcode=2 and nothing happens.

Will need to figure this out.. I've tired multiple exe's and even create a BAT file just in case.. same result though it runs perfectly using the command line with the same params.

Stay Tuned!

[Mario]

Don't forget to double the \ in your strings.

I don't have ImageMagick, but I've made a quick test with FFMPEG:

Code Select Expand

res = await IMatch.processRun({
    executable : 'v:\\ffmpeg\\ffmpeg.exe',
    parameters : '-f lavfi -i testsrc=duration=5:size=2560x1440:rate=30 c:\\temp\\testsrc.mp4',
    showwindow : false,
    timeout : 30
})

Works fine.

[Jingo]

yup.. that was it... I KNEW I was missing something!!  Thx Mario...

[Mario]

yup.. that was it... I KNEW I was missing something!!  Thx Mario...

Pah! Rookie mistake.

[Jingo]

Indeed!  With your wonderful help (as usual!)  - I was able to get a quick app built to display the details as requested by kkiel... I'll be posting the app shortly  - just want to clean it up a bit.   

[Jingo]

And.. all done!  The app can be found here: https://www.photools.com/community/index.php?topic=12399

Enjoy! - Andy.

[kkiel]

Hi Mario, hi Jingo,

you are absolutely great (again!)! I'll test the app this weekend but am sure it will work fine.


Thank you very much for all your support!

Regards,

kkiel

[Jingo]

Pleasure to help...I am making a few tweaks - if I can get them to work, then I will update the other string with a new zip for the files.  Enjoy! - Andy.

[sinus]

Thank you for your answers!

I hoped I could take width, height, color depth, file size, whatever, of the tif-file stored in IMatch to calculate the file size the same file would have if stored as jpg, without actually storing it because this would inflate the database enormously.

...

kkiel

Nevertheless I am curious, for what such an information could be interesting?
That what you wrote above is true, in my opinion, if you are satisfied with a rougly size.

There are more information on the net, even one, where you can calculate the size, basically the same like we could achieve with simply IMatch math.
But the results would be not exactly, like thrinn wrote, it depends also from the content of the image.
(maybe we could add another calculation with some "content value" like "simple content", "medium content" and "heavy confusing content" or so)

But of course, Jingo's app would be best, if it works fine, no question.
Nevertheless to be honest, I cannot imagine, why this could be interesting. If I would know here "how big would be the size, if I add for each tiff a jpg", well, then it would enough for me, if I would count all tiffs and calculate it with an average value and for me this would be good enough.

I hope you find a solution for yourself.

[kkiel]

Hi Sinus,

thanks for your interest! I store black-and-white line drawings as tifs, lzw-compressed, because this works for these kinds of images way better than saving them as jpg. For example: a 1,6 MB lzw-compressed tif (1200 dpi, 8678x7080 px) would need 25 MB if stored as jpg (same size).
But in my webshop I want to specify the file size in jpg, without having to actually duplicate the files in my storage to find out their jpg-size.

[sinus]

Hi kkiel

thanks. Very interesting.
Well, that makes sense, in this case the jpg should be correct, not roughly.

Then it depends also, how many such drawings you have.
Hmmm, if I try to think into your situation, I think, I would work with photoshop, let create the jpgs with an automated action, create a temporary IMatch-DB, scan tiffs and jpgs into this DB, and then transfer the jpg-size into the tiffs.

After this I would delete the jpgs and the temp-DB and let the tiffs again refresh the changed tiffs, this time with a metadata - tag and the resulting jpg.

But of course, if you have thousands of images, and in a lot of different folders, hmm, then this is also not the way to do it.

[kkiel]

Hi sinus,

I've got tens of thousands of images, so I should find a way to do it. Jingos App is very promising!
Actually I plan to generate jpgs from the tifs with IMatch and store the full size jpgs at amazon s3. Maybe I can rescue the file size in jpg from my windows explorer or from s3 somehow, too.

[sinus]

Hi sinus,

I've got tens of thousands of images, so I should find a way to do it. Jingos App is very promising!
Actually I plan to generate jpgs from the tifs with IMatch and store the full size jpgs at amazon s3. Maybe I can rescue the file size in jpg from my windows explorer or from s3 somehow, too.

Yep, Jingo has already created some very good Apps. 
I use special one of them almost every day.

[Mario]

That's why IMatch includes IMWS and allows users to work with database contents from any programming language.
I access IMWS from JavaScript, TypeScript, Python and C#, for example.

In many cases, a purpose-built app is useful to one or maybe a handful of users.
It makes no economic sense for me to work on things which will be used by a few users only. My time is better spent by making stuff that is helpful for larger shares of the user base.

[Jingo]

Just to note... I only wrote the app to generate a single temp image from the focused file and report the size.. this could easily be modified to do this on a more "bulk" scale... choose a category for example, hit an app button and it will report back with image size info for all images... along with their filename, folder location, etc.  Perhaps you also may want an option to not delete the generated temp images but instead save them for manual deletion later - remove a bit of code and off you go!

Lots of potential with just a bit of tweaking now that the bones are in place!