Posts by bitsltd

Hi,

I am going to assume you are on 1417d. If not, upgrade to that version. If you are, the fact that the number changes means the problem is in the JasPer library. This is strange because the JasPer library is used by many programs, but kit is also poorly documented. It may be fixed by switching libraries. The default build is to use JasPer (HAVE_LIBJASPER) for JPEG2000, we can ask Marcel for a dgate build with the openJPEG library (HAVE_LIBOPENJPEG) and see if that fixes it. If he can not, I will try to setup a system to build it on.

Bruce

I have been looking at the code for the JasPer library interface (used to convert to J2K). First, JasPer does not use a percent, but instead a compression ratio with 1 being a one to one and .01 producing a 100:1 compressed file size. Jasper also changes modes when from lossless (int) to lossy (real). With this said, if you run the lossy compression with a debug mode of 3, a line in the log file should say "JPEG2K Lossy Quality = ". This number can range from 95% to 1%. Does it change when you change your lossy compression?
Bruce

Hi,

I built the J2k interface to the JASPER library, I will look at how the lossy percent was passed. Does lossless have any problems?

Bruce

Hi,

I just modified the 1.4.16D version.

I put it in the same spot:
http://www.bitsltd.net/images/…ces_software/nkiqrsop.cpp

Bruce

Hi Marcel,

Is the new code posted? It is an easy change. It all takes place in CompressJPG. If the code is on the site, I will pull it down and modify it or I can send you a "From To" file. Also, you can e-mail the file. Let me know.

Bruce

Hi Heinz,

I looked at the wikipedia page and it speaks about the true lossless and near true lossless. For this, PS 3.5-2008, section A4.3, page 68 added 1.2.840.10008.1.2.4.80 and 1.2.840.10008.1.2.4.81, though I have not seen them used yet.

The "lossless SV6" in the code came from the original nkiqrsop.cxx. Looking closely at the old code, I see for J1 the option passed is "e1" and for J2 is "el".
You are correct, to correctly send "1.2.840.10008.1.2.4.57", I think the predictor must be 6.
I also think this needs to be fixed.
If you want to play with compiling, I have fixed this version of nkiqrsop.cpp and put it here:
http://www.bitsltd.net/images/…ces_software/nkiqrsop.cpp
I compiled it, but have not tested it yet, however the code changes are very small.

Bruce

Hi Heinz,

J1 is JPEG Lossless (1.2.840.10008.1.2.4.70), Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]).
J2 is JPEG Lossless (1.2.840.10008.1.2.4.57), Non-Hierarchical (Process 14) and I've only seen the First-Order Prediction set to 1
Or basically the same thing with the First-Order Prediction defined as 1.
The techie stuff: DICOM standard PS 3.5-2008, sec 10.2, page 58 states that lossless is 1.2.840.10008.1.2.4.70.
So what does all this mean.
My logic:
If it comes in as J2, leave it alone, it is already what I want, DICOM 3 will have no problem with it.
If it comes in as anything else, make it J1, the default for lossless, even if the older J2 is selected.
The questions:
Is there a reason for needing tag (0002,0010 ) set to 1.2.840.10008.1.2.4.57?
Is an older system having trouble with 1.2.840.10008.1.2.4.70?
Do you have images with the First-Order Prediction not set to 1? (I would love to see them)
The solution?:
It would be an easy change to let the older tag be used (the compression is the same), but not DICOM 3 standard.

Bruce

Hi Gilles,

Did you solve this? JSAMPLE16 is defined in jmorecfg.h. I don't see jpeg in the includes, just jasper.

Bruce

Hi Marcel,

I believe a have a much safer 64 bit version.

A recommendation on how I would check for the changes. Before comparing the new files to your files, I would replace all OperatorConsole. with OperatorConsolePtr-> and SystemDebug. with SystemDebugPtr-> in the originals. After that, I would do the file compare. Those are the biggest changes that effect the most files, yet have no real change in the program other than the allocations are done after the program starts.

The other big changes are with strlen and file functions, both can return 64 bit values, even on some 32 bit systems off_t is 64 (mine). VRs are limited to 32 bit length, so they must be checked. I also don't like strlen because many strings in DICOM are not null terminated. For this reason I add strnlen (found on many systems, if not found (mine), I create it). One day I would like to eliminate strlen completely, but not today (unless you want to). I did make strlen32 and strlen32u to limit and return the correct sizes. Again this is almost no change in function, done in a lot of places.

If you have any problems or questions, I will respond quickly. Do you have skype? (bitsltd)

Well here are the files:http://www.bitsltd.net/images/…416releasecandidate64.zip

Bruce

Hi Marcel,

Static, yes, but do they need to be global? You can look at my code, the change would now be easy. Well, I fixed all of the warnings and that made the 64 bit code much safer. I replaced a lot of the strlen()'s with a 32 bit signed (strlen32()) and unsigned (strlen32u()) versions. For example, VRs are always shorter than UINT32 so I would use strlen32u() with them. The other change was to make global classes in to pointers (Ex: Debug) and create them in main, and to test all returned file lengths for > int lengths. Even though the changes are minor, they change a lot of code.

Is your current version the last one posted? If not, can you send me the newest, I think it would be easier for me to merge your's into mine than you to merge mine.

Bruce

Hi Marcel,

I did miss the obvious, in c++ ,Array[a][b] is the same as Array[a*b] in memory and is *Array type. In libjpeg, it makes a Java style array, where Array[a][b] is not Array[a*b], but **Array and *Array.

But the question is still why MAXExportConverters * MAXExportConverters when N from ForwardPDU[N] is limited to MAXExportConverters?

Bruce

Hi Marcel,

Almost done. 2 warnings left in 32bit LE, BE and 64bit LE. I'm just not sure of the code used here in dgate.cpp:

static ExtendedPDU_Service ForwardPDU[MAXExportConverters][MAXExportConverters]; // max 20*20 with remaining association
// This looks like a 2 dimensional array of ExtendedPDU_Service or a ***ForwardPDU handle

*q = new_queue(QueueSize, 1536, 100, exportprocessN, N>=MAXExportConverters ? NULL : ForwardPDU[N], 0);
// Here it is used as a 1 dimensional array ExtendedPDU_Service or a **ForwardPDU handle

struct conquest_queue *new_queue(int num, int size, int delay, BOOL (*process)(char *, ExtendedPDU_Service *PDU, char *), ExtendedPDU_Service *PDU, int maxfails)
// And here it is ExtendedPDU_Service pointer *PDU or used as called.

Is it one or two dimensional?
I'm I missing the obvious?

Also we are creating 400 "ExtendedPDU_Service" classes as a global each time dgate is run. It is only used in export_queueN(), Could it be a local static or a global pointer made when needed?

When I am done, I would like to do the merge with your current version and send it back to you for you to look at. There are a lot of changes in code, but almost none in function. For example, OperatorConsole is changed from a global Debug to a *Debug and constructed in main. This changes OperatorConsole.printf() to OperatorConsolePtr->printf(), no real change in function, but a lot of change in code (thanks to find and replace). I also added strnlen(const char*, max), strlen32(const char*) and strlen32u(const char*) as very safe versions with the correct return sizes in 64 bit.

Bruce

Hi Marcel,

Better than that, I can send the warning free version, I just about done with it.

As for requires global construction, I think the problem is that the global class are constructed outside of main. Maybe they should be changed to pointers and allocated in main().

Bruce

Hi Marcel,

When I build the 32 bit version, gcc4.0, no warnings (yea); but the 64 bit gcc 4.2 has hundreds of warnings (boo). Most are "Implicit conversion shortens 64-bit value into a 32-bit value" and most are from functions that return a size_t put into an int, shouldn't be a problem, but it could be. The second biggest warning is for "No previous prototype for 'some_function()'", easy to fix and unimportant. The next one, bothers me, is "Deprecated conversion from string constant to 'char*'", I would like to fix this one at least and there aren't that many of them (OK, I really would like to fix them all, but ...). The last one is 19 warnings generated by -Wglobal-constructors, 'some_global_function' requires global construction or destruction. I don't know much about this warning to know if I should care. There are some posts about using static variables in global functions, but I don't see that here. Does anyone know about this?

Marcel, what do you want me to do.

Bruce

Hi Marcel,

Can I de-Warning it before it's released?

Bruce

byte must be a Windows/Lunix thing, On my MAC (BSD unix), it's BYTE.
The "byte" problem has been fixed, along with some warnings and posted on "Conquest 1.4.16 beta released"

Bruce

Hi Marcel,

I have moved here from the alpha thread. This should fix the big endian problem, the cannot compile "byte" problem and of course, some warnings. I tried to use the latest files this time. I have added 3 new compression codes to force dgate to send and store in implicit (UI), explicit little (UL), explicit big (UB). I left this function there just incase I need it again.

Bruce

http://www.bitsltd.net/images/stories/file/dgate1416_5up.zip

Hi Marcel,

I will have a look.

Bruce

Hi Marcel,

Got it. I also ran into a different type of j2k where a whole jp2 file is there instead of just the stream. I fixed that at the same time.

Both files are here:
http://www.bitsltd.net/images/stories/file/dgate1416up.zip

Time to move over to the conquest 1.4.16beta topic?

Bruce

Hi Marcel,

I can duplicate the problem using the image I found and a regen. I will work it on my Monday (NY Time).

Bruce