Re: [Libjpeg-turbo-users] ErrorStr not initializing

[Omer M. <mou...@gm...>]

Myself, I would find this more comfortable.
Thanks.

-----Original Message-----
From: DRC [mailto:dco...@us...] 
Sent: Monday, June 01, 2015 10:27 PM
To: lib...@li...
Subject: Re: [Libjpeg-turbo-users] ErrorStr not initializing

Only in the same sense that fixing any bug is "breaking backward compatibility."  The goal is not to maintain compatibility with an incorrect behavior.  Previously, if a premature end of JPEG file was encountered, TurboJPEG functions would return 0 but set the error string.  This is simply fixing that incorrect behavior, so now said functions return -1 instead.

The patch has been checked into trunk and branches/1.4.x.  Please test it.


On 6/1/15 2:07 PM, Omer Moussaffi wrote:
> I like the direction. But won't it be breaking backward compatibility?
>
> -----Original Message-----
> From: Omer Moussaffi [mailto:mou...@gm...]
> Sent: Monday, June 01, 2015 8:25 PM
> To: 'libjpeg-turbo Users'
> Subject: RE: [Libjpeg-turbo-users] ErrorStr not initializing
>
> That actually sounds much, much better.
> And then, if I really know what I'm doing, I can choose to try and use the decoded planes if I think the error wasn't severe.
>
> Go for it.
>
> -----Original Message-----
> From: DRC [mailto:dco...@us...]
> Sent: Monday, June 01, 2015 6:08 PM
> To: lib...@li...
> Subject: Re: [Libjpeg-turbo-users] ErrorStr not initializing
>
> Why couldn't TurboJPEG just treat warnings as errors?  If it encountered a warning from libjpeg, it could finish the operation but still return an error code.  TurboJPEG was never designed to be as flexible as libjpeg.  It's an easy-to-use and straightforward API for doing full JPEG compression/decompression operations in memory.  If TurboJPEG can't completely decompress the JPEG file for some reason, then from the point of view of that API, it's an error, even though libjpeg treats it as a warning.  The other warnings that the TurboJPEG API might encounter also involve corrupt JPEG files.
>
>
> On 6/1/15 8:54 AM, Omer Moussaffi wrote:
>> Yes. Well, what you already have is s de-facto libjpeg warnings system.
>>
>> So... my 2 cents:
>>
>> Maybe add a Boolean (not mandatory, with default value) to the tjhandle initializer. The initializer will pass the Boolean to the class, and on positive (true) value, the class will clear the jerr string on every tjCompress or tjDecompress call.
>> Also, have a 'ValidateJpeg' public function which will return 0 on "no warnings on latest call".
>>
>> Basically, this is what I'm doing now, in a rather ugly fashion.
>>
>> At what level does the jerr message gets the "premature" warning?
>>
>> -----Original Message-----
>> From: DRC [mailto:dco...@us...]
>> Sent: Monday, June 01, 2015 4:34 PM
>> To: lib...@li...
>> Subject: Re: [Libjpeg-turbo-users] ErrorStr not initializing
>>
>> Never mind on the example image.  I was able to generate one by just deleting some bytes from the end of a normal image.
>>
>>
>> On 6/1/15 8:21 AM, DRC wrote:
>>> Example image?  Seems like the correct solution would be for 
>>> TurboJPEG to process warnings from libjpeg differently than errors.
>>> I am open to suggestions for how to make that happen, but I am 
>>> loathe to change the behavior of tjGetErrorStr(), since there are 
>>> probably applications that depend on its current behavior.
>>>
>>>
>>> On 6/1/15 8:11 AM, Omer Moussaffi wrote:
>>>> Thanks.
>>>>
>>>> But, then, I have no way of knowing of an "Premature end of JPEG file"
>>>> error.
>>>> Such images don't usually cause an error value on 
>>>> tjDecompressToYUVPlanes (and I'm not sure it's a behavior we want 
>>>> to change).
>>>> I have working examples: return tjDecompressToYUVPlanes returns 0, 
>>>> but jpeg is missing some blocks. The only way I found to detect 
>>>> this case is to use strcmp(tjGetErrorStr(),"No error");
>>>>
>>>>
>>>>     -----Original Message-----
>>>> From: DRC [mailto:dco...@us...]
>>>> Sent: Monday, June 01, 2015 4:02 PM
>>>> To: lib...@li...
>>>> Subject: Re: [Libjpeg-turbo-users] ErrorStr not initializing
>>>>
>>>> It's because you're using it wrong.  tjGetErrorStr() is only valid 
>>>> whenever one of the TurboJPEG functions returns an error value.
>>>> Otherwise, the error string is undefined.
>>>>
>>>> This works similarly to errno on Unix, for instance, which is only 
>>>> considered valid if a system function returns -1.  You should never 
>>>> use
>>>> tjGetErrorStr() to check for an error condition.  You should always 
>>>> use the return code from the TurboJPEG function to check for an 
>>>> error condition, and you should check the error string only if an error occurs.
>>>>
>>>>
>>>> On 6/1/15 6:38 AM, Omer Moussaffi wrote:
>>>>> There is a problem with the initialization of the error string.
>>>>>
>>>>> I'm using the same tjhandle decompressor to decompress multiple 
>>>>> jpeg files.
>>>>>
>>>>> What I do:
>>>>>
>>>>> ·Read header of file
>>>>>
>>>>> ·If everything ok, run /tjDecompressToYUVPlanes/
>>>>>
>>>>> ·Check return value
>>>>>
>>>>> ·Check /tjGetErrorStr/
>>>>>
>>>>> When the jpeg has a premature end of file error, the 
>>>>> /tjDecompressToYUVPlanes/ return value is 0 (OK), and it gives me 
>>>>> what it can from the input file.
>>>>>
>>>>> /tjGetErrorStr/ returns the string "Premature end of JPEG file", 
>>>>> which I can then check.
>>>>>
>>>>>
>>>>> The current behavior is good, except for a little annoyance: the 
>>>>> /jerr/ buffer still has "Premature end of JPEG file" error message 
>>>>> in it on the next jpeg decompression, and not the "No error" 
>>>>> string which I expect on a good file decompression. It only 
>>>>> changes on a new error instance.
>>>>>
>>>>> Currently, workaround is to manually override the jerr buffer with:
>>>>>
>>>>>                     char* tjBuff = tjGetErrorStr();
>>>>>
>>>>>                     strcpy(tjBuff, "No error");
>>>>>
>>>>> before I start reading a new file.
>>>>>
>>>>> I would expect the jerr buffer to be written with a "No error"
>>>>> message whenever a good decompression occurred.
>>>>>
>>>>> Omer Moussaffi
>>>>>
>>>>> Shutterfly


------------------------------------------------------------------------------
_______________________________________________
Libjpeg-turbo-users mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users