File Repository

[Jupix]

I found the problem, it was on my end. There was a discrepancy between the upload file size limits in the repo code (50 MB) and my php configuration (20 MB). The upload failed because the server would only accept 20 MBs through POST. The limits are now in line with each other at 50 MBs. Can you try again?

I must voice my objection to such large multi-item packs though, because the bundles can and should be divided in a per-item fashion which would make the notes and categorization more accurate, and revising and forking easier and quicker.

[Zephyris]

I must voice my objection to such large multi-item packs though,...

How is this a multi-item pack, it is a set of graphics for one grf.

...because the bundles can and should be divided in a per-item fashion which would make the notes and categorization more accurate,...

By "per item" do you mean one tar for each vehicle? as in 87 tars!?

...and revising and forking easier and quicker.

Do you mean in a purely bandwidth way?

[neob]

Jupix, iirc the allowed file format is checked after upload is finished, which can be a bit annoying since you have to upload a whole file only to get a wrong file format type error.
so maybe some static file extension check can be added to avoid this, but its really a minor not important issue (as you get the point after the first time)

By "per item" do you mean one tar for each vehicle? as in 87 tars!?

Do you mean in a purely bandwidth way?

bandwidth wise it is more logical to divide by generation or some other grouping and thus not to have to re upload the whole pack each time there is a small fix to one of the parts.

[Jupix]

How is this a multi-item pack, it is a set of graphics for one grf.

It's not limited to one RV.

By "per item" do you mean one tar for each vehicle? as in 87 tars!?

Yes, that's how I built the repo to work.

One tar = one vehicle. These tars should go in the repo and they are what developers download when they want to make improvements to singular items.
Bundle of those tars = the GRVTS tar bundle. This should go into some player resource somewhere (preferably the ingame content browser) and this is what players will download when they want to play with your set.

For practical reasons I won't forbid you (or any other developer) to upload stuff for not following that philosophy, but I do encourage you to think about it and hopefully start following it.

Obviously your set is pretty large, so it might be beneficial from a UI standpoint to add a category to list all the custom RV's under, but I assure you the script itself can handle an extra 90-or-so files.

Do you mean in a purely bandwidth way?

Not purely - I would think that it saves anyone from having to sift through dozens of .blends before finding the one they want to modify. (Not to mention the finished sprites that they have to sift through in order to replace the ones they modified.)

But the bandwidth issue itself is genuine, because if you upload a 39 MB bundle, it'll take everyone roughly 7 minutes just to download it, and that's if there are no other users currently using up my bandwidth, which is rare.

Jupix, iirc the allowed file format is checked after upload is finished, which can be a bit annoying since you have to upload a whole file only to get a wrong file format type error.
so maybe some static file extension check can be added to avoid this, but its really a minor not important issue (as you get the point after the first time)

Now that you mention it, I've thought about this before, I'll have a look.

[32Bpp-Pack]

i see the repositroy is going well

[Jupix]

I just put out rev 13 which I've been working on for the last few weeks. It's mainly a thorough reworking of how the app works behind the scenes so I'd like to take this opportunity to ask you guys to report any and all glitches or stuff that looks weird, or like it isn't working correctly.

Outside that, there are some minor new features.

I changed the entry status options (formerly known as file status options) so once again I'd ask you to go through all your hosted files and make sure status (and licensing) information is up to date.

Full change log follows. I've bolded the ones that you are most likely to be interested in.

* New feature: implemented a control panel for various level 4 operative functions like managing site appearance, settings and users.
* New feature: implemented utility for setting up the app's SQL tables.
* New feature: it is now possible to set entry status at time of initial upload.
* New feature: main menu now shows your account name and links to your profile.
* New feature: in addition to server-side validation, file extensions are now validated client-side before okaying the form
* Change: optimized the SQL backbone of the app, as detailed here: http://jupix.info/repo/docs/db_changes.txt
* Change: rewrote file status handling for increased customizability.
* Change: rewrote file<>user relations handling for increased reliability.
* Change: rewrote authentication and session handling for increased security.
* Change: rewrote file handling processes for increased reliability.
* Change: WIP status is now "unknown or dead"
* Typographical: reworded file revision lines in the activity logs to not assume the entry is owned by the user revising it.
* Bugfix: screenshot filenames were not being properly validated.
* Bugfix: footer was not being displayed in the "site disabled" screen.

[maquinista]

I have a question: Do You prefer JPEG screenshots? There are files like the bus stations that the screenshot is much bigger than the file. A JPEG without colour subsampling looks very good with a small file size.

[Jupix]

Personally I find that jpegs are the easiest to get to a reasonable size when compressing high bit depth images like this. They obviously display all the typical jpeg artefacts, but when I've tried compressed PNG's, the file size has still been stupidly large. There are people more qualified than me to answer this question, though, and while file size is important, it's also very important in the repo's case that we avoid prominent compression artefacts or discoloration, otherwise the screenshots are useless.

[Killer 11]

Having broadband internet I prefer PNG's

[planetmaker]

I have a question: Do You prefer JPEG screenshots? There are files like the bus stations that the screenshot is much bigger than the file. A JPEG without colour subsampling looks very good with a small file size.

Sorry to be harsh: as this is about graphics, also and especially their details, it'd be pretty stupid to destroy the original nice and detailed graphics by running a jpg compression over it. How shall I judge the quality of the graphics from a degraded screenshot?

[ArmEagle]

I have a question: Do You prefer JPEG screenshots? There are files like the bus stations that the screenshot is much bigger than the file. A JPEG without colour subsampling looks very good with a small file size.

Sorry to be harsh: as this is about graphics, also and especially their details, it'd be pretty stupid to destroy the original nice and detailed graphics by running a jpg compression over it. How shall I judge the quality of the graphics from a degraded screenshot?

Isn't the screenshot just to quickly show what a package contains? It won't show everything from every angle and zoom level. To really judge the graphics you'd have to download the package and view the included PNGs anyway.

As such, a JPEG does save a lot on bandwidth (though I have no idea about the hosting situation) and loads faster.

[maquinista]

Having broadband internet I prefer PNG's

But this is not only broadband, PNGs add more traffic usage in the server.

I have a question: Do You prefer JPEG screenshots? There are files like the bus stations that the screenshot is much bigger than the file. A JPEG without colour subsampling looks very good with a small file size.

Sorry to be harsh: as this is about graphics, also and especially their details, it'd be pretty stupid to destroy the original nice and detailed graphics by running a jpg compression over it. How shall I judge the quality of the graphics from a degraded screenshot?

I use JPEG with ~90 quality and without colour subsampling, the results are very good in most of screenshots.

[Jupix]

Here is a screenshot that has been split vertically in half.

Below, on the left side there is a JPEG with 5 % compression and chroma subsampling disabled. Its filesize is about 220 kB. On the right side we have a 24bit PNG. Its size is about 550 kB.



Can you tell the visual difference? In the file size there is more than 50 % in it.

Below, on the left the JPEG has been compressed 15 %. Its size is now 110 kB. The PNG is the same as it is above.



This comparison is slightly discredited by the fact the source image had to be scaled down 50 % in order to get it to fit in this post properly. I used a bicubic algorithm with 100 points sharpness.

As for the hosting situation, it is what it is in the FP. 1 mbps shared between all of yous, so there is a genuine argument against using screenshots in the megabytes size range.

[Paxinum]

Hello,

It seems like my username "paxinum" is invalid. I managed to log in like a week ago, but is there a recent change that did something to my user?

I am interesting in getting involved in this process, hopefully when the summer starts (not much spare time as a math grad student during the semester).

[Jupix]

Hi, I'm sorry for the inconvenience, the problem was that I developed rev13 of the app on a parallel database (which became the production database when I deployed the new version) and you'd registered after I took that DB snapshot. I brought you over to the new DB now. Let me know if there are further problems.

Looking forward to your contributions.

[AndersI]

The two 'left' pictures (actually 'on top' on my screen) are pixel identical - this might be a mix-up on your part. As for the jpg/png 'quality' it is difficult to say anything when you show different images. A comparison is always easier when the same original picture is treated in different ways. Apart from that, it seems to me that the jpg parts are a tiny bit fuzzier (which can clearly be seen when zooming in, but that isn't necessary in a show-off picture) - but I'm not 100% sure I could say that if I didn't know which one was which (without zooming).

The main argument against jpg is that it introduces artifacts - fuzziness around sharp lines - and also introduces new colors (a no-no when working with palettes). If a jpg is loaded, processed and saved, new artifacts will be introduced in each save.

But for showing 32bit screen pictures, I'd say they're fine! Just don't ever use them until in the last step, for viewing.

Detail, first one is from your first jpg, second one is from your png:

[Jupix]

The two 'left' pictures (actually 'on top' on my screen) are pixel identical - this might be a mix-up on your part.

You're right, it was, I'd put the same URL in there twice. Fixed now.

As for the jpg/png 'quality' it is difficult to say anything when you show different images. A comparison is always easier when the same original picture is treated in different ways.

You're right again, but this time my point was exactly that: if you aren't making a direct comparison (and like you said, even then zooming in is required), the differences are very difficult to tell.

What you go on to say is all true and it's an undisputable fact that JPEG quality is inferior, but for our use, I think the vastly smaller file sizes warrant using the format.

It's obvious that images with compression artefacts shouldn't be used as sources for anything. Sometimes they are by necessity, though, as textures for example aren't really available for free as raw images.

[AndersI]

You're right, it was, I'd put the same URL in there twice. Fixed now.

And there's still no difference visible to the naked eye. Only zooming (or advanced picture processing like 'difference') will show any difference. I think you've shown that a 15% jpg is more than enough quality to 'show off'.

[maquinista]

I have updated the monorail tracks, Now, I will upload the file without lines:
http://jupix.info/openttd/gfxdev-repo/i ... file&id=50

There aren't crossings.

Edit: uploaded:
http://jupix.info/openttd/gfxdev-repo/i ... ile&id=198

[Xand]

Maquinista, about the monorail if you look at all the corners you can see that they are not displayed properly.

monorail.jpg (107.06 KiB) Viewed 1087 times