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
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
