Re: NSImageCompressionFactor

[Fred Kiefer]

On 21.05.2014 16:56, Riccardo Mottola wrote:
> Hi,
> 
> Lundberg, Johannes wrote:
>> Well, the GNUstep documentation clearly states that it is from 0 - 255
>> so maybe it something that Apple changed recently? We also have to
>> update the documentation and think about all the programs we will
>> break if changing the functionality...
>>
> I found this code in our JPEG handling:
> 
>   if (qualityNumber != nil)
>     {
>       quality = (int) ((1-[qualityNumber floatValue] / 255.0) * 100.0);
>     }
> 
> it is clearly expecting something between 0 and 255 and in "reversed"
> way, since Cocoa states that 0 is lowest quality, 1 highest.
> 
> This assumption (and back-and-forth conversion) is all over
> NSBitmapImageRep.
> 
> I fixed that to my best. Please try!
> 
> Maybe I have forgotten something elsewhere.
> 
> Now, in PRICE, if I compress the same image with different settings, I
> do get:
> 
> -rw-r--r--  1 multix  staff   14751 May 21 16:44 linhof_00.jpg
> -rw-r--r--  1 multix  staff  451980 May 21 16:46 linhof_100.jpg
> -rw-r--r--  1 multix  staff   41743 May 21 16:44 linhof_25.jpg
> -rw-r--r--  1 multix  staff   86293 May 21 16:44 linhof_75.jpg
> -rw-r--r--  1 multix  staff  355566 May 21 16:46 linhof_98.jpg
> 
> which looks much more reasonable than before!
> 
> Riccardo

Hi Riccardo,

thank you for looking into this and fixing it!
Just to make sure, could you please check your results on a Mac as well?
I find the words used in the Apple documentation rather confusing:

"JPEG compression allows a compression factor ranging from 0.0 to 1.0,
with 0.0 being the lowest and 1.0 being the highest."

>From this I would expect 0 to be no compression, that is a huge file and
1 being a high compression, that is a smaller file.

Fred