C# encoder jpeg (COM header handled properly by some viewers but not by some others. Workaround provided.)

[msjuniorc]

hi all,

thanks to Albert's corrections to the encoder.cs, the ipsp sample can now save consistently jpegs ... but I have found (unfortunately) another problem.

When opening and saving a jpeg, the output jpeg can be viewed by sompe programs and not by some others.

For example, while the original can be opened by jpgview.exe (samples) or mspaint, the one saved through the ttippi example cannot. If viewed through jpgview it shows black. If one attempts to view it via mspaint, the latter returns an error and the file can't be opened. Now here is where it gets more complicated, the same file can be viewed through the "windows Picture and Fax Viewer" or the browser (IE and Firefox).

Attached are two files, now.jpg (the original) and now1.jpg (the saved copy using the example).

Thank you in advance for any help,

msjuniorc

[levicki]

Please do not start multiple threadswith the same or similar subject -- please aggregate the information toone of them and delete the other two. Thank you.

[msjuniorc]

Quoting - Igor Levicki

Please do not start multiple threadswith the same or similar subject -- please aggregate the information toone of them and delete the other two. Thank you.

Hi Igor,

with all due respect, the reason why this is in a new thread is because I think and hope that this is a different bug from the previous one. At least my initial investigation shows differences in the way the jpeg header are formatted. I have no problem, if this is what the moderators prefer, in merging different issues in a common thread. The intention was, and is, to segregate bugs so not to make any confusion. If it appears, to the reader, that this thread addresses the same issue as the previous ones, I will rephrase this to emphasize the differences. Ultimately, my only wish is to address an issue I have with the aforementioned code. I have no specific preferences about the number of threads and will modify it/them however it is necessary/requested.

Thank you,

msjuniorc

[levicki]

I have noproblems with separating the issues. I do it as well. However, based on the thread titles your issues sound the same, so you could at least try to think of a better subject.

[Albert_Stepanov]

Hi msjuniorc,

Sorry for inconveniences but some viewers not correctly handle a comment's segment in jpg-files (mspaint says "file's format is not currently supported"). Our encoder writes the COM-marker and length 2. And it's correct. That means there isthe COM-marker and the empty comments. As a workaround you can comment out the WriteCOM function's codes (encoder.cs, line 483). Or add and write your own comment's string after COM-marker. After that mspaint will read jpg-files saving by ttippi sample.

Regards,

Albert

[msjuniorc]

Igor,

point taken. I will extend the subject of this thread to facilitate future research.

msjuniorc

[msjuniorc]

Albert,

In a few I will try the workaround and will let you know the results. I was thinking of a pre-encoding check (if comment is blank fill it with some string ... sort of) not sure if it would be more elegant/proper to perform this check in the encoder.cs or the ttippi.cs. On a different but related matter, are you maintaining the c# examples? The reason I ask is because I have found a few more "quirks" and would like to know who I can get in contact/collaboration with so to correct as many "quircks" as possible before the next release.

TIA

msjuniorc

[msjuniorc]

Albert,

definitively a step forward. The File can now be edited by MSPAINT. Instead of commenting out the entire method I just commented out the calls to it (WriteCOM). I have also noticed code (commented out) that was indeed checking for a value or it would assign a default "versioning" comment. There is still the presence of what seems to be an "extra" header. Its presence does not allow IJL based utilities (i.e. jpgview) to see the image. No errors, but a completely black image. I compared the "good" and the "bad" images and found the following "extra" header in hex:

[c-sharp]0b ff c4 00 1f 01 00 03 01 01 01 01 01 01 01 01 01 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0a[/c-sharp]

Thank you in advance,

msjuniorc

PS It seems to have something to do with the DefaultChrominanceDCBits and the DefaultLuminanceDCBits.

[Albert_Stepanov]

Hi msjuniorc,

unfortunately this encoder not absolutely follows the JPEG specification. And IJL viewer follows.

Update please next codes in the sample:

//encoder.cs

public JPEGEncoder() // line 340
{
int i;
for( i=0; i {
m_qntbl = new CJPEGEncoderQuantTable();
}
for( i=0; i {
m_dctbl = new CJPEGEncoderHuffmanTable();
m_actbl = new CJPEGEncoderHuffmanTable();
}
m_se = 63; // missed data
}

JERRCODE WriteCOM() // line 484
{
IppLibraryVersion lib = new IppLibraryVersion(ipp.jp.ippjGetLibVersion());
string comment = "JPEG encoder based on " + new string(lib.Name) + " " + new string(lib.BuildDate);
int len = comment.Length + 2;
if (m_dst.currPos + len >= m_dst.DataLen)
{
return JERRCODE.JPEG_BUFF_TOO_SMALL;
}
m_dst._WRITE_WORD(0xff00 | (int)JMARKER.JM_COM);
m_dst._WRITE_WORD(len+1);
for (int i = 0; i < len - 2; i++)
{
m_dst._WRITE_BYTE((byte)comment);
}
m_dst._WRITE_BYTE((byte)0);
return JERRCODE.JPEG_OK;
}

Sorry forinconveniences.

Regards,

Albert

[msjuniorc]

Albert,

thank you for the code corrections. I am now able to process jpegs and able to view them via an IJL based utility.

I am assuming you are the maintainer of the c# sample code. I have identified - but not performed any diagnostic yet - a few more quirks on the ttippi example. For example, if attempting to rotate an image, only a sub section of the complete image (North-West) is processed. A similar behaviour (sub section) can be observed when performing other filter/transformation.

What is the internal procedure to begin addressing the aforementioned problems?

Should a new thread (i.e. "c# ttippi.exe bugs and fixes") be started?

Once again thank you for the solutions already provided and looking forward to begin correction of the other issues.

msjuniorc

[Vladimir_Dudnik]

Hello,

with this community forum you can reach IPP technical experts to talk on features or issues you met with IPP product. And IPP technical support people also watching this and will submit issue reports into product data base so development team will review and plan work on this. If you have several issues I would recommend you to create separate threads and mark them as an 'Issue report' to signal product technical support service that it is a problem and you expect somewe will follow up on this.

Regards,
Vladimir

[Albert_Stepanov]

Quoting - msjuniorc

Albert,

thank you for the code corrections. I am now able to process jpegs and able to view them via an IJL based utility.

I am assuming you are the maintainer of the c# sample code. I have identified - but not performed any diagnostic yet - a few more quirks on the ttippi example. For example, if attempting to rotate an image, only a sub section of the complete image (North-West) is processed. A similar behaviour (sub section) can be observed when performing other filter/transformation.

What is the internal procedure to begin addressing the aforementioned problems?

Should a new thread (i.e. "c# ttippi.exe bugs and fixes") be started?

Once again thank you for the solutions already provided and looking forward to begin correction of the other issues.

msjuniorc

Dear msjuniorc,

This sample is example of using the unmanaged IPP functions with the managed callers via the P/Invoke method. It's not the specific purpose application. And for rotating (filtering) an image it showshow tooperate withROI (here roi is 3/4 of the complete image).You free to usethese codes to create your own application what you need.

Regards,

Albert