In Photoshop you can see the size a jpeg takes up in memory. This will typically be much more than the file size on disk since once in memory it is uncompressed. This information may be useful in some cases. (My use case is a stock library requires submitted images to be above a certain size based on size in memory). I am not sure where exactly it could be displayed in PhotoLab. Photoshop displays it in a little information bar at the bottom of the image along with pixel dimensions. The obvious place for PhotoLab to show it would be in the fly out you get when you hover over an image in the filmstrip - though I am not 100% sure it fits there.
Maybe it would be better in export window with compression choices for your case.
2 Likes
As JoPoV writes - PL will not be able to give that on the fly as its not yet know what it will before you go into the export dialog and select or adjust preconfigured export setting.
Displaying it at that point would be achievable though.
1 Like
The size in memory is always the same for every picture with the same bit depth, it depends on the number of pixels. As I guess Photolab used 16 bit for processing, it will be the same size as an uncompressed 16 bit tiff image. You can export to one, and then you will know the size for all the images of your camera. It will only change when you crop.
As the stock size requires a certain size, you can calculate to how many pixels that corresponds, and then just ensure that you never crop more than that. You can calculate the size for example here:
For 24MP it would be a size of 48 MB (choose 16 bit).
1 Like
Good point, if I understand correctly - the figure would be based on a ‘work in progress’ and not final since even with jpegs DXO is editing using an adjustments list and in its own (if set) wide gamut colour space. Based on that the export dialogue makes more sense. Thanks
Indeed uncompressed size in memory (so in processing software like photolab) is :
size bits = x pixel * y pixel * bitdepht * number channels (3 for photolab : rgb).
size bytes = size bits / 8.
size kb = size bytes / 1024.
size Mb = size kb / 1024.
But does stock libraries store uncompressed files ?
1 Like
I don’t know if they store them uncompressed or not. Probably they do it this way (the minimum they accept is 17 Mb in memory) to ensure a minimum quality - either resolution or colour depth. I.e. they accept less resolution if the images have greater colour depth.
Jpeg is a compressed format with loss.
Png is a compressed format without loss.
Tiff is a compressed format without loss (maybe some compression with loss in tiff exist - I’m not sure - but photo processing software use tiff compression without loss - or at least most of them).
So if they store those formats, they store compressed files.
Memory files are always uncompressed.
Disk files can be compressed.
George
In memory 17MB = 17x1024x1024=17825792 Byte.
Every pixel takes 3 byte->17825792/3=5941930 pixel.
Assume your images have a ratio 2:3. The side can be expressed as 2ax3a long. The amount of pixels will be 6a^2.
Now we can say 5941930=6a^2. This gives for a 995.
The image size will be 2x995 by 3x995 or 1990 by 2985. That’s the minimal image size. Just to visualize it.
I don’t understand why Alamy doesn’t give a minimal pixel size.
George
I like this !!!
Don’t be affraid Alamy !!! Photolab is easy to use !!! 
I think you mean ‘minimal pixel size’. Must be ‘minimal size in pixels’. As you could read in the rest of the post.
George
Don’t get me wrong, I know your allegations are true.
But I love to think of the beginners reading this who will be wondering how to use photolab.
It’s not about Photolab. A converter works different. PL uses a bit depth of 16, so twice as much. The calculations only counts for browsers, and simple editors maybe.
George
Indeed, Yes !!! we go back to bitdepht
But the question wasn’t what PL uses.
George
And more general formula gives the result as well as formula solely focused on (simplified for) 8 bit depht and for only 3 channels.
I you know what bit depht is used in the case that interest you.
It’s hard to cummunicate on 1 subject in 2 different threads.
Again, it’s the question asked by TS.
The bit depth in memory is always stored in bytes. So a bit depth from 1 to 8 is stored in 1 byte per channel. A bit depth from 9 till 16 is stored in 2 byte per channel.
With all these posts in 2 different threads I see that this one is what PL uses.
George
First post :
@George
Don’t you think this takes compression into account ?
How are stored images in stock libraries ?
This is probably to ensure minimal image deterioration.
Indeed. I probably mixed the two at times.